On Mon, Aug 11, 2014 at 08:01:40PM -0400, Tim E. Real wrote: > Mm, do you know about the 'slow-sync' Jack callback function? Of course I do. Do you really think I'd comment on anything without knowing it inside out ? That very 'feature' is the problem. > Or do you propose something slightly different? > As in, able to report readiness anytime all the time even in stop mode? Yes. Together with the requirement that any app using the transport API should be ready to start running (playback and/or recording previously armed tracks) instantly a reasonable time (at most a few seconds) after it has been repositioned or reconfigured. Or at least have a state - PAUSE - in which this is the case [1]. In fact any app used for audio recording or playback in a production context should have that property even when used separately, without Jack transport. All professional audio or video equipment I've ever used could do that, even in the tape days [2]. It's a rather basic requirement, and not at all difficult to implement. In other words, the not-ready state should be transient, it will revert to ready ASAP, and it serves mainly as a warning to the user. As soon as everybody reports ready, you know you can start instantly, which is very reassuring in a live context. > The 'slow-sync' Jack callback function is a great feature for > holding up the transport until all the apps report they are > 'ready to roll'. To be able to start 'on cue' they must be ready when the start command arrives and NOT delay it. Starting on cue is a very common thing in broadcasting, theatre sound, live shows, audio drama production,... to name just the few cases I've encountered in my work. > But... not ready for what? The app cannot know what the > next transport intention is until the actual command > comes down the line. Ready to do what would be required 'on cue', i.e. playback. Recording on pre-armed tracks is no more difficult, so I'd include that as well. All the rest (repositioning, preparing to record) can take any time you want, nobody expects that to be 'instant'. I don't think that a global RECORD command or state should be part of a shared transport control, it's local thing for each of the controlled items. Those that have RECORD enabled will record when started. Punch in/out can be controlled locally, and today it will be preprogrammed anyway. [3] Caio, [1] Video tape recorders used to have a separate PAUSE state since leaving the tape static against the rotating drum for too long would damage it. Audio tape recorders usually did not have a separate PAUSE state, they could start instantly from STOP. [2] I know of one professional tape recorder that would spin down the capstan when idle for more than a few minutes. But even that one would warn you a few seconds before doing that, and hitting STOP would override the spindown and keep the transport ready to start instantly. [3] In the 24-track tape days punch in/out could be done either by pre-arming the required tracks and then using the global RECORD at the right time(s), or by starting with RECORD enabled and then using the per-track controls to punch in and out. The latter would be difficult in a software DAW, unless the tracks are prepared in some way previously (which happens implicitly when using the first method). But it's not really required, the first method works OK, even more so if things can be pre-programmed as in Ardour. -- 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
