Saving the path of a sample
hi everybody,
i'm currently working on a groovebox-like beat tool and i'm struggeling with the whole save thing.
does pd provide any object or message to save / load a path of a .wav file, so that i can link all my samples in a preset?
it also would be nice to pack everything in one preset file together with my other tables etc. which also should be saved..
thanks in advance
For more complex state-saving like you're talking about, I wrote these abstractions to help simplify it:
http://puredata.hurleur.com/sujet-5664-state-saving-abstractions
as for the path thing, [splitfilename] will split your filename into a path and filename, so maybe that's useful?
i don't think there is a way to do that in vanilla PD.
thx mealstorm! this looks very useful.
do the save.mmb and the corresponding my.hero objects have to be in the same patch / subpatch or is there any workaround?
and is it possible to save path information "/samples/kick.wav" with the save.mmb object?
thx for the help
@gerritschuster said:
thx mealstorm! this looks very useful.
do the save.mmb and the corresponding my.hero objects have to be in the same patch / subpatch or is there any workaround?
As long as they have the same ID, they'll all talk to each other.
and is it possible to save path information "/samples/kick.wav" with the save.mmb object?
Yes, just send the full path to [save.me.mmb]. You just have to remember to convert it back to a symbol, since Pd seems to forget.
In fact, if you're saving to file and then opening it, Pd will probably parse out the spaces in the path (if there are any) and call it a list or an anything. In that case, you might want to use [list2symbol] to convert it.
thx a lot, the path thing works fine.
but putting the save.mmb objects in seperate patches doesn't work although they have the same ID..
They should. The ID is what it uses for the [send]s and [receive]s. You're not using $0 as the ID, are you? Because that will give a different value for each patch, and so they're not actually matching IDs.
To be honest, though, I wouldn't consider it good practice to be saving presets of multiple patches in one file, because then you lose the usefulness of $0. You'll run into problems if you have multiple instances of the same patch. It's a bit more complicated, but you'd probably be better off wrapping the patches up as abstractions and using a method like the one in [pd abstractions] in the [my.hero.mmb] helpfile.
ah ok - i tried it like in the abstractions-helpfile (but with a saved textfile). the output in the file looks good so far but with the given save/load-patch in your examples, it doesn't seem to load from the textfile.
do i have to modify the routine (from the help patch) to load the data?
sorry for the many questions but this saving stuff is freaking me out
Post an example patch so I can get a better idea of what's not working.
save_settings.pd -> save routine from your helpfile (with my instsaver abstraction).
instsaver.pd -> receives sample-relevant parameters i would like write in a textfile
save_settings.pd -> save routine from your helpfile (with my instsaver abstraction).
instsaver.pd -> receives sample-relevant parameters i would like write in a textfile
Okay, I see. So let me explain a bit about how this approach works, because I'm realizing now it may not be entirely clear. When you use these abstractions to make a "dump" method in an abstraction, what happens is each parameter gets sent out with its [save.me.mmb] name and value. Now, when you collect all of those parameters in a single [save.me.mmb] outside of the abstraction, the name and value pairs are all stored. When they get loaded, they get spit out, again in name and value pairs. You need to [route] those pairs in the abstraction to wherever they need to go. Right now, you have the [route], but it's not doing anything.
oh my, this one is quite obvious. thanks again for the help..
one last thing would be the saving in relative paths (the file symbols), so i can use my presets on different computers / os. openpanel alsways puts out the absolute path, even when i switched to the patche's dir where my samples are in.
Assuming the samples are all in the same folder (let's call it "samples"), and that folder is in the same folder the main patch is in (which is the best way to do it if you are passing the patch around), then the simplest way would be to use [declare] to add the samples folder to the path when the patch loads:
[declare -path samples]
Put that in your main patch. You might have to save and reload the patch for it to take effect.
Then, when you call up the sample using [openpanel], you can use [splitfilename] to get the file name only. You won't need to keep the path, because Pd will look for it in the samples folder when you load the file into [soundfiler] or whatever.
usually i have some subfolders like samples/kicks, snares etc. but if it's the only way i could get used to it.
i stumbled upon a new saving issue - in my patch there are 2 tables which need to be saved in the same preset file together with all the other parameters etc. i tried to add the routine like in the attached patch -> error msg output (addcomma) and the table gets saved and loaded. the other parameters also appear in the preset file but don't get loaded.. any idea?
forget about the previous post, i found the bug..
@gerritschuster said:
usually i have some subfolders like samples/kicks, snares etc. but if it's the only way i could get used to it.
It's not the only way, it's just one way. Keep in mind you can add multiple [declare]s, so you can have [declare -path samples/kicks], [declare -path samples/snares], etc.
You can also do some list processing to try and keep the "samples/kicks" part if you want:
[openpanel]
|
[symbol2list]
|
[t l l]
| \
|
| \
| [- 3]
| \
|
[list2symbol]
Actually, check out this patch I just put together. It will give you a relative path if the path given is contained in the same folder as the patch. Otherwise, it will give an absolute path.
boom! that's what I needed.. I just shared my little project in the patches section - have a look and tell me what you think.
A version of relative path for Vanilla (no need for externals):
Oops! Looks like something went wrong!
