[linux-audio-dev] XAP: cue points / looping

[Frank van de Pol]

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?