[gmpi] Re: 3.11 topic: Multi-timbrality and parameters
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 28 Apr 2004 21:15:33 +0200
On Wednesday 28 April 2004 19.14, Chris Grigg wrote:
> Thanks for clarifying your thinking on connection mechanics, David.
> But that seems orthogonal to how parameter IDs work, and would work
> just as well if there were slots.
Well, yes - except that event addressing in more MIDI-like systems
depend heavily on the hierarchy of port, channels, parameters and
what have you. My point was just that with "opaque IDs", the API
doesn't have to dictate the number of indexing dimensions, or how
plugins should communicate parameter addresses.
> I still think all this string-fu
> is messier than it needs to be, so actually I guess I think it
> could work better. So can you provide a pointer to the OSC
> parameter string format spec, for a closer look?
The only relevant similarity is really that there's a file system like
hierarchy of nodes that can be addressed using "paths". (I referred
to it as "VFS style" in some previous mail.)
> Note, it's also an issue at plug re-config time, not just
> connection time, as the whole params names array contents need to
> be re-built whenever internal structure of the plug changes.
Yeah, but if it's just a 1D array, hosts and plugins aren't required
to think of it as any form of tree structure. That said, I don't like
that part much either... (Tons of overhead. Eww.)
> So far I like the 1D indexed 'modular' approach Tim and I
> separately arrived at. My gut tells me 80% of plugs will be
> 1-slot, so only use index 0, and 80% of the rest will use n-channel
> designs so the 1D system with identical param lists will work OK
> for them, and the 80% of the rest will be expressible as n-slot
> designs with different param lists.
Sounds like realistic figures to me.
> Seems it's only a couple extra
> lines of host code to do it that way.
Yeah, as long as it's strictly 1D and all channels have the same set
of parameters, it's probably about the easiest way it can possibly be
done. No parsing at all (unless you feel like fiddling with the
parameter hierarchy for autogenerated GUIs or something), and you can
still (I think...) ignore the indexing part altogether if you don't
support it.
(Hmmm... Well, not completely: Hosts have to support it, or you'll
only be able to address the first channel of multichannel plugins.
OTOH, the plugins will still *work* - at least if using them with
only one channel makes sense, so...)
> At reconfig time most plugs
> (with static param lists per slot type) would have a lot less work
> to do, i.e. just say how many slots and which param list index each
> slot is using now. (Of course truly dynamic param lists don't get
> any easier.)
Right, but we can't really get around that anyway, I think.
We could make it more efficient by having some kind of "give me all
parameters starting with 'some_group/some_subgroup/'", but that's
some work on the plugin side. :-/
> Also I don't understand this part at all, can you restate please?:
> >"Such a feature would
> >be of use only to host authors who want to send MIDI to synth
> > plugins without doing their homework - and it would only work
> > with synths that actually care to implement it. Other synths
> > wouldn't work at all with such hosts, even if the user is willing
> > to connect CCs to parameters manually."
>
> What's 'homework'?
That would be actually porting the synth from "raw MIDI" to GMPI
events, rather than relying on some legacy MIDI support feature in
the host.
(That said, we could hack some SDK tools that do most of the work, if
you *really* can't be arsed to take GMPI events instead of MIDI
events.)
> Why 'not work at all'?
If a synth implements *only* the legacy MIDI API (why would you
implement "legacy MIDI" at all if you implement "GM hinted
parameters"...?), it would have no real GMPI parameters for
instrument control, so a host without legacy MIDI support wouldn't be
able to do anything useful with it.
Now, as I said, I might have misunderstod the paragraph(s) I was
commenting on, so this could be completely irrelevant anyway! :-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- 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:
