OSC: How quickly can I send? / how long should I listen?

Question

I'm mostly getting the hang of OSC a la Python, but...

I have a Kyma Sound file with a Sound that has eight Multisample Sounds each with their own Level Sound attached, and all feeding into an Output8 sound. Sometimes, I want to change all eight sample indexes, sometimes several levels. (And, sometimes I only want to change one value on one widget.)

It works... most of the time.  However, occasionally, it appears an OSC message is dropped.  Although I haven't personally observed it, I'm being told this happens even when WiFi is turned off and the connection is wired only.

I'm wondering if I should add a wee bit o' delay between messages, when for example, I'm looping though all eight sample indexes or levels, and changing them.  Or should I be creating a bundle instead of sending eight separate "/vcs/..." messages? I haven't learned how to send bundles yet, but my recent progress is making me optimistic that the learning curve won't be too bad.

I've also developed a little debugging program in Python where I can send an OSC messge manually, and decypher what Paca returns to me.  This is working well.  Now I want to incorporate it into my main app, and I'm wanting to know: If I send a message from the app to the Paca, how long should I wait for the response before determining the message was missed and should be resent?

Thanks.

Comments

P.S. Most of the widgets are named "SomePrefix1" through "SomePrefix8". Would it work / would I gain an advantage from dropping the number and then assigning each to a separate channel, then using "/vcs/SomePrefix/8" instead of "/vcs/SomePrefix8/1"?

Answer 1

The OSC protocol is based on the UDP protocol which, unfortunately, does not guarantee the delivery of messages. The messages can be dropped at any point along the path from the transmitter to the receiver of the message, either by software or hardware.

One way to deal with dropped messages would be to periodically send all of the important values, even if they have not changed. (Kyma Control does this for note-off events for the Keyboard and Tonnetz tabs).

You can reduce the likelihood of dropped UDP messages by not sending too many messages or too much data. In your particular case of mixing levels, sending updates at around 10-100 times per second should be more than sufficient, especially if you use the Capytalk smoothed message on the level EventValues and turn on linear interpolation in the Level Sound used in the mix.

There is a special message in the Kyma OSC protocol (http://www.symbolicsound.com/Learn/OpenSoundControlImplementation) to reduce the amount of data being sent: the

⇒ /vcs,if...

eventID1, value1, ...

Change the value of one or more VCS widgets

message is the most efficient way to update as many as 256 values in one message. You would use the

⇒ /osc/widget,i

index

Request description of a VCS widget

message to obtain the EventID for each widget in the currently active Sound.

 

Comments

Thanks for this, I apologise for misleading answer, I have not seen any examples of Bundles in Kyma, and it remains a little confusing.

SSC, please can you post an actual example of this /vcs,if message syntax and construction?

---

Thanks. I was aware of the UDP basis for OSC and caveats that result from UDP. Hence my question. I'm currently not using any CapyTalk in the Sound.  You've given me several avenues to explore.  This should keep me out of your hair for a while... ;-) The Python program I use to monitor goes out and collects all the widgets using /osc/widget,i and places all of the ones with a concreteEventID in a list of dictionaries, keyed on the on the concreteEventID.  So, switching from "/vcs/HotParamLabel/1,value" to "/vcs,concreteEventID,value,concreteEventID,value,..." sounds like the direction I need to go.

Answer 2

In my experience Kyma is very fast with OSC and doesn't drop packets like, say Processing does. You don't need to make a bundle, as Kyma doesn't really respond to Bundles. Kyma can respond to and send Arrays though. Until we have a native OSC monitor in Kyma showing us what its listening to and what its sending (which would be very very useful @SSC ) , I rely heavily on OSCulator by Camille Trouillard to rewrite and shape messages. I construct large router documents in OSCulator for doing the correct handshaking/subscribing procedures that Kyma requires... its been a life saver on many projects.  For example, https://www.youtube.com/watch?v=Uo_KIx7aHuk

I had to send many 100s of messages, and I needed to write a program that could send the correct pattern format first to an OSCulator document. From there I was able to construct a 'Pattern Subscribe' router to Kyma from OSCulator that I needed to run everytime I powered up the Pacarana and connected it to the network, before it would send any data at all.

Comments

Bundles are part of the standard OSC protocol, so there should be no reason not to use Bundles if you need them. However, /vcs,if... is by far the most efficient way to control several independent widgets at the same time.

For those who are not familiar with OSC, a Bundle is when you put several OSC messages into a single UDP packet. When the Paca(rana) receives a Bundle, it processes one message at a time (though ignoring timestamps), just as if you had sent them separately.

---

My implementation is pure Python. No CapyTalk. I have written both my main application (a GUI using the Qt framework as implemented by PySide), and a separate monitoring program that both listens for responses from Paca -- displaying human-readable responses in the Terminal window, and allows one to send messages by typing them as OSC messages, e.g. "/vcs/hotparam/1 0.5". I looked at OSCulator when I was first trying to understand OSC, but didn't purchase, because at that point, I wasn't sure how it might help me.  I may go back and have a second look.