from REAPER to ABLETON (one big disappointment)

[xbitz]

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.

>>> https://news.ycombinator.com/item?id=25059663

[antic604]

Adjust mouse modifiers to your taste.

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]

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.

>>> https://news.ycombinator.com/item?id=25059663

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).
Nowadays the same happens with GPU processing too.

[antic604]

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.

>>> https://news.ycombinator.com/item?id=25059663

In light of that discussion, I wonder how Bitwig differs - from dev perspective - compared to Live?

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]

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.

>>> https://news.ycombinator.com/item?id=25059663

In light of that discussion, I wonder how Bitwig differs - from dev perspective - compared to Live?
It's often seen as the better one in terms of CPU performance and multi-threading in particular.

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.

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.

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.

[.jon]

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.

>>> https://news.ycombinator.com/item?id=25059663

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.

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.

[EvilDragon]

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!

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.

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.

[antic604]

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.

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.

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.

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.

U-He makes such quick tests very easy

[NERF_PROTOSS]

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.

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.

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

[ReleaseCandidate]

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

[boriskarloff]

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

OP here. Feel free to express yourself

[boriskarloff]

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...

[antic604]

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...

Nice!

You'll be happy to learn this:

http://www.mossgrabers.de/Software/Reaper/Reaper.html

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

[thecontrolcentre]

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]

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.