sometimes a noticable latency while setting values from Sonic Pi which trigger interface elements on the touchosc app
random malfunctions such as that values sent by Sonic Pi seem not to reach the app
I guess that #1 is somehow unavoidable and will be dependent on how much is going on and how powerful the used devices are; as far as I know I have made proper use of use_real_time. But I wonder whether there are some general tipps or best practices, how to avoid #2 (if not also #1).
Unfortunately the fact that some osc messages sometimes seem not to reach my touchosc app is hardly reproducible. E. g. an LED will be set to 0 during initilization (first run of script; does always seem to work); while using the live looper it shows a recording live loop (set to 1) and is again set to 0 at the end of the loop (followed by a stop); this does not work always. Of course I can not rule out any mistakes I made writing the script but as I get somehow random results I am pretty sure that it should work as expected.
the OSC messages are sent from Sonic Pi via UDP. Unfortunately, by design, UDP is an unreliable protocol. This means that packets may be dropped en route and there’s nothing in the network protocol to detect and fix this.
The solution would be to use TCP. However, this is yet to be implemented in Sonic Pi as it’s a bit more involved (UDP just requires you specify an IP address and port and it just fires the messages off, TCP requires you set up a unique bi-directional channel between each OSC recipient and Sonic Pi).
Unfortunately I’m not sure TouchOSC even supports TCP, so the practical solution for now is to try and use the most reliable network connection which would ideally be wired. I know from experience that different networks have different packet drop-rates.
With respect to latency, this seems odd. If you can find a reliable way of reproducing this, that would be ace. One thing to try would be to send OSC messages to a process running on the same machine. If you see similar latencies, then it’s likely to be an issue with Sonic Pi - if not, it’s likely to be an issue with your network.
well thanks, that explains partly what I experience.
As far as I know touchosc for Android right now only supports wifi connections (not wired, which would be no problem for me). Although there are hints that you can use USB… I’ll look into it.
Concerning TCP I don’t know but as Sonic Pi currently also not uses it it’s no option at the present time.
As to the latency I will try and see if I can isolate the problem.
Martin
I sometimes find that if I am sending a lot of OSC messages to TouchOSC then interspersing some short sleeps can help. It is certainly helpful if one of the devices (probably the computer with Sonic Pi) is hard wired to the network rather than both being wifi connected. Also (on a Mac at least) you can create an direct network link to the TouchOSC device using create network on the WiFi menu.
thanks for the input. I’ll try to figure out whether I can establish a wired connection (possible directly between smartphone and computer via USB) - although I am working with Linux. But I found already some hints that suggest, it might be possible.
As far as I see, I can’t work with sleeps because I have time critical things running (record 8 beats, play the loop right after it has been recorded).
