Packing data with comas (,) to control msp curve object
Hi there , I'm trying to pack AHDS(R) control data to use the curve object inside max msp.
it doesn't pack correctly, because i try to insert comas "," (do we say it like that in english?)
in order to have the start/end values of my curves.
the curve object only receive the number before the comas and the comas. but not the time of the curves in milliseconds and the curve values (from -1. to 1.)
i don't know at all what to use instead of or with the pack object to do that.
here is a screenshot of a part of my "voice" subpatch
i've used "" to insert the ","
You can use sprintf, still using the backslash (,).
sprintf %f, %f (...)
OK but unfortunately using sprintf %f, %f ...
the first float value has no coma after it in the max windows when adding a print object to the out of the sprintf
and the curve object says "bad arguments"
I added an inlet to the sprintf with the %s definition, associated to a message box containing "," and it doesn't work... is the coma strictly necessary?
dont use [pack] at all when a comma is involved.
for "1., 0.1 0.2 0.3" use [pack] for the last three values
and then [t l 1]
This works for me...
If you learn what the comma does, you might realise that you don't need a comma at all...
Commas don't get sent out of a message box (unless you escape them). Connect a message box with comma to a print, click the box and watch the Max window. Mayby that will give you an idea how to compose your data (hint: use trigger...)
Stefan
i used to escape them, but the message is truncated (does anyone know why?) when received by the curve or line object.
After that i tried without comas and it "works" but no attack is heard at all, no matter the length of attack i entered...
I also have a problem of polyphony since I tried to incorporate an AHDSR to my voice patch. when i play notes polyphonically sometimes a note cuts another, sometimes the release function does not work at all.
I just put a counter with an if function to reinitialize the counter and a gate 64 to dispatch the messages to my 64 voice aliases. the print objects are showing my note off messages are sent on the same voice than the note on, but perhaps my note off sending protocol is not ok.
(Should I tell to max to remember the note on message and the channel where it is sent to send the note off message to the same channel?)
In attachment you'll find my patch and subpatches on their current state.
I'm really a beginner so i hope you'll excuse me for the lacks of the patch
Instead of having lots of intsances of your "voice" patch you might want to load it into the [poly~] object which will manage your midi note on/offs if you use the "midinote" message and [thispoly~] to control which instances are busy.
Have a look at Chris Muir's Simple FM Synth to see how it can be done.
lh
no, you did not send escaped comma symbols to your [line] object, thats impossible. nobody ever sends escaped commas to [line]!
wow, you even have a sprintf obejct between the number boxes and your [line], wtf.
unfortunatly a classic ADSR (or in your case, AHDSR) envelope is less straightforward than one might think and more experienced users also have their difficulties with envelopes, when not with the coding, then with making decisions on the machine model.
i would recommend you to play around more with the [line] helpfile because i think you misunderstood a few things about it.
the generic "input format" for a [line] used as audio envelope is always at least 2 messages: first it needs to be told from where to start, and then it exspects another message, which is a list of time/value pairs. (see helpfile...)
your sampler voice will probably start all envelopes at a level of "0.", so you can use just a [0.] or [t 0.] to set the starting point.
try this: use [pak] instead of this silly [sprintf], and connect the outcoming list into the right inlet of a [zl reg].
[zl reg] can be thought of a [f] object but for lists of unknown lenght. when a voice (note on) will be played, it must now first trigger the "0." and then the envelope stored in [zl reg] (or [pack] or [list]).
yeah guys, and once again the messagebox object has managed to trick somebody about how messages work. it is wicked with this {1., 2. 3. 4., hallo} stuff; on the one hand, without numberbox or messagebox it is very difficult to begin with max, but on the other hand, with them, it is difficult to learn how messages work.
it would not have been the first time that i had to explain somebod why a messagebox {1., 2. 3. 4., hallo} does not print "1., 2. 3. 4., hallo" to the console!
-110
fabienaurejac wrote on Sun, 29 March 2009 18:57i used to escape them, but the message is truncated (does anyone know why?)
Because the line~ object doesn't understand commas.
You really,seriously, need to run not walk to Max Basic Tutorial 1. Read the section titled "Commas change everything".