Making playlist~ filepaths relative/'saving' playlist~
Hi,
I'm writing to ask whether anybody has found a way to make file references in the playlist~ object relative to the max patch (like the object it is based on - sfplay~)? I'm specifically having this problem giving an ensemble a piece with a standalone, which uses the playlist~ object. It seems like the files aren't relative (like in sfplay~), and so they do not load (eg. they reference the full filepath of my computer). I see that the example audio files in Max's loop browser (jongly.aif), aren't referenced in the same way as files I have dragged in.
One approach I can think of would be using the dict function of the playlist~, and creating a coll with the filename info in it (along with other info - selection etc.), and using a combination of 'append $1' and other relevant commands to load it on start-up... But that seems like a lot of faff for such a user-friendly object? Can it be exposed to pattr? Or could I export a JSON dict, and then load the dict back into it?
I did a forum search but haven't unearthed anything. I reckon something along these lines would be a good feature to add in, if the functionality isn't there. There is probably a really elegant way of doing this - my handling of presets etc isn't great.
Thanks.
Don't know if this solves your problem exactly, but these two examples in combination show a way to ensure that your sound files are found if they're in a folder called "sounds" in the same folder as your patch. You could probably adapt these ideas as you populate your sflist~.Providing a full path nameUsing the full path when opening a file
Thanks for your reply. I should be able to get something going with that, combined with using a coll for any settings etc. Strangely, when I send the message 'append' to playlist~ a 'file open' (I don't have a better name for this) dialogue box comes up (the same as is if you send 'open' to sfplay~), but when you select a .aif in the same folder as your max patch you get an error message saying it cannot be found (relating to the path as well).
I would usually have done this with sfplay~ objects, but I thought I'd use playlist~ for slightly greater flexibility etc. It seems a little counter-intuitive if playlist~ is meant to be based on drag and drop etc that these sort of work arounds are needed. Surely there is an elegant way around this?
In the end I've just removed playlist~ from my patch. Would still be interested to know if it'd possible to include playlist~ in, for example, a standalone...
It is, and we fixed a bug in 7.0.2 which prevented the file resources for playlist~ from being copied into the standalone bundle/folder so that they can be used/distributed. However, there's still a bug w/r/t same in projects -- this is already fixed, but missed the 7.0.2 cutoff.
For a future update, we're working on solving some other outstanding issues with objects like playlist~ (which use external media files which can't be embedded into a collective) and projects. For instance, you'll be able to see these files as dependencies in the project window, and perform consolidation/snapshotting/standalone-building without any extra effort, and without needing to worry about absolute vs relative path specifications.
Hi Jeremy, to your knowledge has this issue been fixed?
I think it's related to my issue.
I cannot import audio files into playlist~ in my standalone either by dragging or by sending playlist~ the 'append' message. I've posted my issue here:
hi jeremy, with the 7.3.5 most issues are gone, but if i add a soundfile to a playlist in a standalone app, or if i erase files from it, when i quit and reload the standalone the changes in the playlists are not mantained and it gets back to the original state of when the app was built... is there something i'm missing and doing wrong? if not, is there a way to workaround/fix that?
I have playlist~ presets that lose the path to the files when I open the patch on another computer. To the best of my knowledge, this issue hasn't been fixed in 2025.
I was mistaken. The patch appears to work on different computers if the playlist~ absolutepath only contains the filename. I suspect Max will attempt to locate the missing files within its filepaths.