Problem with live.drop and the preset object in M4L
Hello,
Once again I am so stuck with this problem that I plea for any help :( I tried searching the forums already, but didn't find anything helpful..
I am trying to make a simple drum/oneshot sample launcher with switchable layers. Now I am stuck however with the live.drop object, for I cannot store my sample paths into the preset object properly. Upon inspection it seems that the actual filepaths _do_ get stored with the preset object, but recalling a preset does not recall the sample into the buffer(s).
Here, have a looksee (made a single pad version of the patch):
Any help would be much appreciated! I remember earlier I was fighting with getting some function tables recalled into presets, in that case I eventually solved the problem by pattr'izing the function tables.. But in this case I haven't been able to get the dang live.drop to recall the paths even with the aid of pattr objects.
IMVHO this whole pattr & M4L scheme could use a proper "official" documentation, outlining all the known & unknown issues with using pattr(s), presets et al with your M4L patches.. Something's muy illogico here if you ask me ;)
TIA & Cheers
does this work?:
Hi pid,
thanks, I tried adding a banger to the preset object that bangs the live.drop after a preset recall. Sadly, it doesn't seem to work either :(
Hmm, reading through the docs again, seems like the live.drop can be set to any filepath by sending a "set" message to the object. So now then, how do I get to output a stored filepath from a preset recall? From there onwards, it should be just a matter of "prepend set" to the path and transmit that back to the live.drop after a preset recall..
Anyone? Please! I'm about to throw my new shiny computer outta the window :((
How can this be so hard? Just a matter of storing and recalling a textstring.. So frustrating!!
Ok, managed to get things working via a pattr hack.. What was strange though, I had to defer the "preset changed" notification coming from the preset object before stuff started working. Still haveto check if that simple "t b" recall trigger would have sufficed too with a deferlow added into the mix.. But I gotta say, damn, Max is hard. The scheduling debugging is a serious pain for someone not used to doing it..