Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Bug Reports

Reply
 
Thread Tools Display Modes
Old 06-21-2018, 01:06 AM   #1
Brandtsegg
Human being with feelings
 
Join Date: Feb 2015
Location: Trondheim, Norway
Posts: 13
Default Reaper chokes on fast OSC input

Hi,
I have set the Control Surface Settings so that I can receive OSC messages to control Reaper remotely via OSC. This works well and I can use e.g. "/track/1/volume" to control the colume of track 1.
If I send a lot of OSC messsages in this manner, Reaper seems not to be able to process them fast enough. By "fast", I mean sending 10 messages every 5 milliseconds.
When I say in the header of this thread that Reaper chokes, I do not mean that I get dropouts in the audio, just that the automation is not received and processed (which indeed also can make the output sound shoppy, due to discontinuities in the automation). Reaper seems to skip messages if the rate of communication is too high.

My current solution is to lower the transmission rate when I automate a lot of parameters, and this allows things to run relatively smoothly. The problem is that I need to go very low in transmission rate in order to allow enough parameters to be automated. I would very much need to have an update rate of, say 100Hz, and at the same time automate around 50 parameters.
Currently, I find that I can automate 5 parameters at 100Hz. If I go above that I start to get dropped messages and choppy automation. I can use more parameters if I lower my update rate (transmission rate from the software I use to send the messages).

I use Csound to generate and transmit the automation messages, and can provide a simple example if it would help clarify the problem.
Brandtsegg is offline   Reply With Quote
Old 06-21-2018, 02:35 AM   #2
azslow3
Human being with feelings
 
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 797
Default

50 parameters at 100Hz... WOW

Control Surface default (and so csurf examples) is 15Hz. And I guess that was thought for ~10 parameters (fingers). OSC csurf is not open source and it probably does things faster, still I do not think audible frequencies are in the "working range" of it.

IMHO That requires strong synchronization with the audio engine to in general avoid artifacts, for stable practical use all that should be generated within target plug-in. REAPER has parameters modulation concept, including LFO, which allows to cross particular plug-in limitations, but that is "internal" and so has a chance to be precise.

Note that on that "extreme" level many parameters which are normally irrelevant come into play: OSC timestamps, bundle splitting, carrier protocol, the network stack and its settings, etc. Looking at Csound OSC examples, there is no evidence they even scratch relevant topics...

I repeat, just an IMHO.
azslow3 is offline   Reply With Quote
Old 06-21-2018, 04:32 AM   #3
Brandtsegg
Human being with feelings
 
Join Date: Feb 2015
Location: Trondheim, Norway
Posts: 13
Default

Thanks for the feedback. Indeed this is a lot higher than the usual manual control surface usage. Just that, since we can do external automation, it would be nice to also use it beyond the capacity of human manual control. In my case the control signals are derived from audio feature extraction, so that activity in one instrument can control parameters of processing on another track. For this to be responsive in an interactive live scenario, higher update rates are preferable. I already send the analysis data via OSC from several analyzer plugins (analyzing different instruments) to a "mapping bus" plugin, and I see a much higher bandwidth in the OSC communication between those two. The bottleneck appears to be between the mapping plugin and the DAW, when the OSC messages are piped through the control surface signal chain.Iit seems it could be related to the GUI update in Reaper. I assume that the control surface signals will actually update the GUI before effectively applying the automation (just guessing here), and this obviously will slow things down. For such high rates of update as I am trying to achieve, I would gladly allow the GUI to update much less frequently. If the control signals could reach the destination and have effect on the audio thread, the GUI could even just tag along half a second later if need be.

I have tried using MIDI instead of OSC, and it actually seems a bit more responsive. I know, of course my example optimal rate of 50 parameters updating at 100Hz would by far exceed the MIDI bandwidth. So, just saying that I also tried via MIDI and it seems to hold up a little longer (faster) than the control surface.
I also tried similar control surface automation with other DAWs and run into similar problems as I describe with Reaper. So I do not suggest there is a special problem with Reaper. I merely ask if it would be possible to circumvent this limitation. Perhaps an option to disable/defer GUI updates would allow higher rates of automation?

For those interested, there's much more info on my project and the application, with lots of music examples here:
http://crossadaptive.hf.ntnu.no

