[gmpi] Re: Topic 6: Time representation
- From: "Michael Gogins" <gogins@xxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Thu, 1 May 2003 23:11:02 -0400
I suggest that the host has a small object containing current time, current
sample frame, seconds per sample frame, channel count, musical time, musical
tempo, rate of change of tempo, and so on that it updates once on each block
of sample frames. The host would set a reference to this object into each
plugin, and the plugins can call its inline "get" functions at any time to
read the values of the members of that object. This is as efficient as it
can get and places no restrictions on what or when the plugin can read. This
object could be called the "Conductor" or "Timebase" or something.
===========================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
Silence, a language for programming music and sound
Available at http://www.csounds.com
===========================================
----- Original Message -----
From: <RonKuper@xxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Thursday, May 01, 2003 3:37 PM
Subject: [gmpi] Re: Topic 6: Time representation
> >>>
> > E - Should musical time context changes (tempo & meter) be events?
> > If so, what kind of control over the generation & receipt of these
> > events should the plug have?
>
> The plug 'registers' to receive them. Plugins that don't care aren't
> bothered. Plugins that care get the information.
> <<<
>
> This puts a pretty heavy burden on the host, needing to manage which event
> types each plugin instance has registered for. It's much easier to define
> the set of events that a host will send the plugin, and let the plugin
> ignore what it doesn't care about. The overhead of skipping these
> low-density kinds of events is going to be tiny compared to cycles spent
on
> audio DSP.
>
> >>>
> > G - Should musically interesting times be events? If so, what kind
> > of control over the generation & receipt of these events should the
> > plug have?
>
> I rather like the callback callback. The plugin asks the host to send
> events for some periodic musical event. These two seem to be logically
> XORed. I prefer G
> <<<
>
> Same objection. I don't want to manage registrations and callbacks from
my
> host. Musical events come when they come, the plugin can disregard
anything
> that's coming too densely for it to care about.
>
> ----------------------------------------------------------------------
> 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
>
----------------------------------------------------------------------
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:
