On Mon, 11 Aug 2014, Tim E. Real wrote:
On August 11, 2014 07:21:17 PM you wrote:
On Sun, 10 Aug 2014, Tim E. Real wrote:
On August 10, 2014 09:24:12 AM Len Ovens wrote:
Is there a record enable in there? It seems to me it would be worthwhile
One of the sub projects of this software is to split the computer keyboard
so that the numeric keypad can be used as a midi/jacktransport control
surface while the rest works as the system keyboard still, so I have an
interest in a more complete jack transport from that POV.
Hmm ...
The only way I could see this in terms of the Jack Transport 'states'
is to add some new states:
For example:
JackTransportRecordArm (maybe to help prepare)
JackTransportRecordEnable (subsequent play mode actually means record mode).
MMC, from what I have read, seems to support two record enables:
- arm tracks for recording. While these are in the realtime section of
commands, I would think these would be the commands run before roll to
give sw time to get things ready to record.
- Then there is punchin/out or master recordenable which is meant to be
realtime and should start the app recording with no transport stumble or
wait.
Now maybe there are people who think using track-rec-enable for
punchin/out is the way to go, but I can't see myself working that way. I
also do not think it would be the right thing to do, to expect jack
transport (or any other transport) to arm tracks of multiple apps... or
even one app, because this would assume a static number of tracks. The
punch in/out master rec-enable does make sense though. all the enabled
tracks would record at the same time.
But those do not qualify as 'states', they are just commands !
Yup.
So we might propose something like:
JackTransportRecording (in actual recording state)
Ok, I, in my limited POV, don't see a need for this unless one of the apps
fails to start recording and wants to signal this somehow.
But then we might also need something like:
JackTransportRecordStarting (so that the app can differentiate between
play starting and record starting modes, and tell Jack Transport to wait)
IMO, they are the same thing. When getting ready to play, anything that
needs to be ready for record should be done too. The transport can not
wait at the punch in point for sw to get ready or else the whole punch in
concept is void. Any sw that has a track recenabled should be making sure
it is ready to record on those tracks before playing. It _may_ be OK for
an app to start recording some ms late provided the actual time of the
record starting is saved as the punchin point for that app... this gets
messy real quick though.
If there is to be any "get ready time" at the record strobe, the play
state must not change once started just for recording sake, better a
system wide record start delay of the punch in point.
I still feel the app should be ready to record anywhere from the play
start with no delay.
Obviously difficult to ensure compatibility with existing apps, I suppose...
I would expect an old app to ignore it (them, punch in and out) and lets
get fancy and ask for the moon... jack transport would of course drop in a
MIDI port for telling these old apps to start recording :D
In MusE you can map any midi note to any of the transport functions :-)
For example hit a high 'C' and it starts playing.
It has mappable Stop, Record, Goto Left Marker, Play, and Step functions.
With the variety of MIDI control surfaces around, one pretty much has to.
And now having gotten my feet wet with jack midi stuff... I am thinking of
a MIDI control surface mapping app that takes MIDI in from a control
surface and splits it for a number of applications. The idea being that a
controller that has 8 channels and does banks, might send controls for
bank 1 and 2 to one app and bank 3 to a second and maybe bank 4 to a
third. While it may be possible to auto figure out how many banks each app
has, the operator might be better for settng it up and knowing what is
what. Of course as apps become more "do everything" the use for such a
thing may be waning.
I have looked at OSC... but it has no standards (bad way of trying to
make my point), each signal seems to have
to be directed at a particular app/control. There seems to be no generic
controls where a generic control surface can be used. Maybe that is
because all the docs I have read are showing off it's flexablity. It seems
even a native OSC control surface would need middleware to rename the
signal so the destination was correctly chosen.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
