On Wed, Aug 13, 2014 at 09:41:00AM -0700, Len Ovens wrote:
> To be honest, the reason I thought it would be nice is because I was
For good reasons...
> Having said that, most control surfaces that include a transport
There is one other thing to consider. In most cases the transport
section of a control surface will control a single device, it's
just a remote control. In that case it certainly makes sense to
have a RECORD button there, even more so if the control surface
also provides access to individual tracks.
OTOH, Jack transoprt is an API designed to sync multiple devices,
which just happens to be usable as a remote control as well.
If it makes sense to have a RECORD function there is not so easy
to decide, I can't give a definite answer to that question. What
*is* clear is that if this is added then the semantics should be
well defined and not leave room for interpretation. Does a RECORD
button talking to Jack transport have the same effect as the other
buttons - if enabled it means enabling record mode on all controlled
apps ? In that case there is a problem with apps that don't have
per-track record enables, they would be put into record mode even
if that is not wanted. Or is it a 'third level' of control, above
the per-track and per-app record enables ? In that case it's less
useful than you may want - it's still necessary to use the per-app
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Linux-audio-user mailing list