incidentally i am also pretty deep in the process of building a modular sequencer that saves the state of all the objects in a song using [maphash] which suffers from the same "saves the textfile releatve to the pd dir, not the patch dir" problem. how can you share a little more detail on how your solved this issue? also, what advantages does the [pool] object have over [maphash]?
-josh
David NG McCallum wrote:
Frank,
Actually, I'd also come to the same idea of using Pool to cover my state saving. The only problem was that Pool saved in a path relative to the Pd dir and I needed it to save relative to the patch dir, but I think that's being changed.
I've currently got a really ugly (but it works!) method for saving abstraction states in files in the path of whatever parent patch is making use of the abstractions. This way each of your patches can have unique state settings. I've got a modular mixer strip setup that makes heavy use of this.
Interesting with what you've done about using one file to hold the settings for multiple abstractions, though... I'll have to think more about that... Actually, that's going to be awesome. You could have *all* possible drum settings all stored in just one settings file... hmmmm... Good work, Frank. :)
David . . David McCallum . Music wants to be free . http://mentalfloss.ca/sintheta .
Frank Barknecht wrote:
So all saving of all used patches can be done in a central place. Dave MacCallum had to overcome a lot of ugly obstacles to do largely the same just with builtin objects in his reworked d-angriff patches and a lot of other patches, but with pool it's so much more simple, that it's worth the extra external. Dave, don't you agree after seeing the attached example?
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list