21 Dec
2002
21 Dec
'02
12:17 p.m.
On Friday 20 December 2002 02.58, Tim Hockin wrote:
Yes.
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.
CuePoints are absolute ticks, right? The problem I see with PCP (I prefer to think of it as
jump-point)
Yes, that's what they are.
is that your PCPs are either global to all plugins in
this
timeline, or local to each plugin. If they are global, then
absolute position does you no good. A synth that gets a VOICE_ON at
bar12:beat3 has no idea what it means to have a PCP at tick 8675.
A synth would not care about PCPs at all, unless it's actually a
"vocaliser" that's generating backing harmonies from a HDR vocal
track or something like that. (And then, the data would probably come
from the HDR anyway. The "vocalizer" is just an audio effect, and
doesn't even need basic beat sync.)
If you jump back in time (loop) you need to either
trigger that
note again and seek to the position, or seek backwards (if it was
playing when you jumped).
Yes, but that's a different problem entirely. Synths can't do this
anyway, unless they have integrated sequencers.
The only things that can make use of this are things
like
disk-streaming plugins, which start at bar1:beat1. The idea of
passing an absolute-ticks value to a plugin is wrong, with the
exception of 'automatic' starting plugins, like a disk streamer.
We pass absolute position to POSITION aware plugins because it is a
clean way of indicating the passing of transport-time for any that
want to sync, and for things like disk-streamers. Are we to add
this feature JUST for those plugins, also? I'm not completely
against it, I just want to make sure we're all clear that it's not
so useful to anyone else.
Right. A synth should (probably) never have PCP support, since it
can't do anything useful with it anyway.
The purpose with the PCP interface is simply to have a standard
protocol for the timeline/prebuffering stuff.
The alternative would be to enforce that timeline and transport are
part of the HDR, and that sequencers always slave to HDRs. That way,
a HDR can implement this stuff internally - but obvisously, you can't
make this work with more than one "unit" of this kind in the system.
Also, it might be a bit weird to have to load part of your song (the
timeline) into the HDR, and the rest into the sequencer...
Or am I really missing something?
No, PCPs and the proposed SEEK control solve two different problems.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---