4 Dec
2002
4 Dec
'02
5:38 p.m.
I disagree
with that - this is a waste of DSP cycles processing to
be sent nowhere.
So, why would you ask the plugin to set up outputs that you won't
connect, and then force the plugin to have another conditional to
check whether the output is connected or not? I would propose that the pre-instantiation host/plugin
"negotiations"
including:
* A way for the host to tell the plugin how many ports of
each type it wants for a particular instance of the plugin.
This is exactly what I'm talking about with the connect methods. Before we
go into PLAY mode, we ask for a certain number of channels.
* A way for the host to *ask* the plugin to disable
certain
ports if possible, so they can be left disconnected.
hmm, this is interesting, but now we're adding the conditional
plugin with two 1D, contiguous arrays (although
possibly with some
ports disabled, if the plugin supports it); one for inputs and one
for outputs. That will simplify the low level/DSP code, and I think
Yes, I've come around to this. The question in my mind is now about
disabling (or just not connecting) some ports.
Now, if the plugin didn't support DisableSingle on
the output ports
of type Out;5.1, you'd have to accept getting all 6 outs, and just
route the bass and centel channels to "/dev/null". It should be easy
enough for the host, and it could simplify and/or speed up the
average case (all outputs used, assumed) of the plugin a bit, since
there's no need for conditionals in the inner loop, mixing one buffer
for each output at a time, or having 63 (!) different versions of the
mixing loop.
ok, I see now. If the plugin supports disabling, the host can use it. If
the plugin is faster to assume all ports connected, it does that instead. I
think I rather like that.
think it's a bad idea to *require* that plugins
support it.
This is key, again, you've convinced me.
strongly prefer working with individual mono
waveforms, each on a
voice of their own, as this offers much more flexibility. (And it's
also a helluva' lot easier to implement a sampler that way! :-)
just so we're clear, 'voice' in your terminology == 'channel' in
mine?
...provided there is a quarantee that there is a
buffer for the port.
Or you'll segfault unless you check every port before messing with
it. :-)
Do we need to provide a buffer for ports that are disabled?
Hrrm, so how
does something like this sound?
(metacode)
Yeah, something like that. Add "count granularity", and you'll make
life for the plugin coder a lot easier, I think. (Again, see above.) > { "left(4):mono(4)" }, {
"right(4)" },
Does this mean the plugin is supposed to understand
that you want a
"mono mix" if you only connect the left output?
If the host connects this pad to a mono effect, it knows that the
'left' channel is also named 'mono'. I do not expect the plugin to
mono-ize
a stereo sample (though it can if it feels clever).
all that much to it. There's no sensible way of
describing the
input/output relations of every possible plugin, so it's debatable
whether we should care to try at all.
I'm agreeing now..
* note_on
returns an int voice-id
* that voice-id is used by the host for note_off() or note_ctrl()
That's the way I do it in Audiality - but it doesn't mix well with
timestamped events, not even within the context of the RT engine
core. I don't think that's a good idea. The synth
has a much better chance
of knowing which voice is "best" to steal - and if smart voice
stealing is not what you want, you shouldn't use a polyphonic synth
or sound.
ok, ok.
Besides, VSTi has it. DXi has it. I bet TDM has it.
I'm sure all
major digital audio editing systems (s/w or h/w) have it. Sample
accurate timing. I guess there is a reason. (Or: It's not just me! :-)
yeah, VSTi also has MIDI - need I say more? I'm becoming convinced, though.
What kind of knobs need to be ints? And what
range/resolution should
they have...? You don't have to decide if you use floats.
They should have the same range as floats - whatever their control struct
dictates.
I'd assume
a violin modeller would have a BOWSPEED control. The
note_on() would tell it what the eventual pitch would be. The
plugin would use BOWSPEED to model the attack.
Then how do you control pitch continously? ;-) Some controls may not be possible to change in real
time context -
but I still think it makes sense to use the control API for things
like that.
I don't know if I like the idea of controls being flagged RT vs NONRT, but
maybe it is necessary. Or maybe it's not, and a user who changes a sample
in real time can expect a glitch.
An Algorithmically Generated Waveform script...?
BUt what I don't get is: who loads the data into the control?
a) hast will call deserialize() with a string or other standard format
b) plugin will load it from a file, in which case host passes the filename
to the cotrol
c) host loads a chunk of arbitrary data which it read from the plugin before
saving/restoring - in which case how did it get there in the first place?
(see a or b)
Well, then I guess you'll need the "raw data
block" type after all,
since advanced synth plugins will have a lot of input data that
cannot be expressed as one or more "normal" controls in any sane way.
Such as? Where does this data come from in the first place?
Just as with callback models, that depends entirely on
the API and
the plugin implementation. AFAIK, DXi has "ramp events". The
Audiality synth has linear ramp events for output/send levels.
So does Apple Audio Units. I am starting to like the idea..
Audiality, but
if we're designing the same thing, why aren't we
working on the same project?
Well, that's the problem with Free/Open Source in general, I think.
The ones who care want to roll their own, and the ones that don't
care... well, they don't care, unless someone throws something nice
and ready to use at them.
As to Audiality, that basically came to be "by accident". It started