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

Reply
 
Thread Tools Display Modes
Old 08-16-2017, 07:45 PM   #1
capn slugo
Human being with feelings
 
Join Date: Sep 2010
Location: NYCishness
Posts: 200
Default transport speed lag while recording is a thing

Howdy folks

Does anyone know if there's a way to bitch slap reaper's transport speed preferences into staying perfectly accurate and NOT slowing down when straining while recording or buffering>?

I'm a multi instrumentalists with a midi rig using several midi and digital audio sources

I'm running several multi output instances of kontakt

They all work and sound work fine while I perform and reaper is idle .....until i go into record ........and then it gets choppy and worse when I play and sustain several notes in succession .

I'm only recording on few tracks.

I can live with poor audio (in kontakt ) while I record but I need the transport speed to be consistent or the music suffers . Attempting running kontakt in another rewired instance of reaper out of desperation to solve this problem after fighting reaper and tweaking kontakt for many years (also wondering if disengaging the transport on the slave instance might help if there's a way to do that)

Playback and render are fine but the speed lag when recording (in note-heavy demanding areas) makes the render go out of sync with video recorded simultaneously on other devices

This is a disaster for trying to play in time with a rhythm track/tempo map ore even the most basic click track.

I'm using windows 7 i7 6 core machine 32 gigs of ram. Scarlett focusrite 18i20
I've spent some time optimizing & consolidating instances of kontakt to run as efficiently as possible, limiting numbers of voices per instrument using fewer instances multi reaper channels limiting memory use and experimenting endlessly with reaper settings.

Any ideas would be a great help - thanks
capn slugo is offline   Reply With Quote
Old 08-17-2017, 03:34 AM   #2
capn slugo
Human being with feelings
 
Join Date: Sep 2010
Location: NYCishness
Posts: 200
Default

another day of this
capn slugo is offline   Reply With Quote
Old 08-17-2017, 11:36 AM   #3
capn slugo
Human being with feelings
 
Join Date: Sep 2010
Location: NYCishness
Posts: 200
Default solved

I just flipped my car over as a dedicated process and lit it on fire as a separate process.
capn slugo is offline   Reply With Quote
Old 08-17-2017, 11:49 AM   #4
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Must say I never noticed this happening, at all.
EvilDragon is offline   Reply With Quote
Old 08-17-2017, 11:59 AM   #5
capn slugo
Human being with feelings
 
Join Date: Sep 2010
Location: NYCishness
Posts: 200
Default

dedicated and/or seprate process & - took project 20 min to load and after it did memory was jammed - took another 20 min to close. Perhaps if you could run dedicated process per specific instance of kontakt. Spent the day attempting to try every option in VST bridging/firewalling.
capn slugo is offline   Reply With Quote
Old 08-17-2017, 12:03 PM   #6
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Right, I don't use dedicated processes unless there's really a need for it (like a crashy plugin - which as it turns out I don't have any).


I wonder, when you're recording, how high is RT CPU reported by Reaper's performance meter?
EvilDragon is offline   Reply With Quote
Old 08-17-2017, 12:06 PM   #7
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 12,561
Default

Here's the thing. You set the latency the system runs with. (In preferences/audio/device in Reaper or disable that and use another audio app.) This is a hard value in samples.

Your CPU can either do the processing you throw at it in that interval or not. If the CPU can't keep up, you get dropouts, slowdowns, etc.

Understand that this isn't some "mode". You are literally crashing your computer because it can't keep up delivering the processing you have dialed up within the block size latency interval you have Reaper set to.

If you stubbornly run the system crashing like this, you will not have any kind of stability. This isn't a small quality hit to "live with" kind of thing. This is a "I'm crashing the computer and all bets are off" kind of thing.

If you are in fact doing live performance and thus require low latency (specifically < 11ms round trip), then you may have hit a wall with your hardware.

If you are not intending to do live performance through plugins and/or running live sound, then we can possibly talk about relaxing the latency setting you are running with if you haven't already done this.


You playing those MIDI instruments live with controllers and such? (needs low latency)
Or programming? (doesn't need low latency)

Controlling your block size from Reaper? Or some other audio app?
What is your block size?

You're not doing any CPU hungry stuff like running the project at a different sample rate than the audio and thus converting on the fly?

Last edited by serr; 08-17-2017 at 12:11 PM.
serr is online now   Reply With Quote
Old 08-17-2017, 12:26 PM   #8
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

I probably missed something (TLDR) but not getting the part about "crashing" and not being able to keep up with the buffer. I'm assuming it's just word choice since a buffer that can't keep up or rather be kept up with isn't going to crash the system/computer.
__________________
Music is what feelings sound like.
karbomusic is offline   Reply With Quote
Old 08-17-2017, 12:44 PM   #9
capn slugo
Human being with feelings
 
Join Date: Sep 2010
Location: NYCishness
Posts: 200
Default

Quote:
Originally Posted by EvilDragon View Post
Right, I don't use dedicated processes unless there's really a need for it (like a crashy plugin - which as it turns out I don't have any).


I wonder, when you're recording, how high is RT CPU reported by Reaper's performance meter?
The truly frustrating part is that the glitching and strain happens regardless of the kontakt patches and how many voices are active. Kontakt runs perfectly stable and preforms GREAT getting slammed with hundreds of notes across many instances WHEN it idle . The total CPU gets up to around 45% and no channel with an instance of Kontakt gets above 2.5 %. It's hard to track for certain with half of the kontakts running in a reaper/rewire.

While recording total occasionally driftsup to 55% with or w/out lots of notes. Even with a few things going on it crunches.
I already have my latency set to the longest setting in my Scarlett 18i20.

I could live with crappy audio while recording but the transport/time thing is killing me.

I suspect that if I could contain the midi routing scheme/actions and plugins I've pined over for years in a completely separate instance of reaper and route that midi fresh into the idle set up hosting Kontakt- I could actually create music again someday. And that leads me to wonder about disabling the transport in the slave instance of Reaper Rewire. - probably wont work but neither has any setting I've ventured into ....

Last edited by capn slugo; 08-17-2017 at 12:56 PM.
capn slugo is offline   Reply With Quote
Old 08-17-2017, 12:55 PM   #10
capn slugo
Human being with feelings
 
Join Date: Sep 2010
Location: NYCishness
Posts: 200
Default

"What is your block size?"

The highest scarlet allows - I can live "late" but when late drifts back and forth to "extremely later" I can't record anything.

2048 is set in Reaper
Scarlett just reads 20.0 ms (but I think it's 2048)
capn slugo is offline   Reply With Quote
Old 08-17-2017, 01:13 PM   #11
capn slugo
Human being with feelings
 
Join Date: Sep 2010
Location: NYCishness
Posts: 200
Default

....also,, Playback/ render work fine but the mix is compromised time-wise because reaper changes speeds while capturing. - a nightmare for making music videos.


I would think there would be a setting that would compromise audio in order to keep perfectly accurate transport time.
capn slugo is offline   Reply With Quote
Old 08-17-2017, 01:24 PM   #12
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

I wonder how the hell you're even recording anything in time at 2048 samples buffer size, live...


This is pretty bizarre, Reaper never ever slows transport down while recording over here, even with lots of tracks. Might be a ReWire thing?
EvilDragon is offline   Reply With Quote
Old 08-17-2017, 04:23 PM   #13
capn slugo
Human being with feelings
 
Join Date: Sep 2010
Location: NYCishness
Posts: 200
Default

https://www.youtube.com/watch?v=yuAZMv9Q1QA

Threw this down so you can see and hear- hitting reaper with a lot of notes - it works fine when idle - when reaper starts recording at : 50 with simple HH click, sound and timing goes to shit//// even at the end where most stuff is pulled out

Last edited by capn slugo; 08-17-2017 at 04:31 PM.
capn slugo is offline   Reply With Quote
Old 08-17-2017, 06:37 PM   #14
capn slugo
Human being with feelings
 
Join Date: Sep 2010
Location: NYCishness
Posts: 200
Default

There's not many tracks in record . The midi for the keyboard track is all on one track (multi midi channels) . It seems that the difference between performance in idle vs. record is exponentially more extreme than it should be. I have a feeling there's a midi routing / merge issue in my template. It takes dozens and dozens of piz midi vsts with tons of custom reaper actions to get my stuff happening how i want it - there's some heavy sh%t going on that took a long time to evolve & I could only get happening in Reaper. I keep thinking I need two completely separate instances with the midi routing segregated feeding the instance that records. If there's a way to do that that besides rewire - any ideas on routing between them would be greatly appreciated.

Either that or somehow keep the kontakt separate in another host like Vienna Ensemble 6 - I'm trying rewire now to host the kontakts but the results are identical to keeping them all in one instance of reaper.
capn slugo is offline   Reply With Quote
Old 08-17-2017, 11:42 PM   #15
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Would've been more useful if you showed Reaper on the screen and its performance meter running, honestly It definitely sounds like the main audio thread is being overloaded (RT CPU close to 100%), which results in dropouts etc.


That's a cool looking instrument, though.
EvilDragon is offline   Reply With Quote
Old 08-18-2017, 07:45 AM   #16
capn slugo
Human being with feelings
 
Join Date: Sep 2010
Location: NYCishness
Posts: 200
Default

Okay - Dig it
https://www.youtube.com/watch?v=UWL96Gb67Q0

I see that the RT CPU is high - I misunderstood this thinking that it was a percentage of the Total CPU being used by the ReWire Track where most of the Kontaks are running.

Now I see this:

"The RT ("Real Time") CPU meter measures the amount of CPU time used by the audio thread servicing the sound device. Since it's measuring a single thread, it reflects only the CPU time used by one core, and gives you an indication of how much leeway you have in processing. If you have anticipative FX enabled (and few tracks record armed), RT CPU will generally be pretty low, as most things should be done asynchronously, allowing the realtime thread to quickly put things together.

-Justin

So my next question might be (as if I even knew what to ask) is there a way, using reaper alone, to route and record midi on a separate thread to get reaper to behave as if it's idle?

I'm starting to feel that I'm destined to have to do this with two separate systems - even with 32 gigs of ram
capn slugo is offline   Reply With Quote
Old 08-18-2017, 09:45 AM   #17
capn slugo
Human being with feelings
 
Join Date: Sep 2010
Location: NYCishness
Posts: 200
Default

Now I'm finding that just running the transport in play with midi routed (without arming tracks routed to kontakt) STILL maxes out the CPU the same way - NOT listening back to recording but playing with transport running with 1 track click.


This is one of those times when I desperately wish Reaper would simply distinguish between "tracks" (midi OR audio)and mixing/monitoring "channels"(midi OR audio)

I strongly believe they should function completely independently like a tape machine and a mixing board.

I don't understand why they're conflated together in a cluster that slaves all reapers "tracks" (data or audio streams) and what SHOULD be independent audio or midi "channel" ( data or audio pathways)that function independent of the transport.

I could work around this in a second if only there was an option to have reaper route the midi and audio while ignoring the transport. Then I could record the (midi W/out it being monitored or routed to kontakt /route it by later by simply unmuting).

Last edited by capn slugo; 08-18-2017 at 12:02 PM.
capn slugo is offline   Reply With Quote
Old 08-18-2017, 12:02 PM   #18
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

MIDI cannot work separately to audio, because it drives your virtual instruments. Also MIDI and its routing is not what's taking your CPU - it's all the virtual instruments you have loaded. Any armed track you have when you're recording, gets sent to just one core of your CPU, no matter how many cores you have, in order to have faster processing. But when you load too much, it will overload the core and you get the results that you have.

Also note that ALL SENDS connected to an armed track are also processed on that same core. If that's some heavy reverb plugins, well, we've found your culprit. I see you have nearly 3000 plugins loaded in your project. That is certainly going to make any CPU sweat if you have more than one armed track at a time (and looking at your video, you do!).

You are simply overloading your main audio thread with the number of plugins on armed tracks you're throwing at it. Not Reaper's fault! Arm just one track and see what happens. Freeze the tracks you're not actively using for recording.



(And DAMN some of those sounds are tickling my fancy!)

Last edited by EvilDragon; 08-18-2017 at 12:09 PM.
EvilDragon is offline   Reply With Quote
Old 08-18-2017, 08:46 PM   #19
capn slugo
Human being with feelings
 
Join Date: Sep 2010
Location: NYCishness
Posts: 200
Default

Thanks for the diagnosis.
I know I have to chill out a good chunk of those plugins

I wish I could only arm the single track I'm recording on but Reaper's format leaves no alternative to to bring in the several USB midi hardware devices into armed tracks - this is what I'm whining about & it's my only real complainant with reaper.

Perhaps all DAWs are similar but it seems to a Luddite like me that there should be an alternative/auxiliary way to get midi and control devices into the midi scheme. I don't understand why there's no alternative to binding them to the same thread of events happening downstream.

I tried arming only the one track as you suggested - (with only the essential other usb control/midi hardware tracks armed)and the overload still happens.

I realize I have little knowledge of how any of it actually works and I sincerely appreciate your patience.

I do notice that the midi from the harp aspect of my rig (fishman midi pickup not played in video) is hitting perhaps as many kontakt instances as the key rig but it records smooth while it requires far more tracks to be armed.

Perhaps if I whittled down my 3000 plugins and ran the keyboard midi like this here.
https://forum.cockos.com/showthread.php?t=164597

Glad you dig my sounds - as you might imagine and may have noticed, it took me considerable effort to figure out how to get around in kontakt.

Last edited by capn slugo; 08-18-2017 at 08:56 PM.
capn slugo is offline   Reply With Quote
Old 08-19-2017, 08:32 PM   #20
capn slugo
Human being with feelings
 
Join Date: Sep 2010
Location: NYCishness
Posts: 200
Default Solved -

Epilogue:
The culprit was redundant or corrupt midi routing of cc64 sustain signals being multiplied of channel 1 and converted and distributed to several other midi channels (in order to sustain percussing devices with no sustain pedal ability) One or more of those routings were somehow causing the stutter and slowdown.

The duplicate cc64 events went unnoticed on the master track perhaps because a VST duplicate note filter was in place in the midi stream on a merger track, post cc64 Channel assignment in a merge that fed the multi midi channel master track.

The moral of the story, however incomprehensible or unlikely may be,,, that redundant or corrupt midi data (even if it's filtered prior to the destination VSTI) has an adverse effect on either reapers transport, kontakt or it maxes out the CPU in some other mysterious way.

With this midi routing problem resolved audio sounds indistinguishable between record and idle.

My rig is still running on the edge of my machine's capability but I'm able to record.

I really hope this info helps anyone that might suspect that corrupt or redundant midi routing may be the culprit in overloading a CPU, apparently even if the data has been filtered prior to it getting to it's source.

I'm going out to flip my car over and light it on fire again to celebrate.

Last edited by capn slugo; 08-19-2017 at 08:43 PM.
capn slugo is offline   Reply With Quote
Old 08-20-2017, 01:06 PM   #21
ivansc
Human being with feelings
 
Join Date: Aug 2007
Location: Near Cambridge UK and Near Questembert, France
Posts: 22,754
Default

Can I recommend some easy listening music for while your car burns?

https://www.youtube.com/watch?v=zOoV0I5ifEY
__________________
Ici on parles Franglais
ivansc is offline   Reply With Quote
Old 08-20-2017, 01:42 PM   #22
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Quote:
Originally Posted by capn slugo View Post
The moral of the story, however incomprehensible or unlikely may be,,, that redundant or corrupt midi data (even if it's filtered prior to the destination VSTI) has an adverse effect on either reapers transport, kontakt or it maxes out the CPU in some other mysterious way.
I'd express it differently. It doesn't have a direct adverse effect to Reaper's transport. What happened over there is that that sustain pedal routing held all the voices that were playing back (it depends on the amp envelope that sounds use, if Sustain part of envelope is not set to 0/-infinity, you will have voices that stick around for as long as the pedal is held, or for as long as the samples are long, if they are not looped. If they are looped, you have stuck notes forever until the pedal is lifted), which naturally piled up the voice count until your CPU couldn't take it anymore and ragequit.

So, the CONSEQUENCE of that is audio dropouts since the CPU couldn't process all those held voices in time, which in turn has the "adverse effects" you describe. It's not really "slowing down the transport", it's simply the fact that audio buffers cannot be prepared in time to be served to the audio interface, which glitches everything out.


In any case, glad you found the culprit.
EvilDragon is offline   Reply With Quote
Old 08-20-2017, 02:39 PM   #23
capn slugo
Human being with feelings
 
Join Date: Sep 2010
Location: NYCishness
Posts: 200
Default

I'll reread that 50 or 60 times and eventually the thrust of it will slowly sink in and be incredibly useful to me /// and hopefully others.

Thanks!!

I may have some further questions but ...as always.... the questions I come up with are most likely contained in your explanation.

Cheers!!
capn slugo 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 05:02 PM.


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