Old 11-02-2018, 09:15 AM   #1
Trancit
Human being with feelings
 
Join Date: Aug 2009
Location: Gran Canaria
Posts: 488
Default What happened to anticipative FX???

I am very very sure not very long time ago Reapers anticipative FX trick made a very big difference in the DAW world...

Little tests I made this time ago could load 25-30% more plugins in Reaper than in every other DAW out there...

Now... they are all more or less on par... there is perhaps a difference of +-1 or 2 instances ... but no comparison to the time before...

One could say, that the other developers woke up and implemented something similar to their own products, but I know for very sure (as far as I can believe the developers, what I do), that i.e. in FL Studio nothing like this was implemented...

Second... Anticipative FX does nothing anymore on my side... If I got it activated or deactivated, it shows me the same CPU usage both in Reaper and windows measurement... there is absolutely no difference...

Quite the contrary, there are some situations, where having it deactivated gives less (but little) CPU consumption than activated...

But there is no situation anymore, where having it activated shows less CPU consumption than deactivated...

What happened here???
Is it the OS???
The older tests of course were not on Win 10 but 7 or 8...
Trancit is offline   Reply With Quote
Old 11-02-2018, 09:46 AM   #2
davesnothere
Human being with feelings
 
Join Date: Oct 2016
Posts: 9
Default there is differences

There is a small handful of things different between win10 and its predecessors.

1. The increase of delay to fix hardware timing issues that caused the dredded "IRQ_NO_LESS_THAN_EQUAL_TO" blue screen crashes.

2.The preemptive multitasking profile was drastically changed to include utilizing virtualization to improve hardware timing and use processor speculation for most processes.

#2 is what really caused spector/meltdown
davesnothere is offline   Reply With Quote
Old 11-02-2018, 10:32 AM   #3
xpander
Human being with feelings
 
xpander's Avatar
 
Join Date: Jun 2007
Location: Terra incognita
Posts: 7,670
Default

Quote:
Originally Posted by Trancit View Post
Second... Anticipative FX does nothing anymore on my side... If I got it activated or deactivated, it shows me the same CPU usage both in Reaper and windows measurement... there is absolutely no difference...
If you are not getting to the limits of your computer audio performance with your test project, the regular CPU usage won't necessarily tell you much about the difference. Right-click over the Performance meter and tick Display realtime (RT) CPU. Then run your test and compare the RT CPU numbers while clicking anticipative FX processing on/off.
xpander is offline   Reply With Quote
Old 11-02-2018, 04:05 PM   #4
Trancit
Human being with feelings
 
Join Date: Aug 2009
Location: Gran Canaria
Posts: 488
Default

Hmm, I could swear, this was by far more noticeable years before...
Trancit is offline   Reply With Quote
Old 11-02-2018, 04:25 PM   #5
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

The anticipative rendering does nothing for the total CPU load. Reaper obviously can't make 3rd party plugins run more efficient with some magic trick. The purpose of the anticipative rendering is to allow better multicore CPU usage and reduce CPU load peaks in the critical audio processing thread. (Which doesn't reduce the overall CPU load but allows the CPU cores to be used closer to the maximum theoretical limit and reduces the chances a misbehaving plugin causes an audio glitch.)

It's likely other DAW manufacturers have caught on the same technique in the recent years. Or done some other things to reduce overheads in their processing.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.

Last edited by Xenakios; 11-02-2018 at 04:33 PM.
Xenakios is offline   Reply With Quote
Old 11-02-2018, 05:09 PM   #6
Trancit
Human being with feelings
 
Join Date: Aug 2009
Location: Gran Canaria
Posts: 488
Default

Quote:
Originally Posted by Xenakios View Post
The anticipative rendering does nothing for the total CPU load. Reaper obviously can't make 3rd party plugins run more efficient with some magic trick. The purpose of the anticipative rendering is to allow better multicore CPU usage and reduce CPU load peaks in the critical audio processing thread. (Which doesn't reduce the overall CPU load but allows the CPU cores to be used closer to the maximum theoretical limit and reduces the chances a misbehaving plugin causes an audio glitch.)

