On Wed, 13 Aug 2014, Fons Adriaensen wrote:
On Wed, Aug 13, 2014 at 12:08:51AM -0400, Tim E. Real wrote:
Those that have local RECORD ARM enabled will record when started,
provided global record ENABLE is on.
That assumes that all apps have per-track record enables. A simple
stereo recorder/player won't have them.
Anyway, to set up recording you'd have to access the local user
interface of that app, so having to enable record there is no big
deal. To me it also feels safer.
To be honest, the reason I thought it would be nice is because I was
looking at an app with no MIDI control in, but does have jack transport
control. I was thinking that a master record enable was the one thing
that traditional tape transports control clusters had that was missing. Of
course just because it is traditional is not a great case for including
it. On a tape machine all the controls are clustered for other reasons and
the record arm sometimes does have more space around it or is sunken or
has ridges on its sides.
Having said that, most control surfaces that include a transport section
and for that matter, most sw that has a transport section laid out in the
gui, has the record enable included in that group. So it is a tradition
that is still in common use. What would be called a defacto standard or a
standard by tradition. Again I don't know if it is a good standard or not
but that is where the hand of a recording machine operator will look for
the record button.
The next question is if a control surface should directly control jack
transport. I think the answer is that enough people think is should that
there are a number of standalone jack transport controlers around. Really
the only thing missing is the record functionallity to be complete.
Nudging and shuttling are already easy to do... I suppose scrubbing, or
playing back at non-standard speed is not there, but I am not sure how
that would be done and for now at least, this is not a universal thing
that SW does, so most apps would ignore it anyway. A state that says make
noise even if we are not in play, but we move the transport?
The whole thing comes down to sync and the purpose behind it. This is much
more common in Linux than other places because we can. The purpose is to
take a number of applications and perhaps physical playback/record devices
and to use them all as if they were one machine. From that POV, a single
transport control makes sense. From that POV, using one control surface
for more than one application/device also makes sense. I would suggest,
however, that this practice is becoming less common as applications add
more functions and become more "all in one". It seems that audio recorders
now edit MIDI (and have instrument plugins) and MIDI editors record and
playback sound. Even video can be included. When I first started doing
music on computers, recording audio on a computer was just a dream. MIDI
was no problem (if you stayed away from windows) and so audio was recorded
on a tape machine and the computer sequencer followed the timecode
stripped on track 8 (permanently set to record at -10db for this purpose).
Sync was the only way to get enough tracks for many things. Not any more.
Just to be complete... I have looked at OSC. OSC is very flexable.
However, that flexability seems to be it's problem too. There is no way to
create a generic control surface with /softwarename/track1/gain and then
go "bank up/right" and have the mapping change to
/softwarename/track9/gain within the software... no standards for this. To
be fair, there was not in MIDI either till people started making control
surfaces and the software had to deal with whatever they put out and that
became the standard (The mackie control protcol for example). However, as
a contol surface manufacture, why would I make an OSC product? What market
share would that gain me? Really, in order to even create a middleware
converter from MIDI controller to OSC would be a pain. I would have to do
all the banking in that middleware. I would have to know all the strip
names (takeing non-mixer as an example
"/strip/stripname/pluginname/paramname param") and map them to a number...
or name them in an unituitive manner in the first place. Ardour uses
something totally different "/apname/route/function tracknumber param".
The ardour method at least could be banked reliably. I suppose a patch bay
kind of middleware that showed controler outputs and SW inputs for control
could work, but it seems poor to have a user patch what would be normal
routing for each project. OSC has a way to go, IMO, it is not ready to use
with control surfaces.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
