Stripping off complete path names

[toscanini]

Hello..

I wonder if there is a method to strip off a complete path name like:

"Macintosh HD:/Users/gergelysuto/Desktop/music/new_take_on_nemtom_machine Project/kicks/kick3.aif"

- into: kick3

no other sense than to make it look good and concise to show in lists.

Probably rather a javascript string manipulation trick than native max? If not too complex though (or if someone has built it) I'd love to know.

Thank you,
toscanini

[hoffman2k]

There's an object for this called "strippath."

http://cycling74.com/docs/max5/refpages ... ppath.html

[toscanini]

Awesome
Thanks a lot!

[toscanini]

Hey, Peter,
thanks for the new info,

so if I understand well, the big advantage of the regexp method is that if, for instance I share some device that has samples (files) attached, with regexp it will look and feel the same on somebody else's computer, with strippath it won't in all cases. (right now I have been generating path names with a dropfile object, so in this case even strippath could offer a shareable solution, right?)

Thanks for the version without extension name, real sexy! The PERL syntax is a bit scary, but I am definitely motivated to give it a look.
cheers,

[toscanini]

I added a small expansion; now it should work for both PC and Mac

Nice! I'll use this version if I come up with something that is worth it.
I have seen live.drop and I have a question: native Live instruments like Impulse and Simpler have drop windows that accept samples directly from Live audio clipslots. From my tests this does not work for live.drop. I hope I am mistaken otherwise it is a serious drawback and in this case live.drop wouldn't offer any real differentiation from the dropfile object... from what I understand...

[pid]

hi toscannini

live.drop is live parameter aware, whereas dropfile is not. similar to difference between live.dial and dial.

so, with a bit of patching you can restore loaded samples at saved set / device load.

the whole path business is a minefield because of differences between os's. there are good discussions / demos in all the helpfiles etc for all the relevant objects, eg strippath, conformpath, absolutepath, regexp, etc etc etc.

hth

[stefan-tiedje]

strippath never was a problem for me in terms of core functionality. If you came across the object "tosymbol", you know why. But there is another valid drawback. Its slow, for the simple reason: it also checks, if the file is within the search path.
My experience with regexp is schizoid, usually regexpressions are hard to understand, and very often create unexpected results for some rare special cases (I believe that the given regexp will work fine, but I have no intention to test it...;-).

I had my own needs covered with two abstractions, both don't use regexp, but simple atoi - itoa and some standard Max logic to do their magic. One cuts off extensions and is called strip.ext and the other splits a complete path into path and file name (stripname). The latter is much faster than strippath, though its an abstraction and its more useful...
They both eat happily path names with spaces...
The regexp solution will also be faster by the way...

If you are curious, you'll find both solutions in my St.ools collection:
http://dl.dropbox.com/u/288305/St.ools%20for%205.zip

[toscanini]

@Stefan, thank you for strip.ext, works fine, looking forward to check the rest tomorrow.

@Peter, looking forward to the regexp guide

@pid,

with a bit of patching you can restore loaded samples at saved set / device load

well, this is a cool new perspective. I see now you can bind pattr to a live.drop. I need to see how to take advantage of this. But still, live.drop's inability to receive from a clipslot is disappointing.

[pid]

well, this is a cool new perspective. I see now you can bind pattr to a live.drop. I need to see how to take advantage of this. But still, live.drop's inability to receive from a clipslot is disappointing.

yes, there is much that is really disapointing in m4l, but i guess there is enough that is awesome to keep us all here, too. besides, everytime i leave the max bubble into the real world of yucky stuff like nuendo and pro tools and media composer etc, i feel sick and have to come back to max.

[toscanini]

@pid, I am a bit disapointed with what I have found as perspectives of binding a live.drop to pattr. All it can do is save one pathname as a preset, whereas since with live.drop we are talking about an object designed for realtime manipulation, it should be able to do so with, say, a list of paths obtained by dropping samples in a certain order and editing.
Too bad, I was hoping to short circuit another problem that I did not know yet how to resolve, as exposed here
http://forum.ableton.com/viewtopic.php?f=35&t=156691

I have got advices from Hoffman2k that I'll need to reread a couple of more times to understand

My idea here is to build a very basic sampler without Impulse's envelope options (and really cheap sounding effects) but with a very complete sample management system instead. It is a pain that it won't work directly drawing from clipslots, but the same can certainly be acheived with automatized recording and naming and reloading.
If any of you guys are fancy this idea please speed me up with extra hints,
thank you,
toscanini

yes, there is much that is really disapointing in m4l, but i guess there is enough that is awesome to keep us all here, too. besides, everytime i leave the max bubble into the real world of yucky stuff like nuendo and pro tools and media composer etc, i feel sick and have to come back to max.

totally agree with you about max compared to finished softwares, and I suppose m4l also has brought along a more pragmatic spirit.

[Emanuel Frey]

@toscanini

I had the exact same problem lately with my drumfire m4l patch in version 2.
http://www.maxforlive.com/library/device.php?id=406
The way I solved it is to fill a umenu with the paths, send the umenu contents to a coll object, and finally save and recall the contents of the coll object -> and back...
Its a crude hack, and I would love to see a simpler solution. If you know of one...
Emanuel m8r

[flowdesigner]

live.drop's inability to receive from a clipslot is disappointing.

+10