On Fri, 2 May 2003, Chris Grigg wrote:
That has real simplicity advantages over the host passing a MUSTIME
context ID, esp. if every pin has its own event queue.
That's exactly how I saw it working. Event-processing plugins that don't
mess around with tempo or time will just pass events on to downstream
plugs.
The only complication is in developing merger filters, they will have to
allow (the user?) to select which inbound port's time context to honor.
You'd probably want to know which MUSTIME
context a given note, for example, belongs to. I suppose musical
events in the same MUSTIME context could even go to the same
pin/queue as the MUSTIME tempo, meter, bar/beat/etc. events...
Yes... by and large I see MUSTIMEs running on the same type of event port
(of which a plug will normally only have one, but may have more) as note
(and maybe parameter... see below) data.
One other thing I'd like to bring up, although I'm not 100% sure it's on
topic there has been much discussion of parameter ramps and automation...
Consider the following simple scenario:-
Host -> Midi..Midi processing plug -> Midi..Audio processing plug
We're agreed, I think, that note events and musical time events flow
downstream in the graph. But what about parameter automation events?
They could be said to belong in a time context, and in general be "like"
note and other musical events. However, if they are to flow downstream in
the same way, each plug must have a unique target-ID, such that it can
identify parameter messages intended for it. In the above case, the MIDI
processing plug needs to be able to ignore parameter events for the audio
plug sitting downstream.
The other option is to provide a seperate class of port (event queue) for
parameter events.
What does everyone think?
Regards,
Angus.
