kkll

i'm attempting to build an envelope to send CC information in particular volume.

function -> line~ -> snapshot~ 1 -> change -> ctlout 7

this seems to work well enough in M4L but when i do the same in Max it does not seem to have the same resolution with obvious audible issues.

the M4L is useable, but the Max one is not.

after some testing i've come to the conclusion that "control rate" does not seem to work as i thought :p

when i set the line~ (0 127 127) and put a counter in the mix, i expected the counter to register 128.

however it reported 82 messages in M4L, and 67 in Max.

oh, and when i just used a line object in Max, the counter only went to 7 ..

so, what can i do to make a workable volume envelope ?

i'm attempting to build an envelope to send CC information in particular volume. 

i built one in M4L using
function -> line~ -> snapshot~ 1 -> change -> ctlout 7

this seems to work well enough in M4L but when i do the same in Max it does not seem to have the same resolution with obvious audible issues.
the M4L is useable, but the Max one is not.

after some testing i've come to the conclusion that "control rate" does not seem to work as i thought :p
when i set the line~ (0 127 127) and put a counter in the mix, i expected the counter to register 128.
however it reported 82 messages in M4L, and 67 in Max.
oh, and when i just used a line object in Max, the counter only went to 7 .. 

so, what can i do to make a workable volume envelope ?
thanks.


envelope-to-send-cc-7-volume

i believe that you have not enabled overdrive in maxmsp, which could be responsible for the difference you see (in max4live and pluggo you are always in overdrive)

i see not reason why you would use [line~] with [snapshot~]. you should just use [line] to generate number output.

also, using a grain rate of 1 milliseconds for the output will not only waste CPU, but might also overload most (probably all) midi hardware devices in question. 20 or 30 should be fine. alternatively one could put a [speedlim 25] behind the [line 1], where the values 0 and 127 are excluded from, so that they appear any time, while the rest is limited.

also, using a grain rate  of 1 milliseconds for the output will not only waste CPU, but might also overload most (probably all) midi hardware devices in question. 20 or 30 should be fine. alternatively one could put a [speedlim 25] behind the [line 1], where the values 0 and 127 are excluded from, so that they appear any time, while the rest is limited.

well overdrive doesnt seem to have any effect.

i don't really understand what's happening . i assumed that anything operating at control rate, for example [line] would put out a value at control rate, so i thought (0, 127 127) would pretty much put out 127 values, rather than the 7 i got with my earlier test.

this might not be a problem with most controllers, but with volume it creates very audible artifacts.

so far, i've found using clocker to be the best sounding object. it actually puts out at control rate if set to :)

i will no doubt have to limit it's OP for MIDI. but using speedlim, anything over 3 starts to become audible.

so far, i've found using clocker to be the best sounding object. it actually puts out at control rate if set to :)
i will no doubt have to limit it's OP for MIDI. but using speedlim, anything over 3 starts to become audible.


nope, [line] is outputting at a constant rate, which can be defined as argument.

though when you set that to 1, [line 0 1], it should output 127 values when you send it "127 127", thats right. not sure whats wrong there.

however, i dont think it is a good design to do it like that. you are trying to bind the frequency of generation to the resolution of midi.

even if it is guaranteed that you use it always in high priority mode enabled, i would prefer to treat them independently.

i.e. work in float, then convert to midi: send "0. 1. 127" to [line 0. 1], then do [* 127].

as floatint point will be much easier to perform a logarithmic distortion over the range, among other thing which may be required to control volume.

also look into [slide], which can be helpful building something this.

about speedlim: you are right of course. but when you send data with 1-2 ms over midi, you will easily run into situations where the receiving device wont be able to work with the data in time, anyway.

and remember that this is not exactly a usual process to send envelopes in realtime as midi controller. :)

yes, this volume control is a special occasion :)

line is really not working for me.. no idea why...

if i've copied this code correctly , just a line going into an [itable].

when run the [itable] has maybe 7 points on it.. as shown in the attached picture.

EDIT: makes no difference with overdrive on.

yes, this volume control is a special occasion :) 

line is really not working for me.. no idea why...
if i've copied this code correctly , just a line going into an [itable].

when run the [itable] has maybe 7 points on it.. as shown in the attached picture.
EDIT: makes no difference with overdrive on.


 will output a value every 20ms, but you ask it to output values from 0 up to 127 in 127 ms, so you'll get only 7 steps of ±18 steps (127 / 7). Print the output of line to understand what I mean. If your enveloppe has to be that short, then you'll need to change 

What I see is the expected behavior:
By default, line will output a value every 20ms, but you ask it to output values from 0 up to 127 in 127 ms, so you'll get only 7 steps of ±18 steps (127 / 7). Print the output of line to understand what I mean. If your enveloppe has to be that short, then you'll need to change line's time grain, or work with signals.


i somehow managed to completely miss that [line] has a time grain.. works fine as you say..

i am having a problem though getting [line~] to work, connecting it up similarly as above, it seems to be working at 10ms... but i cant' see any way of adjusting that.

(this is funny, as i mention in my opening post, it seemed to be working at 2ms earlier from triggering a counter 67 times)

lol thanks :)
i somehow managed to completely miss that [line] has a time grain.. works fine as you say..
i'll have to try it out tomorrow.

i am having a problem though getting [line~] to work, connecting it up similarly as above, it seems to be working at 10ms... but i cant' see any way of adjusting that.
(this is funny, as i mention in my opening post, it seemed to be working at 2ms earlier from triggering a counter 67 times)


i guess it is snapshot~ and not line~ causign this. but it is still weird; snapshot~ should work at 1 millisecond, the reference at least doesnt mention a 10 ms limit.

pfft, well i don't know what's happening with my "testing"..

i've just been playing with overdrive, i probably never clicked the audio interrupt option as this seems to fix the [snapshot~] output.

as does playing with the I/O vector size.

pfft, well i don't know what's happening with my "testing"..
anyway.

envelope to send CC 7 (volume)