< Back to IRCAM Forum

OSC directly into Spat5 without Max?

Spat
#1

Hello,

I am wondering if there is a way to avoid to pass through Max scheduler when sending OSC messages to spat.oper for source control. The idea is to not be limited by 1ms message limit in Max, without considering that it is potentially slower too (in my tests, udp messages seems to arrive to the next tick of the scheduler).

P.

#2

Hello Paolo,

Not sure I understand your question correctly.

  • everything in Max is governed by the Max scheduler. I dont see how you could avoid it.
  • OSC messages arriving from the outside world via udpreceive (or spat5.osc.udpreceive) inevitably have some sort of delay due to the network layer. Not much you could do about it.
  • with OSC, you can pack multiple messages into one OSC bundle; this might be more efficient for scheduling.
  • GUI objects (like spat5.oper) are more efficient (but not faster) when their window is closed.
  • spat5 DSP objects (like spat5.spat~) always work with a “scheduler in audio interrupt” mechanism : the incoming messages are processed at the beginning of the next audio tick. So, using a smaller “signal vector size” offers a better temporal granularity (at the expense of a higher cpu load).
  • Keep in mind that all spat5 DSP objects internally use smooth crossfades (in the order of 5 to 50 ms), so sending message with much faster rate might just be a waste of cpu resources.

What is your problem or what are you trying to achieve ?

Best,
T.

#3

Hi tcarpent,

thank you for the very clear and informative answer.

spat5 DSP objects (like spat5.spat~) always work with a “scheduler in audio interrupt” mechanism : the incoming messages are processed at the beginning of the next audio tick. So, using a smaller “signal vector size” offers a better temporal granularity (at the expense of a higher cpu load).

I see. So, unless we have signal vector size < 48 (at 48kHz), spat5.spat~ will always process messages after more than 1ms, even if Max messages are sent every 1ms. And, on the contrary, if lower it will potentially process the same value because of the last message received (for istance, with 16 samples signal vector size, last message will be processed 3 times). Am I correct?

What is your problem or what are you trying to achieve ?

No problems fortunately, just want to understand and use the tool in the best way for me. I was thinking about having smoother transitions, thus trying to overcome the Max scheduler.

Regards,
P.

#4

So, unless we have signal vector size < 48 (at 48kHz), spat5.spat~ will always process messages after more than 1ms, even if Max messages are sent every 1ms

Correct.

And, on the contrary, if lower it will potentially process the same value because of the last message received (for istance, with 16 samples signal vector size, last message will be processed 3 times).

Well, each message is processed only once. And if several consecutive messages carry the same value, this will (most often) not trigger any new calculation.

No problems fortunately, just want to understand and use the tool in the best way for me.

That is good practice !

Cheers,
T.

1 Like