Go Back   Cockos Incorporated Forums > Projects > Deprecated REAPER issue tracker > Closed Issue

Traditional Input Monitoring Issue Tools
issueid=2004 02-09-2010 06:18 AM
Human being with feelings
Traditional Input Monitoring
Separate Functionality of Record Arm and Input Monitor

As per this thread:

The record arm and input monitor buttons must operate in mutual exclusivity of one another, as they do on a conventional multitrack tape machine. Their roles have been clearly defined through decades of practice. If the analogy of a separate mixer and tape deck is being carried over to Reaper then the functionality must be extended to Reaper, as well.

I propose that:

i. The sole function of the record arm button be to enable or disable recording on a track.

ii. The sole function of the input monitor button be to select which signal i.e. pre-recorded or live is being output to the mix bus.
This functionality must persist regardless of the state of the transport and regardless of the state of the record arm button.

iib. A third possible option discussed in the above-referenced thread is a monitor state in which *both* signals are output to the mix bus simultaneously.

Here, then, is my proposal for the right-click monitor mode menu:
Monitor Recorded Track
Monitor Input
Monitor Both
Tape-Machine-Style Monitoring
It should be noted that "Tape Machine Mode", as found in many DAWs, is not a monitor mode unto itself, rather a 'macro' of sorts, which automatically switches a given track's monitor mode to 'input' when armed for record and to 'tape' when unarmed. The user can, of course, choose to manually override "Tape Machine Mode" as circumstances dictate.

Thanks you,

Issue Details
Issue Type Closed Issue
Project Deprecated REAPER issue tracker
Category Audio recording and playback
Status Duplicate
Priority 3
Affected Version 3.22
Closed Version (none)
Yes votes 21
No votes 0
Assigned Users (none)
Tags (none)

02-09-2010 06:22 AM
Super Moderator (no feelings)
08-01-2010 05:56 AM
Human being with feelings
Not a duplicate, but similar.

I'm approaching this with the mindset (and terminology) of a tape-machine operator, and, of course, I'm biased towards my own proposed implementation, which would be more familiar to those who use(d) tape (And no harder to grok for anyone else).

I'll admit that while I see where the other poster is going, conceptually, his take the matter is not what I'd call conventional and I think it adds an unnecessary layer of complexity.

In any case, we both have the same end result in mind so at the end of the day we're on the same team, which is really what matters. I'm happy to quibble over the details once this feature goes into production.

Issue Tools
Subscribe to this issue

All times are GMT -7. The time now is 03:49 AM.

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