[nama] Re: Runtime limit
- From: "S. Massy" <lists@xxxxxxxxxxxx>
- To: Joel Roth <joelz@xxxxxxxxx>
- Date: Wed, 8 Aug 2012 15:54:08 -0400
On Wed, Aug 08, 2012 at 12:26:05AM -1000, Joel Roth wrote:
> Hi Namites,
>
> How does Nama decide how long the engine should
> be allowed to run?
>
> For track caching, especially, we would like the
> correct value set, or the ability to stop the
> transport in the normal way to end the engine run.
Definitely. That is currently not possible and somewhat problematic when
Nama/Ecasound run amok.
>
> Ecasound will *not* give a useful answer via cs-get-length
> if there is a metronome input, or if there is a JACK client
> source (i.e. as part of an insert).
Ah, so those are the conditions. As I use inserts about 90% of the time,
the behaviour seemed pretty constant to me: good to know.
>
> Nama does know the length of each track, and the various
> offsets and regions.
>
> At the least, we need to limit processing time in the
> the simplest case, where cs-get-length returns a non-zero
> value.
>
> In the absence of that value, Nama needs to make the
> best determination it can, and to print that value
> to the terminal.
>
> We also need the ability for the user to specify
> a run time. We currently have limit_run_time
> nd limit_run_time_off commands (not tested.)
Actually, since you mention this, it allows me to introduce an idea
which has been lurking at the back of my mind for several months now. We
have a virtual mark called Now, which is set to wherever the playback
head currently is. I think we could do with a couple (at least two) more
"virtual" (as in dynamic or partly software-generated) marks, being
Start and End. Rationale?
1) Start mark. A start mark would obviously default to zero (hence
already providing a shortcut to reset the playback head), but it could
subsequently be defined to something else by the user, providing a
useful way to skip over the several seconds of silence often found at
the beginning of a project.
2) End mark. This would provide a reference point for engine finish and
could be regenerated with the set-up.
We could even have a couple more marks like User_End to allow the user
to specify manually where engine should finishe and Cache_End to specify
where caching should end. This would also help solve a minor problem,
which is that mixdown currently starts from 0 and proceeds until the
engine finishes or mixdown is manually interrupted. However, in a
real-life use-case, one usually wants to mixdown only part of the
timeline (e.g 00:04-03:37) which currently requires setting the head by
hand and monitoring the time to interrupt processing or trimming the file
after the fact (which is what I usually do).
>
> Finally, to be able to interrupt any processing
> with the spacebar would be useful and is expected.
>
> We have two mechanisms to enforce a limit on runtime:
> the cs-set-length command, and Nama's own ability
> to set a timer to trigger a stop command.
Like Julien, I think the second approach might be best, as it always
leaves nama in control and, in any case, we never operate ecasound in
full batch-mode if we wish to retain the ability to interrupt with the
spacebar.
I also think Julien made a good point about potentially needing to
extend processing beyond file length because of such things as reverb,
delays, and latency compensation. On the other hand, this may prove too
intricate and error-prone, and it might just be easier to set a sensible
default and provide the user with a convenient means of altering the
setting if/when required.
I really think that doing this through marks, rather than commands,
might be more elegant and intuitive, as it mirrors more closely what
other DAWs do.
Cheers,
S.M.
Other related posts:
