On Wed, Aug 13, 2014 at 12:08:51AM -0400, Tim E. Real wrote:
> Interesting... a pause state.
It's typical for video recorders (and DAT). Software apps wouldn't need one.
> With the current system, the user 'presses play button', but the button
How 'not ready' indicated is a side issue. It could be STOP flashing
when stopped and PLAY flashing if you try to start, or some separate
> I would add: If play is flashing he shouldn't have to press it again when it
The 'not ready' feedback exists to avoid the user trying to start
when it will fail, so this shouldn't happen. But when it does, yes
I'd agree that the start command should be remembered (as in fact
it is now).
Some of the tape machines I used could locate to some stored
position, and while they were doing this you could hit PLAY.
If the fast wind was forward they wouldn't even stop, just slow
down when approaching the locate position to arrive there at the
the correct speed and then go into PLAY. That's nice transport
In software such things are almost trivial to implement, and they
make a difference. Ardour fails here when controlled via OSC. If
you send a 'locate' and then 'play' it will in many cases ignore
the 'play' command. You need to insert a delay between the two
to makes this sequence reliable. This hit me when I was writing
the automated systems used at the CdS, which led me to write a
dedicated player app and think a bit about reliable remote control
> Still, to satisfy the OP request, there could be a global record ENABLE,
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.
> > Punch in/out can be controlled
It's never a global thing. One app would do a punch in/out while
the others are just playing. And if not you're doing something
quite complicated, and this will need to be set up and checked
locally on each app anyway.
> How would these decks be told by software to come out of deep-pause mode?
It would be local, or just by sending STOP. And most probably, when
put into remote control mode any 'deep sleep' mode would be disabled.
Anyway for SW apps such a state should not exist at all.
> From the software POV, the play command would have to be sent and
They way I've implemented this in some players uses four states:
all combinations of [STOP, RUN] and [READY, NOTREADY]. A state
that includes NOTREADY is always transient, it will revert to the
corresponding READY one as soon as possible.
The combination RUN, NOTREADY is the one that Jack's 'slow sync'
implements. But it doesn't have STOP, NOTREADY. So that is what
I'd add, together with the requirement that NOTREADY must be
transient, i.e. an app is allowed to be not ready but must always
try to get ready ASAP, and not wait for e.g. a START command to
do so. Being ready of course includes that the audio path is or
can be set up, so things like only creating Jack ports when
started (Audacity) are a definite no-go.
> Pleasure rappin' with ya.
Same here :-)
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