7 Dec
2002
7 Dec
'02
5:18 p.m.
Not defining them seperatly, but making a distinction,
I dont think one
control should be applied per voice and per instrument.
So one should not be able to manipulate a per-voice volume and a master
volume?
So no one has
offered me any suggestions on how we handle the clash between
Master and per-voice controls. To re-ask:
Ban it :) No, velocity != loudless.
ok, we agree on that.
However, even in midi there can be more than one
velocity value per note,
there is seperate release volcity IIRC. I expect the only reason attack
velocity is package up with the note start in MIDI is because otherwise
they couldn't guarantee it would arrive at the same time, and it saved a
few bytes.
MIDI has 2 velocities - note_on and note_off. I see velocity as specific to
those two events. Isn't a new velocity event really a new strike or attack
of the instrument, or, in other words a new voice (even if it cancels the
previous voice)? That said, I hate that Velocity is special. I could be
convinced. I could also stand and argue. Not sure I know which I prefer...
> we can say 'just load a new instance for the
new channel'. It prevents
There are probably other reasons why you /might/ want
this, but I cant
think of anyoffhand. I suspect one is OK and it makes things nice and
simple.
I agree, and simplicity is better, I think. Still needs more noodling. If
it is obvious and easy, then I don't really mind it.
Analogue synths generally dont, some have channel
pressure, but that is
slightly different and variable through the duration.
channel pressure would be a separate control, just as it is in MIDI.
Not really the host can just allocate them from a pool
of 32bit ints (for
example) and pass them in by the new_voice call.
but if a plugin controls another plugin (as suggested by David) the
'pseudo-master' needs to either be a full-fledged host, or needs to get a
pool of VVIDs from the host via a host->get_vvid() callback. It's not TOO
bad, I guess.. But I don't see it as being a big-win on any front as
compared to a synchronous vid = plug->voice_on() mechanism.
This raises
another question for me - the host sends events to the plugins.
Do the plugins send events back? It seems useful. The host has to handle
syncronization issues (one recv event-queue per thread, or it has to be
plugin -> host callback, or something), but that's OK. Do timestamps matter
to the host, except as bookkeeping?
I'm not sure what the instrument will send back to the host that needs to
be timestamped. Well, we were talking about floats, strings or opaque
data blocks before,
so presumanbly the event would be either a float, a pointer to a string or
a pointer to a data block (+ a size).
Assuming that control changes are the only types of events that flow.
some events, off the top of my head..
VOICE_ON (plugin to host) ?
VOICE_OFF (plugin to host and host to plugin)
VOICE_CTRL (host to plugin)
MASTER_CTRL (host to plugin)
SILENT (plugin to host - sent when reverb tails or whatnot have died..)
If you need to send it over a wire you will have to
serialise the strings
and blocks in variabley size chunks, but thats unavoiadable.
yes, and let's not make this a wire protocol :) Seperate project.
Its not purely aimed at instruments, but its heavily
focused that way, it
probably wouldn't make sense to use this API for something LADSPA can do
well (eg. audio+control -> audio+control). If you need timestamps or
polyphony then this would be the way to go, but realisticly that means
intruments and a few other odd cases.
Well, assuming a LADSPA wrapper in this API, a host can transparently use
LADSPA plugins in a multi-channel way. Stereo reverb can be built out of
two LADSPA mono reverbs. Just an idea.