[gmpi] Re: Generalized Music Plugin Interface list is now onl ine
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 11 Feb 2003 20:53:01 +0100
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
Other related posts:
