[nama] Re: Runtime limit

On Wed, Aug 08, 2012 at 12:57:35PM -1000, Joel Roth wrote:
[...]
> > 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).
> 
> We already have regions, which provide the functionality
> you are mentioning. Marks are used to define a region
> so that is somewhat similar to what you're describing.
Hmm... I had a look at Nama's region a while back, but they only seem to
be a way to export part of a track. How would this be used at
mixdown/bounce time?

> 
> Currently marks belong to the project timeline, not to any
> given track.  However that is potentially ambiguous, since
> marks are placed relative to the beginning of the chain setup.
> If *all* tracks get shifted, the marks shift.
> 
> To move track audio based on special start and end marks,
> we'll need to have track-specific marks.
I wan't thinking of anything quite so extensive; I was just envisioning
a way to specify a begin and end time for the whole project and a
general limit for caching. I pondered track-specific marks a few times,
but the potential for confusion seems too great, and this really would
fall within the idea of regions (as usually understood by DAWs).

[...]
> 
> > 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.
> 
> We already have a way to ask for extra time for reverb, etc.
> 
> nama> cache_track + 2  # adds 2 seconds extra
> 
> nama> cache_track 143  # set processing time to 143 seconds
> 
> Which will be fixed when we properly limit processing
> time.
That's good to know. How about a theoretical situation where one want to
account for delay/reverb on the master buss?

Cheers,
S.M.

Other related posts: