[gmpi] Re: Requirements evaluation
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 8 Nov 2003 00:04:31 -0800
On Fri, Nov 07, 2003 at 11:28:09PM -0700, eric wrote:
> I believe it's possible to separate the basic plugin spec into different
> layers, including one that handles things like port datatypes, memory
> buffers, whatever. So we start with the generic spec, and create an
> audio datatype for GMPI V1, and then when video is added in 2, 3, or 4,
This starts to add a serious amount of complexity. It's really nice to
abstract things, but one of the primary goals of GMPI is to be simple.
> Let me clarify: It would be cool to keep multiple hosts in perfect sync
> over a network, and allow plugins on one system to communicate with
> plugins on another. I do NOT think that the networking details should
Oh. Yes. But that is totally outsode the scope of GMPI :)
> version of the project. I don't think this should be specifically
> designed and implemented in the GMPI spec, BUT, I don't think we should
> make GMPI choices that would interefere with this goal (a real goal for
> OMS).
Agreed - please alert us if we make decisions that would preclude this.
> library - the file in which machines are stored.. this supplies the core
> plugin interface/services for all included machines
> machine - this is what the user sees in the ap as a synth or effect
> plugin..
> parameter group - a logical grouping of parameters, ie, A, D, S, R
> on a synth.
> parameter - defined well in the summary
> service - a function that is callable by the host or other
> plugins... a plugin may exist explicitly to provide services such as
> loading/saving non-native file formats
> capabilities - a list of sub-spec implementations (instrument,
> effect processor, etc...)
The ideas are close enough to what I had in mind. Too early for this,
though. Requirements.
> Another layer of the spec might be a specification of spacific parameter
> types in groups, such as music communication spec (similar to MIDI, or
> even MIDI itself). Each of these event-based layers might be listed in
> the capabilities section of the plugin description.
> Another layer might be clock/sync signals.
OK. I've been referring to these things as weel-known parameters.
Essentially (my draft reqs should make this clear) anything that is not
mandatory is a Control (a better name for parameter).
There are well-known parameters that define compatibility with MIDI
There are well-known parameters that define a plugin is an instrument
There are well-known parameters to handle timeline sync
Each of these is an interface (to use Java terms). Perhaps it is worthwhile
for a plugin to announce that it implements specific interfaces. Perhaps
not. Withing (for example) the MIDI controls, the plugin may implement some
or all of the MIDI controls. Does it implement MIDI-compat if it only
handles aftertouch?
> Another layer might be the standard services supplied by the host, and
> standard services that may be supplied by plugins... such services might
> be file I/O, memory allocation, shared memory/resource access, etc..
These things can't be optional. They have to be core.
> IMO, these abstractions do not complicate the design.. they simplify it,
> and allow it to conform more with best oo design practices.
Actual design and encapsulation will come later. First we do reqs. THEN
the spec.
> >Re: NSPR
> >
> Good stuff. However, we may still have to deal with technical issues
> such as timer granularity. I haven't tested it yet. At any rate, it
> could provide us a very good starting point, and the licensing is very
> flexible.
Immediately, I LOATHE the NSPR API from a conventions point of view. It's
also a bit extreme. I don't know that we need that much. Probably has some
good ideas in there/
> I don't know.. this is just a requirement collection doc, not
> implementation details.. =) I figured if a plugin is using too much
> time, the host sends it a signal (via the standard event system, perhaps
> through a dedicated host/plugin communication parameter), and the plugin
It all depends whether it is optional or not ;) It seems like a great
candidate for a well-known control, but it doesn't need to be timestamped.
If this notification mechanism is non-optional, then it should not be a
parameter.
> >Re: Parameters
> >
> >I agree more or less about using generic parameters for many things. I
> >don't know that making it totally extensible is worth the effort.
> >
> What effort? Do you agree that parameter types should be extensible?
Not if it adds much complexity. I'd need to see some ideas about how to do
it with minimal work before I agree it's required. Desired, sure.
But required?
> >However, I don't think I want to see a plugin saying "I am an instrument".
> >The fact that a plugin implements the instrument API should be sufficient.
> >
> I would agree, but how does a plugin announce it's capabilities? =) I
> suggest the capabilities declarition in the plugin description spec
> (another thin layer). =)
Maybe. I'm not convinced it is needed. A plugin announces it's
capabilities by exposing it's controls. When the host enumerates the
controls, it notices, HEY! That's a MIDI-compat control.
> >That said, if an API is sufficiently complex, maybe it is easier to provide
> >a list of interfaces the plugin implements? Anyone have comments?
> >
> Exactly what I propose.
I'm not convinced. This may be a red-herring for now. Does something like
this need to be in the reqs?
> >Can you provide concrete examples of what you need to save besides
> >parameters?
> >
> Wave-tables, for instance, but plugin developers may want to save stuff
> that we can't predict, and we should allow them to. Perhaps this should
> not be implemented via the stata mechanism that was proposed, but I know
> that at a minimum, I'd like to be able to store my currently loaded
> wave-table set for a sampler, and my current sequence for things like
> little beat-sequencers. These things are state-related, and not tied to
> parameter settings, from where I'm sitting.
That's exactly what 'stata' are for. The 'stata' idea will go away, though.
Stata are just parameters that are flagged as state-bearing. Expose an
opaque parameter that is marked as stateful. When asked for the value of
it, encode your wave-table to the blob variable.
Tim
----------------------------------------------------------------------
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:
