Subject: Re: [linux-audio-dev] XAP: cue points / looping
From: Frank van de Pol (fvdpol_AT_home.nl)
Date: Thu Dec 19 2002 - 19:37:38 EET
David, thanks for the quick and elaborate explaination. I now understand
your rationale.
++ votes for PCPs.
-- votes for loop start/end.
Otoh, knowing in advance when a loop will occur might be usefull for some
applications (I can't really think of an good example, the best I can come
up with is sample stretching over duration of loop)
I love the concept of the READY signals to be connected by the user where
needed.
Frank.
On Thu, Dec 19, 2002 at 05:53:00PM +0100, David Olofson wrote:
> Well, your question indicates that "cue point" is not the right term
> for this thing.
My 'cue point' was the generic event to get a notification when a certain
point in playback is reached. I understand this a not specific enough.
Perhaps I should have called simply point or marker.
I use these kind of markers all over the place; for snapping beats between
tracks, track markers for CD burning, hints to help me keep an eye on the
structure etc.
> The "objects" I'm talking about are "Zero Latency Start Points" or
> "Precache Points". The whole point with them is to let plugins know
> about jump target points that the sequencer wants to be able to jump
> to at any time, without disrupting playback.
ok i'm in.
> So, maybe the loop start + end approach isn't all that smart, after
> all...? Although PCPs do waste more memory, they make the
> applications a whole lot more interactive.
great!
>
> But why not just have instant playback whenever possible?
yep.
>
>
> > Think of a live DJ set where drum loops
> > and songs are triggered etc. A large amount of jitter (random delay
> > time) between trigger and start is very frustrating in those kind
> > of applications.
>
> Yes, but that sort of jitter is just a result of using the wrong tool
> for the job, or using the right tool incorrectly.
that's the reason why I'm still a happy user of my Atari ST when performing
on stage :-)
>
> > 'Waiting till everyone is ready' in a real-time
> > context does not sound good to me.
>
> I give you three alternatives:
>
> 1. Ignore READY and just play. As far as realistically
> possible, samplers and HDRs will start playing at
> the right position when they catch up.
>
> 2. Use READY and wait until the plugins are ready.
>
> 3. Tell your samplers to load the sounds you need,
> and give the HDR PCPs for any points in a sequence
> that you need to be able to jump to instantly. Wait
> until they all are ready. Now, you can play sounds
> and jump to any of the PCPs without drop-out,
> delays or other artifacts.
>
>
> Just pick what works best for each situation. All methods can be used
> at the same time in the same net. (Just disconnect the READY and/or
> PCP controls for the plugins you don't want to prepare or care about.)
>
very good!
> > If you want guarantees you'll need to obey the deadlines from the
> > individual plugins and their patches. This is not different from a
> > traditional MIDI sequencer driving a bunch of synths. I know for
> > instance that I need to give my Akai S3K sampler some time to load
> > patches, I take that into account when putting the sysex/pgmchanges
> > in my sequence. Everyone does that.
>
> Of course - but how do you do it for a HDR...? These are two related,
> but slightly different problems.
not too different; only the setup times are different. I'm still glad I
don't have a analogue tape to synchronise to.
In practice, your sequences will have some bars reserved at the start of the
song in which you setup you gear.
Frank.
-- +---- --- -- - - - - | Frank van de Pol -o) A-L-S-A | FvdPol_AT_home.nl /\\ Sounds good! | http://www.alsa-project.org _\_v | Linux - Why use Windows if we have doors available?
This archive was generated by hypermail 2b28 : Thu Dec 19 2002 - 19:53:13 EET