Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER General Discussion Forum

Reply
 
Thread Tools Display Modes
Old 02-15-2020, 03:25 PM   #1
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default Control Surface capture rate increase possible ??

The capture speed was increased a few years ago, but it’s far, far behind what Protools captures from the same devices with the same connectivity.

Justin , Schwa , can the capture rate for stuff like faders be at least tripled or more ?

My goal is to get a similar capture resolution as the on-screen controls on the TCP/MCP. I’m not sure ethernet controllers can be matched, but the amount of data and the delay from controller to volume change during capture has to improve.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 02-17-2020, 02:54 AM   #2
azslow3
Human being with feelings
 
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 797
Default

What you use for "Control surface display update frequency" (default 15Hz)?

DAWs have zero influence on "capture rate", devices send updates when they want. But DAWs process incoming messages using different methods, also concrete REAPER surface plug-in can choose to use different approach. Finally, once required change is submitted to the DAW, the DAW is free to apply it with some delay.

By default, REAPER propose to process surface messages using some "rate" (periodically checking for new messages). So they are not processed once received. When parameter changes are applied I do not know (have not tested, but I guess it is on audio buffer border).

Yet another topic is how changes should be interpreted. That is defined by "envelope points shape" (there are global and track settings for recording envelopes). If set to "square", ramping up/down can produce significant "steps" when points rate is low. But when set to "linear" (or some other), concrete points have low influence on smoothness (more the subject of plug-in format and concrete implementation, plug-ins can apply one value per buffer, and in case the buffer is huge the result will have "steps" no matter what the DAW think the shape should be).
azslow3 is offline   Reply With Quote
Old 02-19-2020, 03:11 AM   #3
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

I figured the update frequency only affected displays on the control surfaces and nothing else. I had heard that higher frequencies produced problems but that was a long time ago.

Might have to give that a go, but it does seem to be more of a Reaper internal thing.

They did triple the 'speed' of control surface capture or something a few years back. That did improve things.

To be clear, I do not expect plugins to react instantly with anticipative processing active.

I do expect volume changes, i.e. the last thing in the chain to be as instant(i.e. buffer size) as possible.

And that just is not the case, because I've had better in 2004 on a MacOS 9 PowerPC running TDM cards. Their latency has been equivalent to about 128 samples buffer size I'm told. The Procontrol optical faders were the quickest back then. Using a midi control surface like the MCU or its predecessor did increase the latency significantly, but Reaper is worse than that. I've used Protools and Reaper for many thousands of hours with midi-based control surfaces, and Protools does better for volume rides with more accuracy and no detectable difference between the capture phase and the playback phase. Reaper presents differences here, though I do admit I could be biased and misinterpreting things. I'd have to record the live output to be sure, which I will do.

The latency problem however is so significant, I really would appreciate the developers taking a look.

Flicking your finger on the fader down three to four times in a second is a vastly different experience on PT and Reaper when using midi-based control surfaces.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 02-19-2020, 03:32 AM   #4
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

Wow! The problem is more significant than I had anticipated. I'm running at 256 samples buffer size, which is about on par for really large sessions.

Here is a session of source audio and resulting audio from simply running a fader up and down on one track.

https://www.mediafire.com/file/w7dnm...sts_1.rar/file (7 MB)

An overview shot is available here https://imgur.com/a/J9Gfzl8

A shot of a zooomed in area is displayed below.

They've all been sample accurately lined up.

The upper most track with audio carries the original audio and the volume envelope.

The track in the middle is the live output of Reaper recorded with the save live output to disk function.

The lower track is the playback of the recorded volume automation, recorded with the save live output to disk function.

We're not talking about ONE BUFFER LENGTH, but several thousand samples latency. Please do feel free to check these results with audio of your own.

The difference between what I'm hearing while running the fader and what is being played back is too significant to ignore now.

__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom

Last edited by airon; 02-19-2020 at 03:37 AM.
airon is offline   Reply With Quote
Old 02-19-2020, 03:52 AM   #5
uksnowy
Human being with feelings
 
uksnowy's Avatar
 
Join Date: Feb 2008
Location: 6950 DK
Posts: 659
Default

subscribed. I need to follow this..
__________________
REAPING HAVOC SINCE 2008
uksnowy is offline   Reply With Quote
Old 02-19-2020, 03:55 AM   #6
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

So, what is the significance of this data ?

Reaper is taking too long to do something with the volume data.

Can I change this with a change in preferences ? Is so, where ?

Would compromises need to be made to accomodate automation-heavy users ? What would those be ? Can this be done, because this isn't good enough for accurate mixing.

Time to kick open this door gents and see what can be done.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 02-19-2020, 06:16 AM   #7
azslow3
Human being with feelings
 
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 797
Default

First of all, these are 2 different topics. Lets keep them separate.

-----------------
Your first question was about converting physical operations on Surface into automation points. So about the delay between physical movement of the fader and resulted automation point (and the maximum "rate" of these points).

I think I have explained that already.


Quote:
Originally Posted by airon View Post
I figured the update frequency only affected displays on the control surfaces and nothing else. I had heard that higher frequencies produced problems but that was a long time ago.
Since in REAPER's MCU support code (and sources never lie...) MIDI input processing is done at the same place as display update, I guess that "update frequency" affect both.

But you can check: try to record automations from (fast) fader movements with "1"/"15"/"50" setting and check the rate of resulting automation points. If you see obvious difference, I am right. If not, I am wrong

-----------------------------------

Your second point is HOW registered automation is applied to the audio.

Anticipative processing. In case it is enabled, your live (but not playback) automation will be delayed. That is perfectly in sync with your observation (and I have just checked locally it works that way).
Why? I guess because complete audio is prepared "in advance". REAPER does not "update" already prepared audio, so you get the delay.

That is easy to solve, exclude the track from anticipative processing or reduce anticipative time to some reasonable number (f.e. 50ms). In the second case you still will have difference in "live" vs "playback", but only by the amount you set.

