[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:23:39 -0500
Thanks for your response.
Regarding doubles vs floats vs ints for controls, think like an experimental
composer. Of course you will need absolutely all the precision you can get
for some crazy reason. The protocol should NOT limit the imagination of the
composer for ANY avoidable reason!
Give me a limit, and I'll come up with a meaningful musical example that
breaks it.
Currently, the best control system that I've had extensive experience with
is the Csound score, where has 3 fixed fields (instrument #, time, duration)
and arbitrary user-defined fields. Fields are float or double (depending on
the build of Csound, and believe me you can hear the difference between
float and double in the synthesis algorithms). If the instrument number is a
fraction, a later event with the same value for instrument number is "tied"
to the first event, thus skipping re-initialization of the instrument
instance and enabling ties, legato, and such that musicians do every day but
most software just doesn't get. Your cookie idea is perhaps somewhere in the
same space.
----- 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:
