[gmpi] Re: OT: Event Properties (was Re: Topic 6: Time representation)

I suppose you could use GUIDs to define the properties, matched with
associated data structures. Plugins and hosts would support the ones
they knew about, so there'd be no need for enumeration and stuff like
that.

Todor

> -----Original Message-----
> From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx] On
> Behalf Of Chris Grigg
> Sent: Wednesday, April 30, 2003 2:05 PM
> To: gmpi@xxxxxxxxxxxxx
> Subject: [gmpi] OT: Event Properties (was Re: Topic 6: Time
> representation)
> 
> Hm.  Didn't mean anything quite so open-ended, but it's interesting.
> How would you do that in a way that wouldn't require all hosts to
> provide all possible event context properties?   A property selector
> enum and a host function for getEventContextProperty()?  Seems like
> you'd want sequencers to be able to provide their own custom
> properties, and you'd have to accommodate arbitrary data types for
> the accessed properties.
> 
>       -- Chris
> 
> >This is an intriguing idea, especially since you can use it to
extract
> >additional context information, like rhythm, key, and more.
> >
> >>  Chris Grigg said:
> >>
> >>  I'm still thinking about Todor's MIDI processing plug-in case.
What
> >>  if -- to take the complete opposite position from the previous
> >>  paragraph for a minute -- we were to say that all event times
> >>  arriving at the plug-in are expressed in linear time -- both
musical
> >>  and non-musical events, so the host has to convert musical time to
> >>  linear time before the plug ever sees the event -- but we also
> >>  provide a reference ID in the event structure, which the plug
could
> >>  query the host on to get the sequencer's original musical time for
> >>  that event?  So in timeslice X I get a MIDI event arriving at
sample
> >>  index 18345, with note 37 and velocity 118 and event ID 3773.  I
> >>  decide to do something musical with it, so I say mySourceEvent =
> >>  gmpiHost::getSourceEvent( 3773 ), which returns a struct with the
> >>  musical time that I can monkey with and then (somehow) post back
into
> >>  the event queue.
> >>
> >>  Something along these lines could clean up the event times
arriving
> >>  at the plug-in, whittling it down to just one time format which
would
> >>  be a kind of optimization for process(), but still leave a way to
> >>  access an event's musical time, for those plugs that need to.  As
> >  > opposed to the single time union idea.
> >  >
> >  >  -- 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: http://www.freelists.org/archives/gmpi
> Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to
unsubscribe
> 



----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: