jvkr

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?

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.

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

scheduler-and-signal-chain

This clarifies the context of my question:

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

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?

------------------------------------------------------------

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.

Yahoo! Toolbar alerts you the instant new Mail arrives.

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

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?

------------------------------------------------------------
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/


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:

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.

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.

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?

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
----------------------------------------------------


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

scheduler and signal chain