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 > then flashes informing the user it will be a few moments before we're > actually running, then it stops flashing and system runs. > > With your proposal, the 'play' button flashes informing the user the > system is busy - BUT - at least when it stops flashing, he is /guaranteed/ > that the system will start immediately. 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 indication. > I would add: If play is flashing he shouldn't have to press it again when it > stops flashing, so let the system remember that he did in fact press play. 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 design. 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 protocols. > Still, to satisfy the OP request, there could be a global record ENABLE, > while still granting that record ARM is strictly a local thing. > To rephrase your last sentence could be: > 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. > > Punch in/out can be controlled > > locally, and today it will be preprogrammed anyway. [3] > > Not sure about global punch in/out. Maybe. 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 > then we wait for a signal from the deck that it's ready. > Which is what the slow-sync callback does. > Seems both it and your proposal would be good to have? 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 :-) -- FA 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 Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
