On Wednesday 18 December 2002 18.09, Steve Harris wrote:
On Wed, Dec 18, 2002 at 05:25:18PM +0100, David
Olofson wrote:
But then you have to stop the whole net along
with the sequencer,
as soon as you have one of those "non-instant" plugins in the
net. The very point is to avoid that.
Effectivly you have to anyway.
I can't see why. You don't even have to stop the plugins that aren't
ready. They *could* actually be capable of doing real processing
while doing background work.
For example, you don't have to kill the whole sampler just because
it's loading a new sound for one of it's Channels. (This applies to
Audiality, BTW. It *never* stops the RT engine, not even when loading
and rendering sounds.)
Realigning all the plugins will take a non finite
time, so you have
to do something while the're busy.
So, why not just keep processing audio, so you don't kill the monitor
mix and whatever might be going on in the net?
I'd *really* like XAP hosts to be able to behave like *real
hardware*, now that we have an OS to provide the lowlatency
scheduling, and real audio interfaces for quality audio.
Besides, this
doesn't just happen when you activate a plugin, but
could happen as soon as you move the transport, or change a
control. Sure, it can be handled with control hints, saying these
controls are not RT safe, but I think that's a bit restrictive.
Are you expecting that the graph will continue to execute while
you're waiting for the realignment? That seems a bit optomistic and
not particularly useful.
(See above.)
OTOH I'm not sure that a delay line (for example)
can handle this
usefully at all, it can't prefill its buffers with the previous n
seconds of audio (which is what it would like to do), so all it can
do is reset back to its inital state (unhelpful and slow) or ignore
it (even more unhelpful).
Ignore what? A delay plugin is never expected to prebuffer anything
at all. It's just expected to delay whatever it receives.
If you really want a song that you start in the middle to sound
*exactly* as if you were doing the same thing with a prerendered
audio file, it's getting really rather hairy.
The idea with the READY thing is just to be able to let the sequencer
know when a plugin is ready to start playing. The alternatives are:
1. Ignore the problem and have the host freeze, lose
sync and whatnot while some plugin needs to prebuffer.
2. Just ignore the plugins that aren't ready, and play.
They'll chime in eventually. Expect the user to wait a
little longer before hitting "play" after moving the
play cursor, if he/she finds this random delay, missed
or delayed first notes etc annoying.
3. Allow the sequencer/host/transport control wait until
plugins say they're ready for instant playback.
1 is obviously out, because it makes some sound cards freak out in
various ways, which in turn may upset external sync'ed devices etc.
That leaves 2 and 3, which are identical to plugins, except that in
3, they have a standardized control through which they indicate their
status.
Its basicly just sequencers (ie. plugins with
internal, temporal
data) that can do something useful with this, right?
No, it would work for samplers, hard disk recorders and the like as
well. I've suggested a way to tell HDRs about the play cursor before
starting the transport. The READY control would be a logical
complement to that, for hosts that care.
It may not be a vital feature, but it's a real problem, and I think
this is a simple solution for it.
Don't mix it up with managing background threads and stuff - that's a
different problem, really. (For which I think I have a simple
solution for simple cases, BTW. Linuxsampler will just have to use
pthreads until XAP 2.0. ;-)
//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 ---