What does "—" mean?
I’m working on a patch that does some granulation on samples and it is working pretty well so far. One problem I have is when I insert the patch on a second track and load another sample, the one from the first track is replaced too.
I have seen other patches that precede [send] and [buffer] etc names with "—". Does this insure that they will have a unique reference?
I am also using [send] and [receive] inside a poly, with "#0-" to give them unique references. What would be the correct way of doing this in M4L – some kind of combination between "—" and "#0-"?
"—" assures you an unique name for the entire device, "#0" makes sure that the name is unique to the abstraction/poly instance.
Thanks a lot for the info – does this also mean "—" gives parameters unique names when I have serveral instances of the same M4L patch running in Live?
Also I have the really odd problem that if I use "—" in front of a buffer name (as I have seen in Robert Henke’s grainfreeze, for example), I get no sound when running the patch in Live, but if I open the patch in M4L it plays fine.
If I delete the "—" the patch plays fine in Live too, but when using multiple instances of the patch the same sample is loaded in each one. My head is spinning already…
I just found a rather perplexing solution, if anyone’s interested. When addressing the buffer inside the poly~, it is not good to use [sprintf "set ---buffer%d"]. What does work is [sprintf ---buffer%d] and then [prepend set].
Don’t ask me why, if anyone does have a rational explanation for this I would be grateful.
You might want to provide a patch…
If you are having problems with either ‘—’ or ‘#0′, post a simple patch so we can help you out.
I haven’t looked at Robert’s patch, but i’m assuming he is using some poly~ arguments in the main patcher and naming these with the ‘—’ convention. Not sure why he wouldn’t just use #0 inside the poly~ patch, but maybe he needs to refer to these buffers outside of the poly~ context. Should work fine.
Thanks for the help so far.. in the meantime I had a crash while saving and now the whole patch file crashes Max when I try to edit. Fortunately I have some earlier versions and the poly~s. But the calling up of buffers with "—" stopped working again.
I have attached the patch: The buffers are being populated in the top left corner. 2 poly~s down is a patcher called sample_select which should call up the right sound, but does so only when I’m editing in Max.
Ummm.. Live crashed for the umpteenth time, but now on restart the patch is doing exactly what it is supposed to (as far as I can tell). How is still a mystery to me, but I suppose restarting Live occasionally helps when coding.
This patch is a little unwieldy, but taking a brief look at it, it *seems* like it should work. However, the way you are setting the buffer~ and play~ names is a little all over the place, so there may be some initialization issues going on.
If you are still having problems, you will have to take the time to whittle it down to something manageable so we can take a better look at it.
Forums > Max For Live