[gmpi] Parameter Proposal was Re: Out-of-Band: suggestion for rethink


Am Montag, 29.09.03, um 15:27 Uhr (Europe/Berlin) schrieb RonKuper@xxxxxxxxxxxx:

*** Don't design the system, just state the
requirements. *** Present the document to the group, and then lets debate
the proposal section by section.

Okay, because I was at it and I had enough from just lurking, here's a quick snapshot on a very small subject, namely parameters. Maybe it's trivial, maybe it's a starting point for someone elses ideas. (I think that parameters are the essence of the plugin, hence I think they dictate a lot of the rest, that's why I would start with them)

Dunno if the form is appropriate.

(Note: The idea of parameter structures is a mix of common Parameters and AU-like Properties, dunno if that is good)

Cheers,

;) Urs


GMPI parameter requirements proposal

Parameter outline

        - Parameters consist of an information structure (meta data)
        and a value structure

        - There are plugin-specific parameters as well as predefined
        parameters (i.e. Bypass, Plugin name, SampleRate etc.)


For Parameters the plugin / framework offers mechanisms to

        - be list-published to host or anything that is aware
        of the plugin (i.e. an external control plugin, seperated GUI)

        - predifined parameters are available, anyway
        
        - be set/read from any external entity that is aware
        of the plugin (info=read and value=read/write, depending
        on metadata)
        
        - non published parameters can be used for internal
        communication (GUI<->plugin)
        "private parameters"


Parameter info

        - naming (UTF8), sizing, ranging, typing, short naming
         (i.e. for hardware control surfaces), default valueing
        
        - grouping of parameters (paging, hierarchical automation
        popup selection, grouping in generic guis)
        
        - association of parameters to objects / semantics inside
        the plugin (Plugin Modules, MultiTimbral Synth parts etc.),
        with its IDs starting at zero for each Module
        (multiple lists rather than a single list)
        
        - flags (readable, writeable, automatable...[extend list])
        
        
Parameter value

        - on simple types, this will be a float (at a min/max range,
        i.e. -100.f - + 100.f, semantics in the info)
        
        - on complex types this will be a pointer to a structure
        (opaque to host, only for internal use / GUI, if not the
        given meta data hints at predefined types)
        
        - a mechanism allows for the representation of values in
        readable / graphical form (a callback?), plus a customizable
        distribution curve, or is that meta info?
        Example: Array of strings for "indexed" values
        
        
Services surrounding parameters

        - Parameter changes are encapsulated within timestamped Events
        
        - Events can be fired to notify entities of parameter
        changes (requires a Listener scheme)
        
        - Events can be fired if the list of parameters changes
        (i.e. creation of a new parameter, or a parameter name /
        semantic changes), requires host to update its list
        
        - Parameter changes can be surrounded by Events which
         mark begin and end of a row of subsequent changes, to allow
         proper automation / ramping
        
        
Implementation stuff

        - As a service, the framework holds all parameter data
        in objects (the plugin does not need to track parameters,
        the framework already does it)
        
        - The framework offers means to store / retrieve parameter
        values in / from preset structures (XML?)
        
        - The host side framework (host SDK) offers appropriate
        Listener/Notification schemes, XML parsing and stuff
        (services in general)
        
        - The host side framework offers a bunch of common
        value->string conversion mechanisms
        (plugin can add its own)


Scenario:

        - the plugin defines a const array of parameter info fields
        and creates the list of parameter objects on instantiation
        
        - the host queries the list ( the plugin gives back only
        the ones it wants to publish )
        
        - the gui represents controls to manipulate parameters
        
        - upon mousing, the framework notifies every entity about
        changes, including surrounding begin/end tags
        
        - on preset save (invoked by the host), the framework asks
        the plugin to collect all information about parameters and
        returns the resulting structure to the host
        
        - upon preset load, the host sends the preset structure to
        the plugin which in turn generates parameter values which
        it sets (fires notification)
        
        - if host saves song or anything, it saves the same
        structure as in the preset (accordingly for load song)
        


----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: