On August 12, 2014 12:26:04 PM Fons Adriaensen wrote:
> 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 ?
Apologies, wasn't sure :-)
> 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].
Interesting... a pause state.
>
> 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.
OK I think I understand now:
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.
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 '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.
Agreed.
> > 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.
Yeah. Traditionally play is a mechanical state (as in "forward ho!") and
record is not really a mechanical state but just a switch commanded
to turn on the record circuit and head etc.
That's why I tried to eek out some definitions yesterday but had trouble.
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.
> Punch in/out can be controlled
> locally, and today it will be preprogrammed anyway. [3]
Not sure about global punch in/out. Maybe.
But as with the record functions, each app would have to have a way of
letting the user elect to participate in the global override(s) or not.
But, if the mechanism by which record functions could be added
could easily include other commands such as punch in/out, why not eh?
>
> Caio,
>
>
[Speaking my language here - Pro repair tech, 30+ years]:
> [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.
How would these decks be told by software to come out of deep-pause mode?
To use my understanding of your proposal, paragraph above, the user's
(software) play button would flash indefinitely (meaning not ready)
until he presses it, and it'll be a moment until the VCR can be ready
to play again.
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?
Ah... But you will say: A system where one of the decks is in deep-pause
mode is not ready at all - it needs to be (manually) taken out or kept out
of that mode when anticipating that recording will take place soon,
to satisfy the instant run requirement. Right?
>
> [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.
MusE has pre-programmed punch in/out.
Can't recall if can be activated remotely.
Pleasure rappin' with ya.
Tim.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Wed, 13 Aug 2014 00:08:51 -0400
This archive was generated by hypermail 2.1.8 : Wed Aug 13 2014 - 08:15:02 EEST