[gmpi] Re: Generalized Music Plugin Interface list is now onl ine
- From: "Michael Gogins" <gogins@xxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 11 Feb 2003 19:17:43 -0500
----- Original Message -----
From: "David Olofson" <david@xxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Tuesday, February 11, 2003 2:53 PM
Subject: [gmpi] Re: Generalized Music Plugin Interface list is now onl ine
>
> On Tuesday 11 February 2003 17.16, gogins@xxxxxxxxxxxx wrote:
> > I propose that the semantics of MIDI be retained, with some
> > extensions, an=3D d
> > at a much higher precision=3D2E All fields should be doubles,
>
> doubles? I'm not saying floats will do for everyone, and XAP will have=20
> it anyway (along with floats, which will be the preferred format for=20
> normal controls), but I think dropping float controls need some=20
> motivation. So does having float controls at all, of course. You just=20
> had me consider ditching float controls in XAP, actually...
>
>
> > controller numbers should be extensible, channel numbers should be
> > extensible,
>
> Well, in XAP, we could use 32 bits, strings or whatever, but the=20
> actual events get stamped with cookies that each plugin generates=20
> when you ask for a control input for connection. These are 32 bit,=20
> and can be encoded in any way the plugin sees fit. That is, you can=20
> have 2 bits for event type (ie CONTROL and... what, really?), 20 bits=20
> for Channel and 10 bits for control, or whatever. The plugin that's=20
> asked for it and will decode the events decides.
>
> Oh, actually, this isn't a definitive restriction. A full "target" is=20
> actually both an event queue and a cookie. This is mostly to allow=20
> plugins to have one event queue for each internal loop (to avoid=20
> sorting/dispatching events internally), but you could of course use=20
> it to extend the physical limits. And multitimbral/multichannel=20
> synths in general will most probably have (at least) one event queue=20
> per channel anyway, since that's by far the easiest way to get sample=20
> accurate control right. (Just wrap the inner loops in "fragment=20
> loops" that loop {check events; process some audio;} until the=20
> requested number of audio frames have been processed.)
>
>
> > timestamps should be absolute sample frames or absolute
> > seconds=3D2E Possibl=3D y,
>
> Sample frames, definitely. It's pointless to drag in other units, as=20
> every plugin is more or less tied to the audio timing anyway.
>
> Actually, pure event processing plugins - ie "MIDI plugins" - aren't,=20
> but the host would have to fake something anyway, to support better=20
> than engine cycle granularity timing. Say, 8000 frames per second -=20
> or 48000? Doesn't really matter. Pure event processors just compare=20
> timestamps most of the time anyway, and when they want to operate on=20
> them, it's usually *musical* time that is of interest. Then, just=20
> call the host to translate.
>
>
> > additional data fields can also be added (spatial location,
> > etc=3D2E)=3D2E
>
> This is hairy stuff... XAP and PTAF just use voice controls. There are=20
> no "arguments" that are passed with specific note on/off events. In=20
> fact, in XAP, NOTE will probably just be another control.
>
> We have considered calling it STATE instead, having two default states=20
> "off" and "on", and optionally other states, such as the phonemes of=20
> the english language or whatever a plugin might use. Plugins would=20
> enumerate their custom states if they have any, so sequencers and the=20
> like can display nice names instead of just NoteOn, NoteOff, State2,=20
> State3 etc.
>
> Anyway, the point is that the "arguments" become "latched controls".=20
> That is, while normal controls would do something whenever you change=20
> them, these are only looked at by the plugin when a specific state is=20
> entered. For example, the current value of the VELOCITY control would=20
> only be considered when switching STATE to the ON state (or setting=20
> NOTE !=3D 0.0), and DAMPING (or whatever) would only be considered when=20
> switching to the OFF state (or setting NOTE to 0.0).
>
>
> > The plugin API can have a translation layer that takes conventional
> > byte-size MIDI and forwards it to the higher-precision interface,
> > which is what the implemention is required to process=3D2E
>
> Yes, definitely. I think the translation could be done with ordinary=20
> plugins that take MIDI messages as "raw data controls", but that=20
> doesn't really change anything; it's just a clean way of making MIDI=20
> parsers and generators portable and reusable. And available as real=20
> units to those who want to tweak the MIDI<->control mapping! Just use=20
> your favorite MIDI->GMPI translator in any host, and you can get your=20
> MIDI controller to work *exactly* the way you want, with any host and=20
> any with synth that has the controls you want.
>
>
> //David Olofson - Programmer, Composer, Open Source Advocate
>
> =2E- The Return of Audiality! --------------------------------.
> | Free/Open Source Audio Engine for use in Games or Studio. |
> | RT and off-line synth. Scripting. Sample accurate timing. |
> `---------------------------> http://olofson.net/audiality -'
> --- http://olofson.net --- http://www.reologica.se ---
>
>
> ----------------------------------------------------------------------
> 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:
