19 Dec
2002
19 Dec
'02
1:40 p.m.
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:
that's the reason why I'm still a happy user of my Atari ST when performing
on stage :-)
very good!
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(a)home.nl /\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?
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. '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.)
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.