Jerky playback of OSC signal

I am attempting to record and playback an OSC stream, recording appears to work however on playing back the singal is not smooth and is quite jerky.
Attached are two gif showing the UI of the OSC input when recording and the OSC output on playback. I’ve uploaded gifs of the level indicator showing during recording and playback
two-input
two-output
The stream should be outputting messages at around 100-500 Hz but I haven’t verified that. Is two able to cope with that amount of data?

1 Like

Hi and thanks for posting!

While that data rate is quite high for control data (a message every 2-10ms), if it is only a single stream, TWO should still be able to handle it fine - but it’s not really a use-case I’ve tested much before, since control data signals are normally a lot sparser than that.

I recommend sending at a good display refresh rate, so for example 30-60hz. Then, if the value needs smoothing, you can interpolate at the receiving end. Think of the controls in e.g. a VST plugin GUI - they will not send their value to the audio engine at that rate either, but at a rate closer to display rate.

In testing this, I also found two bugs in TWO, since I normally never use it with this high a data-rate per single stream (thank you!):

A: timeline GUI : it would crash, if the lane displaying the keyframes in a clip was visible, meaning it tried to add a key component every 2 milliseconds(!).

So, this, but while recording, would crash:

If I hid the key lane, and only showed the clip lane, it did record however (as evident by the screenshots, so like below):

So, until I fix this crash for high data-rate recording, the workaround will hopefully allow you to keep working.

B: Feedback detection would mute playback even when set to off in TWO’s Global Settings (My default threshold IS actually 2ms :)). The workaround is to set the threshold to 1ms.

IF suddenly TWO isn’t playing back, check the Mute section of your Node - “Feedback detection” might have muted it - As is evident by the Warning in the message bar at the bottom (I could improve the usability of this, it’s not immediately clear that this has happened if you don’t know where to look):

See where it’s muted to the right, with “Output” being ticked? Untick, to unmute.

I also tried playing that recording back to Protokol / my Max patch, and I didn’t see the jumpiness you experience - not even with a Debug build (on my windows machine). Maybe it only happens on macOS?

It sent out all 5000 messages very speedily, and while Max’s console choked up badly, Protokol’s (and TWO’s own console), kept up with the sending!

If you can share your TWO-file do please send it to me, I’d love to test with it directly!
And of course if you’re at liberty to share the software generating the message stream I’d be curious to test with that too.

I will fix these 2 bugs, meanwhile I’d love to be able to reproduce the issue you’re having to make playback choppy, so do answer to the above if you can!

Here’s my test files:
500Hz.zip (60.1 KB)

Best,
Ilias B.

Thanks for testing that out. I changed the source OSC input to another app that I had a better knowledge of the message rate. This is ~100 Hz but for 5 different streams. With this setup recording and playback was working as expected.
After that I retried using the original app and I am no longer seeing the issue. So not sure what was happening. Unfortunately I saved over the original recordings so I can’t get back to the state it was in.

1 Like

Glad to see it’s resolved, regardless!

I’ll do some more testing at high data rates, and address the 2 bugs found in the above process in the meanwhile.

I hope you find TWO useful.

Best,
Ilias B.