[gmpi] Re: Parameters / controls / GMPI event system - refreshment

On Tue, Nov 29, 2005 at 06:45:42PM +0100, Koen Tanghe wrote: 
 >This also means that most events stay fixed sizes.  An alternative
 >would be to make an expandable "note-on" event which started with a
 >'size' field and had some sort of dictionary (param = value) built
 >in.  This means a lot more work for everyone, I think.

 Maybe, but it's more structured. I like the idea of having a basic event to
 which atributes can be attached.


Yeah, there's something simple and less complicated about using this,
instead of multiple discrete events.  It's a data normalization problem.
The more normalized we get, the more intricate it gets, but the more
flexible it gets.


.  .  .  m  u  s  t     n  o  t    c  o  m  m  e  n  t  .  .  .

.  .  .  m  u  s  t     n  o  t    c  o  m  m  e  n  t  .  .  .

.  .  .  m  u  s  t     n  o  t    c  o  m  m  e  n  t  .  .  .

AAAARGGGGHHH!!!

OK. Aside from not getting why we're changing the control system design, something about this scheme is just not gelling for me.

(1) One of the examples had messages addressed to things called v0 & v1, but usually you want the plug to do voice allocation. So what's up with that?

(2) If you separate out all the parameters into separate messages, how does the plug know when the sender's finished sending parameters? If it's just waiting for the 'turn note on' message, then

(a) is it -really- reasonable to rely on senders to always do the 'turn note on' message last?

(b) Can you -really- rely on the pipes to always preserve message transmission order (think TCP/IP etc.)?


> But you're right that the multiple control ports idea might be easier to
handle. Not sure which one I prefer, but I'm fine with either. 

I could be talked into either or even something else.

 >>Does the plugin have 64*6 = 256 parameters?
 >
 >nope, just 6.
 >
 >>Or do other way around, but also using parameterized events: 6
 >>control in ports, one for each type of event?
 >
 >That's the ticket.  At least *I* find it elegant.


 OK...
 So what does the host get when it asks the plugin for its parameters?
 Just 6 parameters, as it seems.
 How will the host know that events sent to these control ports are
 parameterized with a voice ID?


However you ask the control port for it's metadata will include that info
- a flag or a special control port type or something.  Think of it as a
  flag - it keeps it simple.

What does a separate port per parameter achieve that parameter addresses within a single port does not?

How do parameter ports relate to voice addressing?

        -- Chris G.


> >Effectivly yes. 
 >Treating them as 6 'indexable' parameters makes them more manageable
 >is all

 Here I seem to understand:
 there are 256 parameters, but there are only 6 control in ports.


(6*64 != 256, by the way)

If it helps you to think of them as individual controls, that's ok, too.
That's really a matter for internal design.  As far as the API goes, there
are 6 control inputs.

 What I'm aiming at is that the host should be able to build a list of all
 possible parameter change events that may come out of or go into a certain
 plugin (as required by the spec part talking about plugins reporting their
 parameters).
 When using "parameterized" events, will it be able to do that? It implies
 that the parameterization of each event is also known to the host somehow,
 right?


In my view the host should be able to get metadata from the plugin that is
detailed enough for it to list something like:

Controls {
        Master {
                Volume: float32 [0.0, 2.0]
                Balance: float32 [-1.0, 1.0]
                Velocity(v): float32 [0.0, 1.0]
                Pan(v): float32 [-1.0, 1.0]
                Cutoff(v): float64 [0.0, 1.0]
        }
        Oscllators {
                Osc1 {
                        Shape: enum [Sine, Saw, Square]
                        Octave: int32 [-2, 2]
                        Phase: float32 [0.0, 1.0]
                }
                Osc2 {
                        Shape: enum [Sine, Saw, Square]
                        Octave: int32 [-2, 2]
                        Phase: float32 [0.0, 1.0]
                }
        }
        Filter {
                Cutoff: float64 [0.0, 1.0]
        }
}

You should be able to get all that and more from metadata.  Arbitrary
grouping and everything you need to know to auto-generate a reasonable UI
for a plugin.  The above ignores multi-channel or multi-module plugins.
It also neglects audio IO.  Those will make it even more detailed.

 >Not perfectly clear, but going thru the host has so many advantages..

 I was talking about the fact that some current plugins have the ability to
 morph their presets from one set of parameters to another set of
 parameters. One way to do this is by having something in the plugin's
 "process" function that updates the parameters so that they morph towards
 the new preset. The host will never see this (that's why I called it
 "short-circuit"), if these parameter changes are not reported through
 events.
 A solution we talked about was that there would be the possibility to have
 a "proxy" plugin that generates the parameter change events, sends them
 through the host to the plugin (in a buffer of timestamped events) right
 before the plugin's process itself is being called. This would also allow a
 user to record a series of random events for a plugin that has some
 parameter randomization built-in and thus always get exactly the same sound.
 We then had discussions about overhead for morphs that are smoothed on the
 sample resolution and ramps etc...

 But from the replies I think I can safely say: ALL parameter changes are
 done through events on a control wire.
 So this seems clear now.


Right, we definitely need to support spontaneous changes.  We talked about
a possible model, but as the details evolve, it may not be the ONLY model.
I don't want to get married to any proposals until it's time to start
actually doing them.

----------------------------------------------------------------------
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



----------------------------------------------------------------------
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: