Forums > MaxMSP

data arrival within a vector?


Roman Thilenius
Feb 19 2011 | 11:59 pm

 
so this might be a silly question, but i want to make sure i am not doing
something wrong.

imagine the following situation: i have two poly~s, and i want to turn one
off while the other one is turned on.

because i dont want glitches in the resulting signal outputs of the poly~s,
i need to make sure that the data coming from, for example [t 1 0], arrives
within the same audio vector.

should it do that already, or is there a chance that the 1 comes late (so that
the signal of the second poly~starts late?)

[t 1 0]
[poly~ signal1] [poly~ signal2]
|
 
 
 -110
 


andrea agostini
Feb 20 2011 | 11:00 am

It depends on your settings, and threading context.
– If your t is working in the main thread, the sequence of events it triggers can be interrupted at any time by the computation of an audio vector
– If it’s working in the high priority thread, AND you have "scheduler in audio interrupt" on, it won’t be interrupted by an audio vector. On the other hand, if you’re asking for too much work to be done after the trigger, your audio might crackle. And if your signal vector size is too high, the timing of your events might not be precise enough.

for more details, have a look at http://cycling74.com/2004/09/09/event-priority-in-max-scheduler-vs-queue/

best
aa


Roman Thilenius
Feb 20 2011 | 2:04 pm

 
yeah, i wouldnt have asked if it was under metro conditions.
 
but in the given case it is triggered by the user, and how much
other work has to be done is uncertain.
 
what would you suggest? [uzi 1] – [t b b] ?
 


andrea agostini
Feb 20 2011 | 6:25 pm

You know, I don’t think there is a way to prevent the evaluation of a message from being interrupted by another thread taking over. this would require a thread-locking system at the patching level, and we don’t have one – not even with a custom external.

the only way is setting "scheduler in audio interrupt", and making sure that [t] runs in high priority. [uzi] won’t do this (if you bang it in the main thread, it will fire in the main thread as well), but [del 0] will.

hope it makes sense…
aa


Roman Thilenius
Feb 20 2011 | 7:02 pm

well i am clear about the sheduler settings and overdrive and in
interterrupt – luckily – are my regular settings anyway in this application.

delay 0 is a good idea, but i really did not know that uzi wont get the
event up in the priority, thanks for clarifiying.

just to make me understand: would a metro recreate the bang in high
priority?
 
-110


Roman Thilenius
Feb 21 2011 | 10:10 am

then why not uzi?


Roman Thilenius
Feb 21 2011 | 7:54 pm

ok thanks guys.

btw:

"This is a critical difference as the defer object
can cause a message sequence to reverse order,
while deferlow will preserve a message sequence’s
order."

lalala …

-110

Viewing 7 posts - 1 through 7 (of 7 total)
Forums > MaxMSP