scheduler and signal chain

Mar 16, 2007 at 7:43am

scheduler and signal chain

In a situation where we attempt to find the limits of sensor measurement, from a udpreceive object arrive thousand values per second. Timer indeed indicates a 1 ms interval between successive events, although these values are the boundary of what timer can measure. Anyhow, the goal is to turn this stream of values into a signal. Connecting udpreceive directly to a sig~ gives a signal from which many values are missing and values are unevenly distributed over time. The missing values could be explained because more ore less only once every signal vector size a value can be added to the signal chain. Making the signal vector size about 1 ms or smaller doesn’t appear to help a lot. I figure this has probably the same reason as why values are unevenly distributed, and that is because values form udpreceive are low on the scheduler thread.

As an aside, concerning scheduler handling, my guess is that this has dramatically changed since 4.6. For instance, turning on both metros in the defer help file totally hijacks my powerbook while in 4.5 this is not a problem. Also many of my patches where scheduler timing played a roll had to be reprogrammed.

My question, finally, is how to do something which would be the opposite of defer, and to hand a dense stream of scheduler events to the audio chain. Or should the values coming over a network being dealt with as audio chunks to start with?
Thanks

_
johan

#30851
Mar 16, 2007 at 9:30am

This clarifies the context of my question:

http://www.koncon.nl/ipsonlab/ipscomp_htm/ipsoncomp_intro.htm

_
johan

#99240
Mar 16, 2007 at 7:02pm

Hi there,

how does biquad~ work internally?

When signals are connected to its inlets, does it
interpolate over 1 signal vector size or are the
signal coefficients updated every sample?

Does it interpolate the coefficients only when signals
are connected to its inlets or also when it simply
receives the coefficients as Max messages?

Thanks for the knowledge.

- Luigi

————————————————————
THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION. ANY UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.
————————————————————

Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.

http://tools.search.yahoo.com/toolbar/features/mail/

#99241
Mar 17, 2007 at 4:22pm

Hoi Johan,

Your setup sounds as a perfectly acceptable one. The idea of an udp stream is that some data can be dropped if there is too much data for a bottleneck somewhere in the chain, but 1000 msgs/sec shouldn’t be a problem. The max scheduler refreshes every 2 ms by default, so by default and with enough CPU power left, every 2 messages will be processed ‘at the same time’.

udpreceive receives in scheduler here, so a ‘deferhigh’ won’t help you. Try this:

#P newex 110 199 26 9109513 print;
#P newex 110 157 19 9109513 t b;
#P flonum 110 75 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 110 93 108 9109513 udpsend 127.0.0.1 1234;
#P newex 110 178 80 9109513 mxj WhichThread;
#P newex 110 136 77 9109513 udpreceive 1234;
#P connect 1 0 5 0;
#P connect 0 0 4 0;
#P connect 4 0 1 0;
#P connect 3 0 2 0;

with overdrive turned on, this prints ‘scheduler’ in my max window.

Did you try to monitor the input of udpreceive with a multislider in scroll mode? Perhaps dsp hasn’t got anything to do with this.

About the dsp part:

If you want to use the sensor data as hearable audio (or need the info at audio rate) you’ll have to provide your circuit board with an analogue or digital audio output and insert the data into max with an adc~.

If you want to use the sensor data to modify a dsp chain (which I assume you do), at a certain point you’ll have to wisely feed the events into the signal domain, which means that you are in fact interpolating between them. I don’t see why you should need a sig~ for that, most dsp modifiers accept floats.

For a more detailed answer you’d need to post a patch.

Hth,
Mattijs

Quote: jvkr wrote on Fri, 16 March 2007 08:43
—————————————————-
> In a situation where we attempt to find the limits of sensor measurement, from a udpreceive object arrive thousand values per second. Timer indeed indicates a 1 ms interval between successive events, although these values are the boundary of what timer can measure. Anyhow, the goal is to turn this stream of values into a signal. Connecting udpreceive directly to a sig~ gives a signal from which many values are missing and values are unevenly distributed over time. The missing values could be explained because more ore less only once every signal vector size a value can be added to the signal chain. Making the signal vector size about 1 ms or smaller doesn’t appear to help a lot. I figure this has probably the same reason as why values are unevenly distributed, and that is because values form udpreceive are low on the scheduler thread.
>
> As an aside, concerning scheduler handling, my guess is that this has dramatically changed since 4.6. For instance, turning on both metros in the defer help file totally hijacks my powerbook while in 4.5 this is not a problem. Also many of my patches where scheduler timing played a roll had to be reprogrammed.
>
> My question, finally, is how to do something which would be the opposite of defer, and to hand a dense stream of scheduler events to the audio chain. Or should the values coming over a network being dealt with as audio chunks to start with?
> Thanks
>
>
> _
> johan
—————————————————-

#99242
Mar 19, 2007 at 1:16pm

Dank you Matthijs for the input. Part of the solution I found in jit.release~

_
johan

#99243

You must be logged in to reply to this topic.