the_user_formally_known_as_glennbo
I remember losing perfect takes a few times with Sonar because I thought I was in record ready, when I really only had input monitoring turned on. That has NEVER happened to me in REAPER, and I actually remember thinking it was a more logical way for a DAW to work when I first started using REAPER.
You can not start recording in Sonar till you arm. In Reaper you also can press play button instead of Rec and so do not record what you have thought. And there is still the case of "Arm:yes" and "Record:disable"...
EDIT: for clarity
Up to now, what I have seen in Reaper was logical, consistent and flexible. That feature at not at some points.
There is "Record Arm", "Record monitor", "Record" and "Input". Many combinations are allowed but do not have much sense for me ( "Input:None", "Record:input", "Arm:yes"; "Input:MIDI All", "Record:input (force stereo)", "Arm:yes") other are "exotic"
("Input:MIDI All", "Record:audio/midi", "Monitor:Off", "Arm:yes"). So 4 different sets of options to influence what should happened with the input and recording, many combinations of which make no sense but rather simple wish is FORBIDDEN by design. If I am allowed to "record nothing" I expect that I am also allowed to "just listen the input" without arming.
To make it clear. That is not a show stopper. In general I LIKE the way this part of routing is implemented in Reaper and it covers/simplify much more use cases then Sonar approach. That is why I have not noticed any inconvenience in my tests before.
I just do not like to see something is "Armed" if I have no intention to record. F.e. if some track(s) are for "play along", I do not want see them as "armed" nor as "auto armed".
I would prefer to have everything the way it is, but I would like to see. "Input monitor" IN ADDITION to what is there.
Can be:
a) just one extra "Input monitor" button, with an option of "auto on when track is selected". But yet another button/options set does not sound as a nice proposal... so
b) a possibility to switch "Record monitor" into "Input monitor" mode. I do not see any reason when both are required in parallel. Note that "Record monitor" echo much more than just the input (since it is possible to record not only the input). All other signals are enabled by default, so Parent get everything from its children, sends are working (obviously) without arming anything. So why not allow normal hardware inputs routing without arming?
My conclusion: current implementation assumes any external signals are for RECORDING only. My wish is to allow them for PLAYBACK as well (as is the case for all internal signals).