With PDC it can be more complicated (I have not checked). From my observations, REAPER adds PDC to anticipative time. That way tracks with PDC can have much longer preparation time then specified in the settings (there are plug-ins with up to 1sec PDC, also note that REAPER quantize PDC of each plug-in in the chain to current buffer size (not the sum of PDC, f.e. if you have buffer 20ms and 2 plug-ins with 1ms PDC, you get 40ms REAPER PDC, not 20ms as you could expect and not 2ms as in some other DAWs...).
azslow3 is offline   Reply With Quote
Old 02-19-2020, 12:51 PM   #8
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

I did try 30 and 60 Hz which made no difference at first glance.

I actually tried a second and third time in the same session. Those two instances had over 20.000 samples of latency, whereas the first sat at around 3500-4000 samples.

At 48kHz that's 73-83ms and then 417 ms. Weird, but another test revealed the problem.

The test was run at an anticipative render ahead time of 1000 ms, which coincided with another increase of in the time difference between live input volume control and the resulting output of Reaper. It was also in the range of 1000 ms(48000 samples).

Thank you for pointing out this possibility. It certainly cut down on the time it may have otherwise taken to reach this conclusion.

One might think this has to be done for reasons unkown to us.

Another test in trim/read mode revealed that that particular volume control has almost no latency.

Conclusion
The envelope-driven volume of a track in Reaper is applied in the anticipative render-ahead of the mixing engine, but the trim/read, i.e. non-volume-envelope-driven track volume is applied after the anticipative processing.

Consequence
Depending on session size, this can make Reaper less usable or pretty much very unusable for precision mixing work that involves fast fader rides, which was a sneaking suspicion that I wrongly thought to be the result of Reapers midi-control-driven volume control, but has now revealed itself to be a fundamental strategic flaw in Reapers engine. That's how problematic I regard this as, because I got better control-surface to audio volume control latency in Protools 20 years ago.

Adding a processing block of latency because of some routing complexities or envelope interpolation is understandable, but this is rather bad. We're talking about ONE extra multiplication that Reaper seems to handle just fine for the trim/read control and even with an extra processing block added I do expect better than shuffling this one task in to the "process FX" queue of the rendering engine, because this tasks is at the users direct fingertips more than anything else.

Proposal
Put (post-fx)volume envelope processing in to its own block, AFTER the anticipative fx processing, so control-to-volume latency during envelope recording is minimized.

I could mix dialogue without a compressor in Protools, and still can with both midi-based(bit less) and ethernet-based controllers.

Dear developers, can you think of a reason this could not work in Reaper ?

I sure fucking hope not , so please take a look at this at your earliest convenience if you please.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom

Last edited by airon; 02-19-2020 at 01:01 PM.
airon is offline   Reply With Quote
Old 02-19-2020, 03:51 PM   #9
azslow3
Human being with feelings
 
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 797
Default

ProTools (probably, but Cakewalk for sure) simply do not have anticipative processing. Disable it in REAPER and you should get close to the same behavior concerning envelope recording.

I think good proposal to have a flag with "Switch to real-time when some envelope is in Write mode". So, the same as in case of track arming.

For surfaces that is different story. I am surprised you have not observed the change, but by 30-60Hz you just should see more envelope points (in case they are not "auto-reduced", there is such option). I really propose compare 30Hz with 1Hz. I will do this when back at home (I am far away now).

But I also do not understand why REAPER does not process surface messages in (near) "real-time" (as MIDI) and in examples (== standard surface modules) has cycle based approach.
There is related general design problem (I have mentioned it long time ago... f.e. REAPER can not work good with Ableton oriented controllers because of that design).
azslow3 is offline   Reply With Quote
Old 02-20-2020, 05:28 AM   #10
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

Just given that a go as well.

1 Hz, 30 Hz. That had not made the difference. On one track with audio Reaper performed identically when recording automation in terms of point density.

However, there was a difference when there was more than one track. Everything in the Buffering preferences is on something close to default, including the anticipative FX. Here too, the control surface refresh rate made no difference(tested with 1Hz,15Hz and 60 Hz).

Check out the screenshot below. The tracks are IDENTICAL. I tried both with and without heavy-handed plugins.

I recorded the first pass, then duplicated the track, cleared the volume envelope and recorded a new pass on the second track.

Look at that shit on the second track. That has to be a bug ladies and gentlemen.

I think I've narrowed it down too. I'll post in the bug report forum about this.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom

Last edited by airon; 02-20-2020 at 05:45 AM.
airon is offline   Reply With Quote
Old 02-20-2020, 06:07 AM   #11
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

I've posted a bug report about this problem here:

https://forum.cockos.com/showthread.php?t=231810

It has all the details plus more screenshots.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 02-20-2020, 04:25 PM   #12
azslow3
Human being with feelings
 
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 797
Default

Quote:
Originally Posted by airon View Post
Just given that a go as well.

1 Hz, 30 Hz. That had not made the difference. On one track with audio Reaper performed identically when recording automation in terms of point density.
Well, I have also checked and got the same result. No difference.
Then I have found: https://forum.cockos.com/showthread.php?t=193160

So REAPER just call Run (read/write in Mackie code) with 30Hz, independent from specified setting. So I was wrong, this setting has no influence on control surfaces read/write rate (I have thought it should since Cakewalk also has such setting, and it is really used for Run rate... apart from async input and throughput aware output).

---------

I do not have touch sensitive faders, with pan automation and Mackie plug-in I could not reproduce.

In your report you mention "MCU/CSI". Does that mean you have tried with native REAPER Mackie plug-in and CSI or just MCU and Presonus with CSI? In the later case, that can be CSI bug...
azslow3 is offline   Reply With Quote
Old 02-21-2020, 12:41 AM   #13
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

I tried both.

I got these kind of shapes before but I had always wondered where they came from. In particular two identical points right next to each other. Weird stuff.

It must be a bug in the controller plugin API. They’ll likely find it fairly quickly. Protools never had this problem and I worked on midi-cable MCU units back then, so it can’t be a bandwidth problem.

Now I need to prepare the request for placing the volume envelope processing outside the anticipative processing. Turning that antipative processing off is not viable, though keeping it to about the same as the max plugin delay compensation might be.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 02-25-2020, 06:36 AM   #14
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

The envelope recording issue turns out to be a possible problem with the unit itself, and NOT Reaper. I've had no confirmation from other Faderport users yet but I've asked folks to check for this issue as well here in the General forum section.

I've posted a feature request for moving the volume envelope processing out of anticipative processing.

https://forum.cockos.com/showthread.php?t=232003
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 02-25-2020, 09:06 AM   #15
azslow3
Human being with feelings
 
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 797
Default

Cheapest "MCU compatible device" is TouchDAW (for tablets). I remember there was demo. You can try it to check the problem is general or device driven (I am still far away from the place I can check myself).
azslow3 is offline   Reply With Quote
Old 02-26-2020, 12:52 AM   #16
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

I've eliminated USB cables or hubs as the culprit. Checked chipset drivers.

I need to try this on another computer too.

If I don't get a reply from Presonus by the end of the week, or any confirmation from other Presonus users, I'm taking the unit in for repairs.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 02-26-2020, 01:31 AM   #17
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

Even with perfectly working USB, same might well be the culprit.

It's known that Midi via USB imposes real-time latency.
- The Midi messages are sent via USB without any individual timing notification
- USB will collect a number of messages into each transfer block to communicate the blocks.
- As the PC receives complete blocks, the first changes in a fade will instantly be overridden.
- Supposedly a block is sent whenever a max block size is reached or when there is a time gap between the bytes.
- I don't know how the size of that time gap is determined or if that value can be configured (at the PC and/or the device) . It seems "natural" to assume something like twice the time for a byte with plain old 32 KBit 5-Pin Midi (-> 625 uSec)

-Michael
mschnell is offline   Reply With Quote
Old 05-02-2021, 03:47 PM   #18
DeBased
Human being with feelings
 
DeBased's Avatar
 
Join Date: Jun 2010
Location: UK
Posts: 412
Default

Hi, did you ever find out more about this? I have a new way you can test for surface automation quality, it should be available to play with in a week or so.
__________________
Reaper5, Win10Pro, Ryzen 5950x/64GB, RME UFX/BabyFace Pro, Behringer X-Touch
- my true 'global' (project-tab independent) Send/Receive FX
- my Behringer X-touch mods + XCtrl mode for CSI (coloured scribble strips!)
DeBased is offline   Reply With Quote
Old 05-02-2021, 04:26 PM   #19
valy
Human being with feelings
 
Join Date: Jan 2020
Posts: 1,927
Default

I'm also curious to know what came of this.
valy is offline   Reply With Quote
Old 05-08-2021, 07:26 AM   #20
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

Presonus opened a ticket, and later passed this information on to the product team. But at the same time the pandemic hit full force, so I'm not sure what happened.

In addition to this problem there is also the 'recording latency' of automation problem in Reaper, including track volume automation.

Interpolation could help. Fixing the latency problem could help a bit as well.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 05-08-2021, 11:06 AM   #21
valy
Human being with feelings
 
Join Date: Jan 2020
Posts: 1,927
Default

Thanks for the update.
valy is offline   Reply With Quote
Old 05-09-2021, 01:34 AM   #22
inertia
Human being with feelings
 
Join Date: Oct 2013
Posts: 800
Default

I don't think the delay is exclusive to Reaper. I don't have the code to hand but I think there is also a delay in the controller driver loop to stop the device being overloaded with commands.

When I was programming my own Faderport driver I was getting progressive slow down because the Faderport was being overloaded and needed a delay.
inertia is offline   Reply With Quote
Old 05-09-2021, 09:41 AM   #23
valy
Human being with feelings
 
Join Date: Jan 2020
Posts: 1,927
Default

Quote:
Originally Posted by inertia View Post
I don't think the delay is exclusive to Reaper. I don't have the code to hand but I think there is also a delay in the controller driver loop to stop the device being overloaded with commands.

When I was programming my own Faderport driver I was getting progressive slow down because the Faderport was being overloaded and needed a delay.
But he said that the delay wasn't occurring in Pro Tools with the same device?
valy is offline   Reply With Quote
Old 05-09-2021, 10:19 AM   #24
inertia
Human being with feelings
 
Join Date: Oct 2013
Posts: 800
Default

Quote:
Originally Posted by valy View Post
But he said that the delay wasn't occurring in Pro Tools with the same device?
I was slightly unclear. What I meant was it wasn't maybe just a problem with stock Reaper code but the surface control driver that is a module within Reaper to control the surface.
inertia is offline   Reply With Quote
Old 05-09-2021, 11:18 AM   #25
valy
Human being with feelings
 
Join Date: Jan 2020
Posts: 1,927
Default

Quote:
Originally Posted by inertia View Post
I was slightly unclear. What I meant was it wasn't maybe just a problem with stock Reaper code but the surface control driver that is a module within Reaper to control the surface.
Oh, so because PT uses HUI protocol (I assume) it's somehow more efficient or whatever? Makes sense, although I know nothing about the inner workings of these drivers -- but I can imagine the scenario.
valy is offline   Reply With Quote
Old 05-09-2021, 11:19 AM   #26
valy
Human being with feelings
 
Join Date: Jan 2020
Posts: 1,927
Default

If it's a case of the controller being overloaded, does the option to reduce automation points help at all? Or is that completely unrelated to the issue at hand?
valy is offline   Reply With Quote
Old 05-09-2021, 10:13 PM   #27
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

Nah. The Presonus issue in this particular case is that the controller sends controller data at a very low rate once faders are moving at all, I.e. data is being sent to the controller.


The latency issue I mentioned via the link is unrelated to any particular device. The issue there is that Reapers automation recording is uncompensated, unlike audio recording. So whatever your anticipative render-ahead buffer is(200ms default), you‘ll hear the effects of your changes with latency during recording, and without when simply playing back.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 05-10-2021, 12:46 AM   #28
valy
Human being with feelings
 
Join Date: Jan 2020
Posts: 1,927
Default

Sounds like several unrelated problems conspiring to make riding faders laggy in REAPER.

As such, I'm not hopeful for a solution.
valy is offline   Reply With Quote
Old 10-28-2022, 09:28 AM   #29
Reaktor:[Dave]
Human being with feelings
 
Reaktor:[Dave]'s Avatar
 
Join Date: Jun 2010
Location: Berlin
Posts: 563
Default

Regarding the capture rate of the faders, the problem is that the rate is too low at which REAPER asks a control surface plugin to process the midi event list. It's happening at roughly 30ms (v6.68). The control surface plugin is being woken up every 30ms, finds let's say five MIDI events from a single fader movement in the list and now either squeezes all five at the same position or discards all but the latest.

This negatively impacts the timing resolution of a REAPER control surface plugin compared to directly accessing the device's MIDI data and I've started a thread about that here: https://forum.cockos.com/showthread.php?t=272125

Maybe there's a workaround or the REAPER devs can increase the rate at which a control surface plugin is requested to process incoming MIDI events.
Reaktor:[Dave] is offline   Reply With Quote
Old 10-28-2022, 09:39 AM   #30
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

Maybe setup per device or CSurf.

I use CSI for my faders, and although it's not bad, my biggest concern no longer is the capture rate. That can never be as good on midi devices as it is/was for LAN-connected control surfaces. Zero contest from the start. I used Pro Control in 2001 and the original HUI controll surface in 2007, and what the jumping jack fu** of a slow down that was. Analog->consumer crap level downfall, BUT it was constant and I could work it.

Reaper has this giant shit turd of a recording(not playback!!!!!!!!!) problem for automation.

When recording, you hear
system latency + anticipative FX processing
When playing the recorded data you hear
system latency
So great, and they're so silent on this issue that I just gave up. They cannot change it or they don't understand it or they don't care(unlikely).
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 10-28-2022, 11:03 PM   #31
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

Quote:
Originally Posted by Reaktor:[Dave] View Post
Regarding the capture rate of the faders, the problem is that the rate is too low at which REAPER asks a control surface plugin to process the midi event list. It's happening at roughly 30ms (v6.68). The control surface plugin is being woken up every 30ms, finds let's say five MIDI events from a single fader movement in the list and now either squeezes all five at the same position or discards all but the latest.
As with Midi transfer, the latest state (i.e. the one the movement stopped at) always is the one that holds, resolution is not affected by timing.
-Michael
mschnell is offline   Reply With Quote
Old 01-24-2024, 06:28 PM   #32
LetsGoBrandon
Human being with feelings
 
Join Date: Oct 2021
Posts: 17
Default

Have the devs taken a look at this yet? According to reaper_plugin.h (header for various virtual interface definitions and structures for reaper c++ api), reaper indeed executes a control surfaces run function at 30 event frames a second.

Code:
/*
** Control Surface API
*/

class ReaProject;
class MediaTrack;
class MediaItem;
class MediaItem_Take;
class TrackEnvelope;

class IReaperControlSurface
{
  public:
    IReaperControlSurface() { }
    virtual ~IReaperControlSurface() { }
    
    virtual const char *GetTypeString()=0; // simple unique string with only A-Z, 0-9, no spaces or other chars
    virtual const char *GetDescString()=0; // human readable description (can include instance specific info)
    virtual const char *GetConfigString()=0; // string of configuration data

    virtual void CloseNoReset() { } // close without sending "reset" messages, prevent "reset" being sent on destructor


    virtual void Run() { } // called 30x/sec or so.


    // these will be called by the host when states change etc
    virtual void SetTrackListChange() { }
    virtual void SetSurfaceVolume(MediaTrack *trackid, double volume) { }
    virtual void SetSurfacePan(MediaTrack *trackid, double pan) { }
    virtual void SetSurfaceMute(MediaTrack *trackid, bool mute) { }
    virtual void SetSurfaceSelected(MediaTrack *trackid, bool selected) { }
    virtual void SetSurfaceSolo(MediaTrack *trackid, bool solo) { } // trackid==master means "any solo"
    virtual void SetSurfaceRecArm(MediaTrack *trackid, bool recarm) { }
    virtual void SetPlayState(bool play, bool pause, bool rec) { }
    virtual void SetRepeatState(bool rep) { }
    virtual void SetTrackTitle(MediaTrack *trackid, const char *title) { }
    virtual bool GetTouchState(MediaTrack *trackid, int isPan) { return false; }
    virtual void SetAutoMode(int mode) { } // automation mode for current track

    virtual void ResetCachedVolPanStates() { } // good to flush your control states here

    virtual void OnTrackSelection(MediaTrack *trackid) { } // track was selected
    
    virtual bool IsKeyDown(int key) { return false; } // VK_CONTROL, VK_MENU, VK_SHIFT, etc, whatever makes sense for your surface

    virtual int Extended(int call, void *parm1, void *parm2, void *parm3) { return 0; } // return 0 if unsupported
};
This is needlessly slow, and I think if more people knew about this, reaper would get some serious negative press by the control surface crowed.

I suggest Reaper increase it to at least 60 fps, or perhaps make it a configurable setting per surface. If this is a difficult issue, then I strongly suggest the reaper team refactor the timing data structures.

This would be the proper way to code, and I know full well the Reaper team can properly code.

Or they already fixed it and I look like a dunce.
LetsGoBrandon is offline   Reply With Quote
Old 01-25-2024, 12:24 AM   #33
DeBased
Human being with feelings
 
DeBased's Avatar
 
Join Date: Jun 2010
Location: UK
Posts: 412
Default

Well, I hacked a control surface plugin to overdrive the surface updates massively. The biggest reason I wanted this is because hardware faders are updated way too slow, resulting in them being super noisy as they grind step, step, step. with my hack, they turned butter smooth and super quiet, literally night and day.

the problem is, I did this with a thread which is unreliable, and although it works very well for the faders, it did mess up the control surface's lighting randomly - especially as I also did lots of fun light and fader animations for a 'screensaver' when you didn't touch it for a while.

So yes, Reaper should absolutely make this configurable. And devs, please don't just hard-code an arbitrary higher rate, but let users actually configure this to whatever they want.
__________________
Reaper5, Win10Pro, Ryzen 5950x/64GB, RME UFX/BabyFace Pro, Behringer X-Touch
- my true 'global' (project-tab independent) Send/Receive FX
- my Behringer X-touch mods + XCtrl mode for CSI (coloured scribble strips!)
DeBased is offline   Reply With Quote
Old 01-25-2024, 05:44 AM   #34
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

Quote:
Originally Posted by LetsGoBrandon View Post
Have the devs taken a look at this yet? According to reaper_plugin.h ... 30 event frames a second.
In what cases do you think that matters ?

If you e.g. run a volume control from a CSI input, you need to do smoothing (limiting the frequency content of the control signal), to avoid zipper noise and other audible artifacts. hence processing that stream (before actually using it in the volume control algorithm) with hogher frequency does not make much sense. If using it for stuff like play/stop doing this faster than LF audio also does not make much sense.

@DeBased:
Yep: motor Faders.
I use (and hacked myself) a configuration similar to a CSI thingy running a Midi stream through Reaper connected to a XTouch Compact via USB at one site and a XR18 via (USCIIBot and) OSC/Ethernet in the other. Here everything is event driven, not pulled. (Midi in Reaper Tracks is known to be very low latency). Nonetheless the motor faders seem "noisy" and "steppy".

Last edited by mschnell; 01-25-2024 at 05:54 AM.
mschnell is offline   Reply With Quote
Old 01-25-2024, 06:09 PM   #35
LetsGoBrandon
Human being with feelings
 
Join Date: Oct 2021
Posts: 17
Default

Quote:
Originally Posted by mschnell View Post
In what cases do you think that matters ?

If you e.g. run a volume control from a CSI input, you need to do smoothing (limiting the frequency content of the control signal), to avoid zipper noise and other audible artifacts. hence processing that stream (before actually using it in the volume control algorithm) with hogher frequency does not make much sense. If using it for stuff like play/stop doing this faster than LF audio also does not make much sense.

Why is it set at 30hz? Nobody needs a logical reason to want to configure the polling rate. They should be be able to set it to whatever they find works best.

Handling transient spikes due to rapid parameter changes should be the job of the API user, so it should be in your own code.

What you SHOULD do is make the value configurable. And the polling behavior should be dictated by the propgrammer. For instance, you can set it up so that if x amount of time has gone by since the last IO read, your logic gets triggered instantly as an event, but the next event can only occur after x amount of time. So if a particular queue has data on it, the event immediately triggers as long as no event preceded it less than x time ago.

Thats how it should be done. But instead, the polling is done for you, which is an improper standard.
LetsGoBrandon is offline   Reply With Quote
Old 01-27-2024, 03:09 AM   #36
ajaym
Human being with feelings
 
Join Date: Aug 2009
Posts: 210
Default

This is indeed an annoying issue, because when using a control surface, any fader changes often introduce a zipper effect which is distracting. I also tried increasing the refresh rate and was surprised to see this didn't help, so this is definitely an issue that needs to be addressed.
ajaym is offline   Reply With Quote
Old 01-27-2024, 06:59 AM   #37
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

Artifacts when volume is changed are the more annoying the faster the volume change happens. Hence to get a decent result the steepness of that curve needs to be limited directly in the "volume control" algorithm (see ReaPack -> Midi CC Volume for parameters with such an algorithm)
mschnell is offline   Reply With Quote
Old 01-29-2024, 01:19 PM   #38
LetsGoBrandon
Human being with feelings
 
Join Date: Oct 2021
Posts: 17
Default

I have not seen a good argument for setting the polling rate at 30hz.

I think the issue is related to everyone's confusion on what is responsible for the audio that comes out of reaper. Ultimately, I think the only responsibility reaper has for dealing with audio artifacts is making sure it complies with protocol standards for the audio/midi software it wants to host, and giving a toolset to both users and programmers for dealing with those artifacts. Defaults are set so things work optimally for the general case. Everything else should NOT be locked by reaper, such as the polling rate for a control surface.
LetsGoBrandon is offline   Reply With Quote
Old 01-29-2024, 03:10 PM   #39
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

Quote:
Originally Posted by LetsGoBrandon View Post
I have not seen a good argument for setting the polling rate at 30hz.
Polling uses up CPU. And with Reaper, priority is dedicating CPU to audio streams. Hence 30 Hz is a rather obvious compromise.

Last edited by mschnell; 03-19-2024 at 12:36 PM.
mschnell is offline   Reply With Quote
Old 03-19-2024, 10:07 AM   #40
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

Well, I could mix dialogue without a compressor in 2003 with on a Protools TDM system. It was that fast and direct. The same is not possible with Reaper and midi-based controllers so far.

The controller was the Pro Control connected via ethernet and using optical faders. The latency of the system was about the equivalent to 128 samples I'm told. I later mixed with a midi console (the first HUI model) and it had a significantly higher latency. Basically it's a digital mixer controlled by a DAW.

Reaper is ok, but it's below that level by a long shot if you're using any external controllers via midi. The people using EuCon may be better off though. Direct control with the mouse of a fader is very fast and this would be great if the mouse was any good for mixing. It isn't.

In all I rate that aspect of Reaper as 'good enough for most users', but it has some weaknesses and it's not a priority right now to improve those aspects it seems.


Concerning point interpolation and smoothing, Protools can reduce and smooth out points as well, and it does a better job at it than Reaper ever has, having multiple levels of influence as well when recording automation.

Most importantly PT never changes anything outside the location range that you're recording to. Reaper does, which is why I keep its point reduction turned off at all times. Making changes that affect the area outside the recording range messes up plugin data a LOT.

I haven't checked if that's still the case in at least a year though.

-edit-
It's looking better now. First glance at the data suggests it is no longer making that mistake. Good.

One aspect I'd like Reaper to do on a per-device basis is smoothe out the data better. Some hardware produces rather weird data like the Presonus 8/16 controllers, if just one of faders is being made to move. First pass is great on that controller, but if anything moves it gets iffy with data stuttering in. No fast action with that. The X-Touch controllers do a better job at that, even if it's with this huge latency Reaper introduces with the render-ahead buffer.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom

Last edited by airon; 03-19-2024 at 10:21 AM.
airon 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 03:47 AM.


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