[gmpi] Bookmark: Event Queues & Routing (not Topic 6: Time rep.)
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 2 May 2003 14:59:39 -0700
On Fri, 2 May 2003, Chris Grigg wrote:
Angus Hewlett wrote:
>
>So, my question is, if the host wants to send automation data to a plug
>which is not immediately downstream of the host with regards to the event
>stream, do we:-
>
>(a) provide a secondary port on all plugs for automation events (to which
>the host can now connect directly)?
>
>(b) provide a means of tagging automation events with a "destination plug"
>field, which causes intervening MIDI:MIDI plugins to pass-through
>automation events not intended for them (unless of course said MIDI:MIDI
>plug transforms automation data as well as note data, in which case it
>will transform the automation event and then pass it on).
>
>If (b), we should also at least consider the aspect of transformability
>when designing our automation event architecture.
Just like the MIDI arpeggiator example, I'm having trouble seeing why
any pass-through should occur. IOW, why handle parameter events
differently from musical events? So the seq automation channel (in
the host) just targets the specific pin of the specific plug that has
the specific parameter it's automating.
OK, so you're suggesting architecture (a), where a plugin has several
different pins for different classes of events.
No I'm not. I'll try to be clearer. Different pins, yes, but not
separate pins per event classe. If for automation/modulation we do
something like controls, then each pin tells the host about the zero
or more controls available on each pin, and any other receivable
event types, at setup time.
My problem with that is
that, by and large, an event is an event and any division runs the risk of
being arbitrary if we are not careful.
Not a problem if there's no distinction of event classes by pin. And
if we can find a way to go towards the 'everything's a control'
model, there might be only a couple basic event types. A barline or
a SetControl is a point in time, a note is a span of time whose
duration may be initially unknown, a recorded automation move or
other ramp-control is a span of time whose duration is known. Maybe
those three event classes are enough?
> I mean, why 'broadcast'
parameters (by passing on to downstream plugs/chaining) that are only
meaningful to particular plugs? Inverting the question, what
parameters would be interesting enough to all plugs to warrant
broadcasting them?
I'm not talking about broadcasting, I'm talking about a specific issue
regarding downstream event flow. The question is whether automation is
typically delivered down the same event-transform stream as other event
data might be (which to my mind has some advantages, but requires careful
design) or whether we provide seperate ports on each plug for note-events,
parameter-automation events, etc., etc.
It's not either-or. And I still don't understand. Can you back up
and explain your event stream model at a high level? In particular,
can you unpack 'the same event-transform stream as other event data',
as it's confusing me. You mean one systemwide queue, one queue per
plug, or one queue per pin? Or something else?
-- Chris
----------------------------------------------------------------------
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:
