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?
Mar 16, 2007 at 9:30am
This clarifies the context of my question:
Mar 16, 2007 at 7:02pm
how does biquad~ work internally?
When signals are connected to its inlets, does it
Does it interpolate the coefficients only when signals
Thanks for the knowledge.
Never miss an email again!
Mar 17, 2007 at 4:22pm
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;
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.
Quote: jvkr wrote on Fri, 16 March 2007 08:43
Mar 19, 2007 at 1:16pm
Dank you Matthijs for the input. Part of the solution I found in jit.release~
You must be logged in to reply to this topic.