[gmpi] Re: 3.11 topic: Dynamic plugin structure
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 29 Apr 2004 11:30:55 -0700
On Thu, Apr 29, 2004 at 10:27:21AM -0700, Chris Grigg wrote:
> >I disagree that the string format is error prone..
>
> I meant: Nothing prevents the programmer from making a typing error
> resulting in the 'same' parameter being spelled differently in
> different channels. If there are param name lists referenced by ptr,
> then all channels meant to be the same -will- have identical names.
This is not a fatal error, but I see your point.
> >> // Parameter Names for simple Gain plug
> >> numChannels = 1; // This plug has just one channel.
> >> channelParamNamesLists[] = { 0 } ;
> >> ParamNamesLists[] = { &masterParamNames };
> >> masterParamNames[] = { "gain" };
> >Where as with the OSC-naming I would just say:
>
> >parameters[] = { "/master/gain" };
> Are you saying the dead simple 4-line pattern I showed above, which
> allows all the flexibility we've been talking about for the universe
> of GMPI plugs, is too heavy a burden for simple plug writers? That's
I think the 4-line pattern is more complicated than it need be, probably.
> But!!! users will never see the slot address part ( '/master' ) of
> the param address. Whereas the other parts may or will be displayed
> in GUI.
Well, in MY gui, they'd see a container called 'Master' and another called
'Channels'.
> >simpler, and therefore better, IMHO.
>
> Maybe. I'm a sucker for indexed indirections.
:) Data normalization is a fun excercise, but there is rarely a need to
go beyond 3rd Normal Form.
> cramping the rocket scientists. Anyway, non-binary form makes sense
> in cases where civilians are going to be looking at the data directly
haha, civilians. That's funny :)
> >are going to allow arbitrary grouping of parameters, we'll need to codify
> >even more substructs. Or you'll have to parse delimited strings anyway.
> >:)
>
> Unavoidable under any flavor of parameter addressing -- plugs with
> dynamic parameter lists will always be responsible for managing those
> lists. All we can do is spec the framework they use to report their
> results back to the API.
My point was that you have to parse anyway. All arguments about cruft and
inefficiency are red herrings. But we're maybe over-simplifying. A
parameter is more than a name.
> Again, using strings for slot addressing is inefficient.
Efficiency is a red herring. This is the sort of thing the host does ONLY
at (re)config time and never again.
> >And it's easy to grok. :)
>
> Only if you're looking at the strings, which nobody will be.
It's easy to grok for newbies to the API, too.
(FROM OTHER EMAIL)
> Tim said, to David:
> >red herring. You store internally an array of params for each 'module'.
> >When you want to load a new module you insert copies of those strings. I
> >think the right answer may be a hybrid of the two.
>
> If you reference the lists via ptr, then you're right, there's no
> issue, but that's what I was saying too. My point was if you -don't-
Well, there IS an issue - you have to copy each string with the channel
number substituted into it. That made me think it was fugly ;) You're
right that a parameter's channel assignment does not have anything to do
with it's name.
> It would make sense to spec a standard structs for parameter
> description. The param descr struct would hold the channel/slot,
> param name (in /-format), the param's data type, any hints or other
right.
> possibly organized by slot/channel (though I'm not sure an explicit
> representation of channels is needed since it's implicit in the ),
umm, does not parse..."in the )" ?
> I'm not sure about channels. Do channels specify their own
> independent I/O ports/pins/queues, or is it the plug's job to connect
> the pins to the channels? We don't know yet. (There may be creative
Well, since the mixer use case came up again, each mixer 'channel' has
different IO needs and those IOs are very much tied to the channels.
We could, instead, invent a different way for dynamic IOs, but it seems to
me like it should at least be parallel.
A reasonable abstraction (to me)
host_probe_channels(GMPI_plugin *plugin)
{
GMPI_channel **channels;
int c;
channels = plug->get_channels();
for (c = 0; channels[c] != NULL; c++) {
GMPI_channel *chan = channels[c];
int i;
for (i = 0; chan->parameters[i] != NULL; i++) {
GMPI_parameter *param = chan->parameters[i];
// params with names like "/eq/low"
host_handle_one_param(param);
}
for (i = 0; chan->ios[i] != NULL; i++) {
GMPI_io *io = chan->ios[i];
// ios with names like "/stereo"
host_handle_one_io(io);
}
}
}
----------------------------------------------------------------------
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:
