[gmpi] Re: Parameters / controls / GMPI event system - refreshment
- From: thockin@xxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 30 Nov 2005 20:43:32 -0800
On Thu, Dec 01, 2005 at 04:38:44PM +1300, Jeff McClintock wrote:
> >t0: VVID(60).cutoff = 0.7
> >t0: VVID(60).velocity = 64
> ..-- VVID(60) is playing
You can't assume that it is playing as soon as the velocity is set. Some
instruments don't have a concept of velocity. Some instruments have
velocity that can change continuously. You have to decouple the note-on
from any particular control.
> >t1: deactivate VVID(60)
> > -- VVID(60) goes into release stage (I have a long envelope release)
>
> >* I press key #60 on my keyboard again:
> >
> >t0: VVID(60).cutoff = 0.1
> > -- What happens?
>
> You forgot Velocity (you pressed key 60 again)
The events don't have to come in any order. They are all on the same
timestamp, but they have no guaranteed relative ordering within that
timestamp. My point was that when you see that first cutoff event, you
don't know what the intent was.
> you triggered a new note. The correct behaviour for any keyboard
> instrument I can think of (Piano, Organ, Mellotron, Rhodes, Clavichord).
You don't know that yet. All you know at this point is that I sent a
cutoff change for VVID(60).
Now, we can tighten the semantics of note-on to eliminate the allocate
step. If you make the rule that all the events that apply to a note-on
MUST occur on the exact same timestamp as the note-on event, then you
don't really need the allocate step. That adds it's own complications.
For example a plugin needs to know that the following two sequences are
the same and refer to 2 different voices:
t0: VVID(60) note-on
t0: VVID(60).cutoff = 0.7
t0: VVID(60).velocity = 64
...
t1: VVID(60) note-on
t1: VVID(60).cutoff = 0.5
t1: VVID(60).velocity = 120
t0: VVID(60).cutoff = 0.7
t0: VVID(60).velocity = 64
t0: VVID(60) note-on
...
t1: VVID(60).cutoff = 0.5
t1: VVID(60).velocity = 120
t1: VVID(60) note-on
> The real issue you're grappling with, is that the synth has limited
> resources.
> For each VVID you send, the plugin must allocate memory to hold the
> current state of all controllers on the VVID (Pitch, Velocity etc).
> If host keeps sending new VVIDs to the synth, the plugin will
> eventually be overwhelmed by the huge ammount of 'state' it has to maintain.
>
> 'deallocating' a VVID frees those resources thereby saving the synth
> consuming infinite memory.
No, I assumed that when a plugin is done with a real voice, it will just
ignore that VVID until it gets allocated again. This is another plus for
an explicit allocate. You can ignore any VVID that hasn't been allocated.
I guess you can do almost the same without explicit allocation. If you
get events for a VVID you don't currently care about and there is no
note-on message on the same timestamp, then you discard all the events for
that VVID.
> But how many VVIDs can the synth handle before choking?, how is the host
> supposed to know?, Why is it the host's mico-managing the synth's resources.
It's not, it's exactly the opposite. When the synmth can't handle any
more voices, it does what it needs to do. The host can keep talking to
defunct VVIDs, and the plugin will ignore them.
> Do different synths have different max-VVID limits?, if so they're not
> substituteable any more. How can you record a track on synth-A, then
> decide you're rather hear the playback on Synth-B.
nope, the synth can drop VVIDs internally. If you ask a synth for 10,000
VVIDs, it can just drop the LRU VVIDs and ignore messages for them.
> ...So, after the host has de-allocated a VVID it is free presumably to
> re-allocate it.
> So the host is keeping track of which VVID are in use and
> intelligently deallocating and reallocating them.
It has nothing to do with intelligence, it has to do with what you've
sequenced. You should be able to use a new VVID for every note the user
sequences. With 2^32 or 2^31 VVIDs per channel, you should never have to
wrap in a sequence. That doesn't exuse us from solving the wrap problem,
though.
> What is the net effect of de-allocating then re-allocating the same
> VVID a second later?
To tell the plugin that the VVID represents a new virtual voice. And I've
already conceded that you don't need to deallocate. And as of this
message, I agree that with some caveats (reasonable, I think) you don't
even need an explicit allocate, just an explicit note-on/note-off and a
large VVID space.
> Rather than this over-complicated allocate/deallocate scheme. Implement
> a "voice-reset" command. It's the same result.
That's what a re-allocate is. It says "I don't care about the old voice
anymore, do whatever you want. I want to re-use that VVID number for a
new voice".
So my assertion is that we don't need deallocate, and we don't need the
plugin to tell the host when it is done with a voice. We don't need an
explicit allocate, but without it we need extra rules about note-on and
note-on-controls.
I don't think you can getr much simpler and still meet the requirements.
In truth, this more minimal model may be missing some of the requirements,
I haven't worked it all out fully, but I *think* it's all covered.
Tim
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