also, the source for my plugins here:
https://github.com/Oeyvind/featexmod
(not too well documented yet, but I'll help anyone venturing into compiling and using them)
Brandtsegg is offline   Reply With Quote
Old 06-21-2018, 05:38 AM   #4
azslow3
Human being with feelings
 
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 797
Default

Quote:
Originally Posted by Brandtsegg View Post
Thanks for the feedback. Indeed this is a lot higher than the usual manual control surface usage. Just that, since we can do external automation, it would be nice to also use it beyond the capacity of human manual control. In my case the control signals are derived from audio feature extraction, so that activity in one instrument can control parameters of processing on another track.
That is an extra argument to not use OSC for that. Without proper audio level synchronization, the result can be no more then "a prove of concept", in other words just a toy. That is a big problem in all audio/video applications.
From my knowledge there is no proper way to synchronize audio stream with (external) OSC stream. That problem is solvable for audio on hardware level only (dedicated "world clock" or digital audio connections between devices or single clock inside one device). MIDI devices are synchronized to own "MIDI" master with much lower resolution (which f.e. in the DAW can be bound to the audio clock reference). Typical simple implementations of OSC do not have synchronization at all.

So after your explanation, I can only again recommend "in house" solution: REAPER parameter modulation. You can organize it with own "Audio->Parameter" plug-ins (VST with Audio input and MIDI output) or adopting REAPER own "Audio->Parameter" capability on top of own "Audio->Audio" processor. In both cases, that can produce predictable timing since that will work inside "real-time" engine DSP chain, taking into account PDC, anticipative engine and other concepts. External approach (OSC, external MIDI, even at first look most "speedy" shared memory transfers) simply have no chance to do the same. The topic is complex, even audio only external processing made by special hardware with special software and explicit care from all (good pro level) developers is not "simple" (f.e. google UAD and DAWs). DIY approach using not suitable for the purpose technologies will fail there.

Quote:
Perhaps an option to disable/defer GUI updates would allow higher rates of automation?
Only REAPER devs know complete answer, but GUI updates should not influence automations. No one will use a DAW which process GUI with higher priority then RT audio engine
Not RT streams, including control surface operations, also should be lower in priority then RT audio and MIDI.
In my personal observations, that is in fact the case: direct MIDI input into Reaper works smoother then "injected" throw csurf MIDI (at least for "MIDI Learn" I see significant difference). I do not know the ratio between csurf priority and GUI priority, can happened they can disturb each other.
azslow3 is offline   Reply With Quote
Old 06-21-2018, 10:32 AM   #5
Brandtsegg
Human being with feelings
 
Join Date: Feb 2015
Location: Trondheim, Norway
Posts: 13
Default

[QUOTE=azslow3;2003329]That is an extra argument to not use OSC for that. Without proper audio level synchronization, the result can be no more then "a prove of concept", in other words just a toy. That is a big problem in all audio/video applications.

Well, OSC seems to be well adapted as an interface for musical instruments, so it is genrally deemed predictable enough to be used for many control scenarios, and also good enough for musically expressive tasks and low latencies. I am not talking about sample level synchronization. OSC also proves to do the job well in my use case enough when routing the messages directly to a paremeter inside a VST. The lag and lack of bandwidth appears only when we go through the control surface signal chain. This is what leads me to believe there is an extra bottleneck there. I was simply trying to pinpoint this as precisely as possible, hence also the example from my use case. I hope some of the Reaper devs can shed some light on possible causes for the bottleneck.
Brandtsegg is offline   Reply With Quote
Old 06-21-2018, 09:23 PM   #6
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

Quote:
Originally Posted by azslow3 View Post
50 parameters at 100Hz... WOW
Seems like 99,9 % of unnecessary data: repetitions and/or very small changes.

-Michael
mschnell is offline   Reply With Quote
Old 06-22-2018, 12:03 AM   #7
Brandtsegg
Human being with feelings
 
Join Date: Feb 2015
Location: Trondheim, Norway
Posts: 13
Default

Quote:
Originally Posted by mschnell View Post
Seems like 99,9 % of unnecessary data: repetitions and/or very small changes.

-Michael
I do actually filter out very small changes, so insignificant changes are not transmitted and do not waste bandwidth.
Brandtsegg is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 04:13 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.