>>> https://news.ycombinator.com/item?id=25059663EvilDragon wrote: ↑Thu Jan 14, 2021 10:49 pm Single thread performance matters in EVERY DAW. Not just Live.
The main thing is, Reaper is doing something Live isn't, which is called processing ahead of time (anticipative processing). This utilized your CPU much better.
from REAPER to ABLETON (one big disappointment)
-
- KVRAF
- 4504 posts since 3 Oct, 2013 from Budapest
"Where we're workarounding, we don't NEED features." - powermat
- Banned
- 11467 posts since 4 Jan, 2017 from Warsaw, Poland
I wonder how many potential users Reaper loses by not adhering to industry standards when it comes to shortucts, modifiers, etc. My experience was really soured by things working (very) weirdly out-of-the-box.
Perhaps they should change the defaults if it's so easy?
-
ReleaseCandidate ReleaseCandidate https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=476930
- KVRian
- 620 posts since 19 Oct, 2020
Yes, multithreading is a concept most people, including developers, don't understand, in reality it's way more complex than the people think it is (and I'm not talking about lock free algorithms).xbitz wrote: ↑Fri Jan 15, 2021 8:50 am>>> https://news.ycombinator.com/item?id=25059663EvilDragon wrote: ↑Thu Jan 14, 2021 10:49 pm Single thread performance matters in EVERY DAW. Not just Live.
The main thing is, Reaper is doing something Live isn't, which is called processing ahead of time (anticipative processing). This utilized your CPU much better.
Nowadays the same happens with GPU processing too.
- Banned
- 11467 posts since 4 Jan, 2017 from Warsaw, Poland
In light of that discussion, I wonder how Bitwig differs - from dev perspective - compared to Live?xbitz wrote: ↑Fri Jan 15, 2021 8:50 am>>> https://news.ycombinator.com/item?id=25059663EvilDragon wrote: ↑Thu Jan 14, 2021 10:49 pm Single thread performance matters in EVERY DAW. Not just Live.
The main thing is, Reaper is doing something Live isn't, which is called processing ahead of time (anticipative processing). This utilized your CPU much better.
It's often seen as the better one in terms of CPU performance and multi-threading in particular. It's definitely not because of sandboxing (as pointed out) and I find it hard to believe that Live forces into a single thread 2+ otherwise independent tracks that go through the same return tracks.
-
ReleaseCandidate ReleaseCandidate https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=476930
- KVRian
- 620 posts since 19 Oct, 2020
I guess because of their stricter routing rules they have less complex audio paths to process and can easier decide if something is save (independent) to compute in parallel.antic604 wrote: ↑Fri Jan 15, 2021 10:22 amIn light of that discussion, I wonder how Bitwig differs - from dev perspective - compared to Live?xbitz wrote: ↑Fri Jan 15, 2021 8:50 am>>> https://news.ycombinator.com/item?id=25059663EvilDragon wrote: ↑Thu Jan 14, 2021 10:49 pm Single thread performance matters in EVERY DAW. Not just Live.
The main thing is, Reaper is doing something Live isn't, which is called processing ahead of time (anticipative processing). This utilized your CPU much better.
It's often seen as the better one in terms of CPU performance and multi-threading in particular.
Live doesn't do that, I (and other people) would have noticed yet I guess, sending many tracks to one aux channel isn't that uncommon.
-
- KVRAF
- 5818 posts since 9 Jul, 2002 from Helsinki
It's just a fancy word for adding high latency to your playback controls (play/stop). There is a noticeable lag when starting and stopping your track, which doesn't exist in Live. Reaper buffers the audio stream to compensate for it's inefficient code. Turn off the "Anticipative Processing" to see how bad it actually is in terms of CPU efficiency.xbitz wrote: ↑Fri Jan 15, 2021 8:50 am>>> https://news.ycombinator.com/item?id=25059663EvilDragon wrote: ↑Thu Jan 14, 2021 10:49 pm Single thread performance matters in EVERY DAW. Not just Live.
The main thing is, Reaper is doing something Live isn't, which is called processing ahead of time (anticipative processing). This utilized your CPU much better.
Now this lag trick can be useful when you are mixing and have a bad habit of mixing plugin tracks instead of audio, but for tracking it's horrrendous, and messes up with PDC and timing accuracy of MIDI recording.
- KVRAF
- 23102 posts since 7 Jan, 2009 from Croatia
That's a load of bullcrap
Anticipative processing doesn't mess up PDC nor does it apply to recording live MIDI inputs (armed tracks). All DAWs do media buffering to some extent otherwise you'd have glitch city. Also note that buffering audio is not the same thing as anticipative processing. Also, anticipative processing is not a trick to compensate for inefficient code. It's a feature!
Show me a DAW that supports 128 CPU cores natively and as efficiently. Is there any other? But of course there isn't!
Anticipative processing doesn't mess up PDC nor does it apply to recording live MIDI inputs (armed tracks). All DAWs do media buffering to some extent otherwise you'd have glitch city. Also note that buffering audio is not the same thing as anticipative processing. Also, anticipative processing is not a trick to compensate for inefficient code. It's a feature!
Show me a DAW that supports 128 CPU cores natively and as efficiently. Is there any other? But of course there isn't!
There are no "industry standards" really. Most DAWs have wildly different shortcuts for any number of standard editing actions... Of course, PT is not flexible at all here since you can't even change any shortcuts, it's their way or highway. But compare shortcuts between PT, Cubase, Logic, Live, it's all wildly different for the most part, I guess the only thing in common is using spacebar to start/stop transport.
- Banned
- 11467 posts since 4 Jan, 2017 from Warsaw, Poland
Yeah, that would make sense. Limited feedback options and inability to (easily) modulate anything by anything would indeed make parallelisation easier, as things are more 'predictable' that way.ReleaseCandidate wrote: ↑Fri Jan 15, 2021 10:36 amI guess because of their stricter routing rules they have less complex audio paths to process and can easier decide if something is save (independent) to compute in parallel.
You're right. Just tested it with 3 CPU-heavy tracks totalling at 75% DSP and then sent them through a CPU-heavy reverb return. No difference.ReleaseCandidate wrote: ↑Fri Jan 15, 2021 10:36 amLive doesn't do that, I (and other people) would have noticed yet I guess, sending many tracks to one aux channel isn't that uncommon.
U-He makes such quick tests very easy
-
- KVRist
- 108 posts since 14 Jan, 2020
ED already said it, but it's worth repeating since people might see the thumbs up on your post and assume you have any idea what you're talking about: this is a load of bullcrap. all DAWs buffer audio output, anticipative FX processing is not the same as this buffer and doesn't 'compensate' for anything, it doesn't affect PDC or MIDI timing in any way, it works fine while tracking as it doesn't affect record-monitored tracks, and if you don't like the small added delay when starting/stopping playback you can turn it off.jon wrote: ↑Fri Jan 15, 2021 11:00 amIt's just a fancy word for adding high latency to your playback controls (play/stop). There is a noticeable lag when starting and stopping your track, which doesn't exist in Live. Reaper buffers the audio stream to compensate for it's inefficient code. Turn off the "Anticipative Processing" to see how bad it actually is in terms of CPU efficiency.
Now this lag trick can be useful when you are mixing and have a bad habit of mixing plugin tracks instead of audio, but for tracking it's horrrendous, and messes up with PDC and timing accuracy of MIDI recording.
-
ReleaseCandidate ReleaseCandidate https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=476930
- KVRian
- 620 posts since 19 Oct, 2020
This is now my official 'complain about Reaper'-thread!
The docks and toolbars have significantly less docking and enabling/disabling options than in Samplitude.
But the customized MIDI editor is usable now
The docks and toolbars have significantly less docking and enabling/disabling options than in Samplitude.
But the customized MIDI editor is usable now
-
- KVRist
- Topic Starter
- 129 posts since 28 Feb, 2007
OP here. Feel free to express yourselfReleaseCandidate wrote: ↑Thu Jan 21, 2021 1:16 pm This is now my official 'complain about Reaper'-thread!
The docks and toolbars have significantly less docking and enabling/disabling options than in Samplitude.
But the customized MIDI editor is usable now
-
- KVRist
- Topic Starter
- 129 posts since 28 Feb, 2007
Just one thing about my current relationship with Ableton and Reaper: I bought Push 2 and didn't start up Reaper since the time I started this thread. I'm sorry to all Reapers...
- Banned
- 11467 posts since 4 Jan, 2017 from Warsaw, Poland
Nice!boriskarloff wrote: ↑Thu Jan 21, 2021 8:32 pmJust one thing about my current relationship with Ableton and Reaper: I bought Push 2 and didn't start up Reaper since the time I started this thread. I'm sorry to all Reapers...
You'll be happy to learn this:
http://www.mossgrabers.de/Software/Reaper/Reaper.html
https://www.youtube.com/watch?v=zlXQribt7KQ
-
thecontrolcentre thecontrolcentre https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=76240
- KVRAF
- 35189 posts since 27 Jul, 2005 from the wilds of wanny
boriskarloff wrote: ↑Thu Jan 21, 2021 8:32 pm Just one thing about my current relationship with Ableton and Reaper: I bought Push 2 and didn't start up Reaper since the time I started this thread. I'm sorry to all Reapers...
-
ReleaseCandidate ReleaseCandidate https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=476930
- KVRian
- 620 posts since 19 Oct, 2020
The more I use Reaper the more limitations I encounter. It's API is same limited as the ones from Tracktion's Waveform or Cakewalk (but you can at least use Python, Lua or C++ instead of CAL. Yes, I love Emacs, but would prefer some ML dialect).
That's also why many user extension are hacks around this limitations (Reaticulate or retrospective record or...). You can't even colorize the rows in the MIDI editor per note.
So Reaper's scripting really is is 'only' better macros, no real interface to internal dáta, so no chance to get non-hacked extensions.
But at least the key command menu is better than in Cakewalk, which has the most braindead implementation of a keybinding menu of any program that I know of.
So: great for audio with your custom scripts/macros, I still prefer Samplitude together with Soundforge though. For MIDI: Cakewalk is about the samé (and is also lacking retrospective record) but has articulation maps and actually colors your piano roll when using scales instead of just the keys. Or Live 11, if you want a MIDI editor that has exactly the features you need in a way that's not configurable in Reaper (you can't context sensitivly change the mouse actions to get the pointer as 'smart' as with Live, I still too often erratically generate a note).
If Bandlab would add an alternative (Python or Lua) to the (deprecated) CAL scripting and an official documentation instead of http://dgcardenas.fpmit.com/cal/...
So, tl;dr: really disappointed about the limited scripting customizability and limited docking cababilities of Reaper. One of the few programs I'd actually change the source code of if possible, out of frustration of missed opportunities.
The problem is you know you can't (except using M4L, so actually you can do the samé as with Reaper) change anything in Live, but in Reaper I always find some limitation whenever I want to really change or add something.
That's also why many user extension are hacks around this limitations (Reaticulate or retrospective record or...). You can't even colorize the rows in the MIDI editor per note.
So Reaper's scripting really is is 'only' better macros, no real interface to internal dáta, so no chance to get non-hacked extensions.
But at least the key command menu is better than in Cakewalk, which has the most braindead implementation of a keybinding menu of any program that I know of.
So: great for audio with your custom scripts/macros, I still prefer Samplitude together with Soundforge though. For MIDI: Cakewalk is about the samé (and is also lacking retrospective record) but has articulation maps and actually colors your piano roll when using scales instead of just the keys. Or Live 11, if you want a MIDI editor that has exactly the features you need in a way that's not configurable in Reaper (you can't context sensitivly change the mouse actions to get the pointer as 'smart' as with Live, I still too often erratically generate a note).
If Bandlab would add an alternative (Python or Lua) to the (deprecated) CAL scripting and an official documentation instead of http://dgcardenas.fpmit.com/cal/...
So, tl;dr: really disappointed about the limited scripting customizability and limited docking cababilities of Reaper. One of the few programs I'd actually change the source code of if possible, out of frustration of missed opportunities.
The problem is you know you can't (except using M4L, so actually you can do the samé as with Reaper) change anything in Live, but in Reaper I always find some limitation whenever I want to really change or add something.