It's likely other DAW manufacturers have caught on the same technique in the recent years. Or done some other things to reduce overheads in their processing.
Thx for explaining... perhaps this effect was more noticeable on older Multicore CPU´s...
Trancit is offline   Reply With Quote
Old 11-02-2018, 05:28 PM   #7
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by Trancit View Post
perhaps this effect was more noticeable on older Multicore CPU´s...
Or on older operating systems. Or maybe newer plugins just have more predictable CPU load behavior. (It's really a bug in a plugin if it causes CPU load spikes in the audio processing thread.) Other apps may also have previously had problems in how they handle their disk I/O and such, making them behave unfavorably compared to Reaper.

It would still be interesting to do some benchmarks comparing Reaper to other DAW applications at this point in time.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 11-03-2018, 09:13 AM   #8
Trancit
Human being with feelings
 
Join Date: Aug 2009
Location: Gran Canaria
Posts: 488
Default

Quote:
Originally Posted by Xenakios View Post
Or on older operating systems. Or maybe newer plugins just have more predictable CPU load behavior. (It's really a bug in a plugin if it causes CPU load spikes in the audio processing thread.) Other apps may also have previously had problems in how they handle their disk I/O and such, making them behave unfavorably compared to Reaper.
It´s very likely, that it will be a mix out of all of these points, which made a much bigger difference in the past...
Trancit is offline   Reply With Quote
Old 11-03-2018, 11:50 PM   #9
tombuur
Human being with feelings
 
tombuur's Avatar
 
Join Date: Jul 2010
Location: Denmark
Posts: 465
Default

I have Cubase 9.5 Pro but hardly use it. The reason is that with comparable projects Cubase crackles and stutters when Reaper only uses around 25% cpu. I thought the difference was due to Reaper using anticipative FX. Not?
__________________
Reaper 5, latest release, 64-bit w SWS |GA Z270 UD5|Intel i7 K7700|32 GB RAM|Fireface 800|500GB SSD sys, 1TB SSD Rec, 4TB HDD samples|Win 10 64bit|Dynaudio BM6A|Softube Console 1|Sonnox|Waves|Melda|Superior 3|Komplete 12U|Melodyne|Slate|Izotope.
tombuur is offline   Reply With Quote
Old 11-04-2018, 01:15 AM   #10
Trancit
Human being with feelings
 
Join Date: Aug 2009
Location: Gran Canaria
Posts: 488
Default

Quote:
Originally Posted by tombuur View Post
I have Cubase 9.5 Pro but hardly use it. The reason is that with comparable projects Cubase crackles and stutters when Reaper only uses around 25% cpu. I thought the difference was due to Reaper using anticipative FX. Not?
It´s possible but can have different reasons I think...

Perhaps you are using VSTs, which benefit much from anticipative FX (while Cubase has it´s own system with ASIO guard, hasn´t it??)or just behave better in Reaper...
Trancit is offline   Reply With Quote
Old 11-04-2018, 02:00 AM   #11
tombuur
Human being with feelings
 
tombuur's Avatar
 
Join Date: Jul 2010
Location: Denmark
Posts: 465
Default

Quote:
Originally Posted by Trancit View Post
It´s possible but can have different reasons I think...

Perhaps you are using VSTs, which benefit much from anticipative FX (while Cubase has it´s own system with ASIO guard, hasn´t it??)or just behave better in Reaper...
I generally use VST3, unless only VST2 is available. Not that I think VST3 is better in Reaper, but just to limit the number of "duplicates" when searching for an fx and perhaps save a little space on the system drive.
__________________
Reaper 5, latest release, 64-bit w SWS |GA Z270 UD5|Intel i7 K7700|32 GB RAM|Fireface 800|500GB SSD sys, 1TB SSD Rec, 4TB HDD samples|Win 10 64bit|Dynaudio BM6A|Softube Console 1|Sonnox|Waves|Melda|Superior 3|Komplete 12U|Melodyne|Slate|Izotope.
tombuur is offline   Reply With Quote
Old 03-11-2019, 07:51 AM   #12
David Carlyon
Human being with feelings
 
Join Date: Feb 2019
Posts: 182
Default

This is a topic that interests me a lot. I was using Bitwig (which i love for creative inspiration/jamming ideas) but it is very inefficient. I found Ableton to be not that much better.
Studio One i found to be very good. I found i could run the same sessions and much more with less problems.

Coming to reaper - which i have been evaluating for the last week now - i have noticed that i rarely get any audio crackles or drop outs.
It has been very much noticable.

Also i am trying to re-think the way i work, so as to make the most out of anticipative fx processing.

For example, i was told that stacking up lots of VSTS on a single channel (in other programs would load up one core, without being able to usilize multi cores/threads. So i started using more busses for different FX.
But it seems with anticipative FX, it is better not to load up busses and aux's, as they cannot be pre rendered in the same way?

Even without thinking about optimizing my session, it was already better than the others i have been using. But i am going to try and optimize my sessions further, to make the most of Reapers method.

If anyone has any tips on this, i am very interested to hear!

Also, someone was telling me yesterday that Digital Performer has implemented something similar to anticipative FX - so maybe other DAWs are catching on
David Carlyon is offline   Reply With Quote
Old 03-11-2019, 08:57 AM   #13
Coachz
Human being with feelings
 
Coachz's Avatar
 
Join Date: Oct 2010
Location: Charleston, SC
Posts: 12,770
Default

Quote:
Originally Posted by davesnothere View Post
There is a small handful of things different between win10 and its predecessors.

1. The increase of delay to fix hardware timing issues that caused the dredded "IRQ_NO_LESS_THAN_EQUAL_TO" blue screen crashes.

2.The preemptive multitasking profile was drastically changed to include utilizing virtualization to improve hardware timing and use processor speculation for most processes.

#2 is what really caused spector/meltdown
Is windows 10 better than windows 7 for Reaper? I'm on 7 currently.
__________________
Track Freezing Scripts

Coachz Repo
Coachz is online now   Reply With Quote
Old 03-11-2019, 09:15 AM   #14
azslow3
Human being with feelings
 
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 797
Default

Anticipative processing is a complex topic.
The following in IMHO, I can misinterpret something (corrections are welcome).

Real time processing is done simple way. Once per "buffer size" time (f.e. 128 samples, 44.1kHz -> 2.9 ms ) audio driver (ASIO) delivers input buffers and ask to fill output buffers. So in such mode a DAW has no more than that time to do the whole one buffer processing. And that is hard limit, failing to fit one single processing into that time produce "click/crack".

3ms (and lower) is not "long". Yes, it is just "300 Hz". But not so long time ago computer tick was on the level 100 Hz. That is not the same as CPU frequency, tons of operations are required to switch processes, even longer to sync hardware (out of CPU parts are still working in MHz frequencies, the speed of light limit is not yet broken and Shannon's theorems are still valid, in other words our "micro" computers are "too big" for high synced operations rates).

The quality of audio device hardware, its drivers, computer hardware, all used drivers and OS plays significant role. And all that was improved over time and all DAWs can profit from that. There are reports proper made computers with careful settings and good audio interface can be 95% loaded without producing any cracks in real time. But there are computers/OS/drivers/interfaces with which people get troubles after 30% or even lower (average!) load.

Anticipative processing renders everything possible "offline".
And possible is everything without "live" input (so without sources in record armed tracks).

Sure, it still should process 3ms audio no longer then 3ms, but only IN AVERAGE. F.e. if first 3ms takes 4ms to process, but next 3ms takes just 1ms, there is no problem 4+1=5, less then 3+3=6. Real time processing will be in trouble in that case.

The second aspect is load distribution. If you have 2 independent tracks with 1 FX each, it is possible to run them on different cores. Even in Real Time. But if you have 2 FXes on one track, so in a sequence, what can be done? With anticipative processing it is possible to run the first with one buffer and the second with the second buffer. So, natively you can run them on different cores in parallel when desired. In Real Time processing, both FXes MUST work with the same buffer and they should finish within that buffer time. Is there some tricks? Yes! A DAW can internally use let say a half of real buffer and so run them in parallel (with some performance overhead penalty, so the overall load will be HIGHER, but load balancing will be better), a kind of "micro anticipative" processing.

The third aspect is PDC, Plug-in Delay Compensation. Some plug-ins do not produce output for the buffer they had on input, but for some early buffer. The difference can be significant, up to 1second (!) for mastering plug-ins. Note that is not "CPU time" related, plug-ins just want to know "future" audio information. With anticipative processing, that can be organized without troubles so tracks are not getting PDC from other (unrelated) tracks. That is not possible to do in Real Time mode, all signals are delayed by any PDC in any branch (since ALL tracks should produce the same timeline output for fixed by real time input).

Finally I want to mention that default REAPER anticipative delay time is too high (200ms). That produce significant visual delay (the information displayed by plug-in GUI is TOO EARLY compare to the audio output, since plug-in is processing in advance). There are some "tricks" here, f.e. (obviously) reduce the delay for plug-ins which GUIs are open. If I remember correctly, Studio One is using the trick more then REAPER (REAPER claiming it for MIDI).
Note: this delay helps with the first aspect. Load balancing needs no more then number of cores * buffer time by definition, PDC compensation is done independently (it can be way more then 200ms).
azslow3 is offline   Reply With Quote
Old 03-11-2019, 11:45 AM   #15
David Carlyon
Human being with feelings
 
Join Date: Feb 2019
Posts: 182
Default

Quote:
Originally Posted by azslow3 View Post
Anticipative processing is a complex topic.
The following in IMHO, I can misinterpret something (corrections are welcome).

Real time processing is done simple way. Once per "buffer size" time (f.e. 128 samples, 44.1kHz -> 2.9 ms ) audio driver (ASIO) delivers input buffers and ask to fill output buffers. So in such mode a DAW has no more than that time to do the whole one buffer processing. And that is hard limit, failing to fit one single processing into that time produce "click/crack".

3ms (and lower) is not "long". Yes, it is just "300 Hz". But not so long time ago computer tick was on the level 100 Hz. That is not the same as CPU frequency, tons of operations are required to switch processes, even longer to sync hardware (out of CPU parts are still working in MHz frequencies, the speed of light limit is not yet broken and Shannon's theorems are still valid, in other words our "micro" computers are "too big" for high synced operations rates).


The quality of audio device hardware, its drivers, computer hardware, all used drivers and OS plays significant role. And all that was improved over time and all DAWs can profit from that. There are reports proper made computers with careful settings and good audio interface can be 95% loaded without producing any cracks in real time. But there are computers/OS/drivers/interfaces with which people get troubles after 30% or even lower (average!) load.

Anticipative processing renders everything possible "offline".
And possible is everything without "live" input (so without sources in record armed tracks).

Sure, it still should process 3ms audio no longer then 3ms, but only IN AVERAGE. F.e. if first 3ms takes 4ms to process, but next 3ms takes just 1ms, there is no problem 4+1=5, less then 3+3=6. Real time processing will be in trouble in that case.

The second aspect is load distribution. If you have 2 independent tracks with 1 FX each, it is possible to run them on different cores. Even in Real Time. But if you have 2 FXes on one track, so in a sequence, what can be done? With anticipative processing it is possible to run the first with one buffer and the second with the second buffer. So, natively you can run them on different cores in parallel when desired. In Real Time processing, both FXes MUST work with the same buffer and they should finish within that buffer time. Is there some tricks? Yes! A DAW can internally use let say a half of real buffer and so run them in parallel (with some performance overhead penalty, so the overall load will be HIGHER, but load balancing will be better), a kind of "micro anticipative" processing.

The third aspect is PDC, Plug-in Delay Compensation. Some plug-ins do not produce output for the buffer they had on input, but for some early buffer. The difference can be significant, up to 1second (!) for mastering plug-ins. Note that is not "CPU time" related, plug-ins just want to know "future" audio information. With anticipative processing, that can be organized without troubles so tracks are not getting PDC from other (unrelated) tracks. That is not possible to do in Real Time mode, all signals are delayed by any PDC in any branch (since ALL tracks should produce the same timeline output for fixed by real time input).

Finally I want to mention that default REAPER anticipative delay time is too high (200ms). That produce significant visual delay (the information displayed by plug-in GUI is TOO EARLY compare to the audio output, since plug-in is processing in advance). There are some "tricks" here, f.e. (obviously) reduce the delay for plug-ins which GUIs are open. If I remember correctly, Studio One is using the trick more then REAPER (REAPER claiming it for MIDI).
Note: this delay helps with the first aspect. Load balancing needs no more then number of cores * buffer time by definition, PDC compensation is done independently (it can be way more then 200ms).




Wow lots of information there, will have to re read a couple of times.
What about tracks that have 'receives' do they utilize anticipative processing?
Also what about the master channel?

So studio One is now using a similar type of system? S1 is the other DAW that stood out for me in terms of efficiency. Of all the ones i have used, Reaper and studio one are by far the most efficient. but i have to say i have hadfar less 'crackles' with reaper.

Thanks again, great input.
David Carlyon is offline   Reply With Quote
Old 03-11-2019, 12:14 PM   #16
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Quote:
Originally Posted by davesnothere View Post
2.The preemptive multitasking profile was drastically changed to include utilizing virtualization to improve hardware timing and use processor speculation for most processes.

#2 is what really caused spector/meltdown
Well no, Spectre/Meltdown is a hadrware exploit of CPUs that has existed for years. W10 changing something about multitasking profile did not magically cause Spectre/Meltdown to exist.

Quote:
Originally Posted by azslow3 View Post
But if you have 2 FXes on one track, so in a sequence, what can be done? With anticipative processing it is possible to run the first with one buffer and the second with the second buffer. So, natively you can run them on different cores in parallel when desired. In Real Time processing, both FXes MUST work with the same buffer and they should finish within that buffer time. Is there some tricks? Yes! A DAW can internally use let say a half of real buffer and so run them in parallel (with some performance overhead penalty, so the overall load will be HIGHER, but load balancing will be better), a kind of "micro anticipative" processing.
A serial chain of FX where 2nd FX depends on the output of 1st FX cannot be broken down to parallel or anticipative processing. You need to finish processing the buffer with the first effect so that the second effect can process on the output of the first effect. So AfxP in Reaper doesn't work like what you suggest here.

Last edited by EvilDragon; 03-11-2019 at 12:24 PM.
EvilDragon is online now   Reply With Quote
Old 03-11-2019, 01:10 PM   #17
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by EvilDragon View Post
A serial chain of FX where 2nd FX depends on the output of 1st FX cannot be broken down to parallel
It maybe kind of could be, but Reaper doesn't work like that and I suspect it wouldn't pay off to do that kind of more complicated pipeline in the end anyway.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 03-11-2019, 11:51 PM   #18
azslow3
Human being with feelings
 
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 797
Default

Quote:
Originally Posted by David Carlyon View Post
What about tracks that have 'receives' do they utilize anticipative processing? Also what about the master channel?
If receive comes from record armed track, the only way to process is Real Time. The same for Master as long as live track is routed to it.

Quote:
Originally Posted by Xenakios View Post
It maybe kind of could be, but Reaper doesn't work like that and I suspect it wouldn't pay off to do that kind of more complicated pipeline in the end anyway.
Sorry for possible confusion. That was an example what can be done if there is no general anticipative processing. Sure REAPER does not need that. But Cakewalk has real time engine only and so tries to use such kind of tricks.
@EvilDragon. If the buffer size is let say 512, but you call plug-ins with 256, the second FX in the chain can start working after the first 256 samples are processed by the first FX.
azslow3 is offline   Reply With Quote
Old 03-12-2019, 12:06 AM   #19
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Quote:
Originally Posted by azslow3 View Post
@EvilDragon. If the buffer size is let say 512, but you call plug-ins with 256, the second FX in the chain can start working after the first 256 samples are processed by the first FX.
Ah, so that sounds similar to something like the dynamic buffer size feature of FL Studio (which actually creates a bunch of issues with a lot of plugins, ironically).
EvilDragon is online now   Reply With Quote
Old 03-12-2019, 04:44 AM   #20
azslow3
Human being with feelings
 
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 797
Default

Quote:
Originally Posted by EvilDragon View Post
Ah, so that sounds similar to something like the dynamic buffer size feature of FL Studio (which actually creates a bunch of issues with a lot of plugins, ironically).
I am not using FL Studio, but Cakewalk has introduced such approach several years ago. I had not many cores to use the feature, reported experience in the forum was mixed.

I do not exclude we will see dynamic buffer size in the future REAPER versions. I have extra checked and was surprised REAPER is using the same buffer size during anticipative processing as in real time. Smaller buffers can have significant overhead (simple to observe switching from 512 to let say 32/48), so that can be a kind of efficiency optimization. Celemony (still) recommend high buffer for Melodyne, including explicit REAPER instructions. It works fine for me without changing the buffer, but since they persistently mention that there should be a good reason.
azslow3 is offline   Reply With Quote
Old 03-12-2019, 12:45 PM   #21
Trancit
Human being with feelings
 
Join Date: Aug 2009
Location: Gran Canaria
Posts: 488
Default

Quote:
Originally Posted by azslow3 View Post
Finally I want to mention that default REAPER anticipative delay time is too high (200ms). That produce significant visual delay (the information displayed by plug-in GUI is TOO EARLY compare to the audio output, since plug-in is processing in advance). ...
What would you recommend to set the delay time to??
My "problem" (not really a problem but annoys a bit) with this 200ms delay is that the audio is still running after pressing spacebar to stop the playback...

Somehow that´s irritating for me and feels wrong if I hit space and after pressing Reaper still triggering sometimes the next kick...

I am not very sensitive to delays and working with 512 -1024 sample buffer is mostly good for me...
What should be a good delay time setting for Anticipative FX without having this "after-run"???
Trancit is offline   Reply With Quote
Old 03-12-2019, 12:52 PM   #22
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by Trancit View Post
What should be a good delay time setting for Anticipative FX without having this "after-run"???
Try 50 milliseconds, should still give benefits for CPU performance. (Note that plugin delay compensation is another mechanism and will also cause those deferred playback stop delays.)
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 03-12-2019, 01:13 PM   #23
Trancit
Human being with feelings
 
Join Date: Aug 2009
Location: Gran Canaria
Posts: 488
Default

Quote:
Originally Posted by Xenakios View Post
Try 50 milliseconds, should still give benefits for CPU performance. (Note that plugin delay compensation is another mechanism and will also cause those deferred playback stop delays.)
Thx...
Trancit is offline   Reply With Quote
Old 03-13-2019, 09:47 AM   #24
David Carlyon
Human being with feelings
 
Join Date: Feb 2019
Posts: 182
Default

Quote:
Originally Posted by azslow3 View Post
If receive comes from record armed track, the only way to process is Real Time. The same for Master as long as live track is routed to it.


Sorry for possible confusion. That was an example what can be done if there is no general anticipative processing. Sure REAPER does not need that. But Cakewalk has real time engine only and so tries to use such kind of tricks.
@EvilDragon. If the buffer size is let say 512, but you call plug-ins with 256, the second FX in the chain can start working after the first 256 samples are processed by the first FX.
Would you say in general it is better to avoid loading up single tracks?

For example, as reapers tracks have multiple inputs, i was thinking that instead of having multiple submix groups (drums, bass, synth etc) i could just send them to one buss, but on different channels. Then create a 'buss processor' with LBX stripper and do it all from one interface.
But that would mean having quite a lot of plugins on one singular track.

Is that sort of thing not really advised?

Cheers
David Carlyon is offline   Reply With Quote
Old 03-14-2019, 04:58 PM   #25
David Carlyon
Human being with feelings
 
Join Date: Feb 2019
Posts: 182
Default

One thing i have noticed is that if i run a VSTi on a Midi item instead of Track, the timing is different.
If i have a kick on every downbeat and looped, the first note of the loop is always cut off a bit.
So i assume there is mor anticipative procesing on the items than the tracks?
David Carlyon is offline   Reply With Quote
Old 03-14-2019, 05:32 PM   #26
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 1,619
Default

Quote:
Originally Posted by EvilDragon View Post
A serial chain of FX where 2nd FX depends on the output of 1st FX cannot be broken down to parallel or anticipative processing. You need to finish processing the buffer with the first effect so that the second effect can process on the output of the first effect.
It can be. We do seem to keep arguing about this.

Remember when I started this thread? I was wrong that Reaper worked this way (and proved it to myself later in that thread), but the design could work.
tack is offline   Reply With Quote
Old 03-14-2019, 10:00 PM   #27
azslow3
Human being with feelings
 
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 797
Default

Quote:
Originally Posted by David Carlyon View Post
Would you say in general it is better to avoid loading up single tracks?

For example, as reapers tracks have multiple inputs, i was thinking that instead of having multiple submix groups (drums, bass, synth etc) i could just send them to one buss, but on different channels. Then create a 'buss processor' with LBX stripper and do it all from one interface.
But that would mean having quite a lot of plugins on one singular track.

Is that sort of thing not really advised?

Cheers
I will say from performance reason it is better keep things on separate tracks/buses then try to put everything into one multichannel bus.

One reason, if something can be done in parallel on parallel tracks that will be optimized and synced in parallel. F.e. mentioned PDC will work on each track/submix independently, you will not get PDC delay from already mixed drums on synth, you can even record synth in this case.

The second reason is what tack has just mentioned, in his test REAPER was not load balancing plug-ins put on one track, while load balancing the same plug-ins (and the same logical routing, so from one to another) on different tracks.
azslow3 is offline   Reply With Quote
Old 03-14-2019, 10:36 PM   #28
Faderjockey
Human being with feelings
 
Faderjockey's Avatar
 
Join Date: Jun 2007
Location: Baltimore,MD
Posts: 920
Default

funny this thread happened recently.. because I never messed with this in all the years since 2008 that I was moved full time into Reaper.

but few weeks ago I had some glitches.. and some software was acting weird I thought. Console 1 was updates and I just bought British channel on sale. I had a sort of big session.. bunch of console 1, UAD, Waves, Soundtoys you name it.

well the glitching was bugging me.. so I decided to reinstall Win10 and things on another SSD.. so I at least had the old one if something got weird. But the new install seemed better.. after several emails over all this time with Softube one of the guys reaches out and says he was messing with the newest version and in Reaper noticed changing Anticipative from 200 to 600 made the glitches stop...

and did a test and sure enough it did.. but I didn't notice at the time how it changed the meter visuals.. few days later I was mixing something and then I say the meters.. took me reading to realize that 600 setting was why.. I didn't know it would do that.. so I go back to 200 and I started getting clitching on this tune.. I never use to have it until the newest softube update.

So I'm sort of going nuts..right now I settled at 250 setting to not get gitches and sort of live with meters.. but still I can tell they are as on time as I would really like. i'm on Win10 pro i7 7700K 32gig ram. and moved from my SSD Samsung 850 to 860 version.. and same results even with audio drives being either a Lacie Rugged or my internal WD m.2 audio drive
Faderjockey is offline   Reply With Quote
Old 03-16-2019, 03:35 AM   #29
azslow3
Human being with feelings
 
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 797
Default

200ms is huge by itself. Check performance meters in REAPER and in the System, use https://www.resplendence.com/latencymon to check for some bugging drivers.

But there is one setting which you can try instantly. What is your ASIO buffer setting? Try to change it to something like 512 or 1024. Even in anticipative mode, REAPER is using that size for buffers. And some plug-ins can be sensitive to that.
azslow3 is offline   Reply With Quote
Old 03-16-2019, 10:03 AM   #30
Faderjockey
Human being with feelings
 
Faderjockey's Avatar
 
Join Date: Jun 2007
Location: Baltimore,MD
Posts: 920
Default

right now I have it set to 300 Console1 newest drivers have been acting weird and I've been talking with them.

my buffers on this mix is at 512.

I also noticed if I was to freeze a track sometimes a glitch would be in the freeze making audio drop out.. pita!! all the years on Reaper never had this issue.

so I unfroze all tracks.. between native and all my UAD DSP I have 194FX running and total CPU on machine is at 28.2

but with antucupative FX at 300 I don't get glitches but hate looking at meters when set there.. any lower even 250 I know get crackles.. never use to get that.
So don't fully know if it was newer Reaper updates or the newer Softube updates that made this stuff act weird and glitch like this.
Faderjockey is offline   Reply With Quote
Old 03-18-2019, 01:02 PM   #31
jm duchenne
Human being with feelings
 
jm duchenne's Avatar
 
Join Date: Feb 2006
Location: France
Posts: 914
Default

Thanks for these interesting explainations, I think I understand better why with some rather demanding plugins, the output sound have big drop outs as soon as I need to control them with MIDI.
It depends of course on the computer, but with everyone I use it happends in some circumstances.
Big buffers help a little but don't avoid it.

The only solution I have found is to play them in Bidule, either as standalone with Rearoute or as a plugin, so I can record their output or automation in Reaper.
It is strange because when it is possible, if I control them via MIDILearn I can use them, it is only when the track receives MIDI that the audio output becomes unusable.

Do you know some way to prevent this ?
jm duchenne is offline   Reply With Quote
Old 03-19-2019, 12:50 AM   #32
azslow3
Human being with feelings
 
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 797
Default

Quote:
Originally Posted by jm duchenne View Post
It is strange because when it is possible, if I control them via MIDILearn I can use them, it is only when the track receives MIDI that the audio output becomes unusable.
Does that happens without arm tracks or with arm tracks only (so you have "rec armed" tracks for MIDI input)? In the second case, try to check "Allow life FX multiprocessing on" option, enable it (if not yet) and increase the number of CPUs (if physically available).
azslow3 is offline   Reply With Quote
Old 03-22-2019, 09:30 AM   #33
David Carlyon
Human being with feelings
 
Join Date: Feb 2019
Posts: 182
Default

Does anyone have any experience with the Antelope Discrete interfaces and their on board FX? I am wondering if this will work well alongside anticipative FX
David Carlyon is offline   Reply With Quote
Old 03-22-2019, 09:36 AM   #34
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

That has nothing to do with AfxP, it's FX processing done on the audio interface before your signal hits the DAW. Can be used for monitoring purposes, or "burned in" as you record your input signal. As if you were recording from outboard gear directly (hardware compressor, EQ, guitar amp...)
EvilDragon is online now   Reply With Quote
Old 03-22-2019, 02:33 PM   #35
David Carlyon
Human being with feelings
 
Join Date: Feb 2019
Posts: 182
Default

Quote:
Originally Posted by EvilDragon View Post
That has nothing to do with AfxP, it's FX processing done on the audio interface before your signal hits the DAW. Can be used for monitoring purposes, or "burned in" as you record your input signal. As if you were recording from outboard gear directly (hardware compressor, EQ, guitar amp...)
Oh, i thought you could use the FX to process things within the DAW too? Will have another look
David Carlyon 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:43 AM.


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