[gmpi] Re: 3.9 (draft) use cases and stuff

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 25 Feb 2004 16:06:54 -0800

On Wed, Feb 25, 2004 at 06:23:55PM +0100, Chris Grigg wrote:
> > > >...GMPI instruments (GMPIi?).
> > >
> >> Personally I was hoping to avoid having a different API type or plug
> >> designation for instruments vs. effects etc., though that may be
> >> over-optimistic.
> >
> >I don't think there is a different interface needed.  Whether you think of
> 
> I just meant I don't want to see GMPI instruments be a different API 
> from GMPI effects processors, etc., like other plug systems do.  Your 
> coinage "GMPIi" reminded me of VSTi in a bad way.

Oh, sorry.  It was just a joke, mostly ;)

> >For an "effects rack" kind of host or a host that just takes MIDI input and
> >renders it, there is no track length, and therefore there is no concept of
> >transport at all, right?
> 
> Transport is a property of stored media (comes from 'tape transport' 
> originally), so yes.  What point are you trying to make here?  I was 
> referring to the earlier, different discussion of a case where you 
> might have e.g. algorithmic note sequence generators, or loopers, 
> that have the concept of musical time, past and future, but will 
> never reach the end of playback because there isn't any end of media.

Those things have the concept of musical time, but not of position within a
project, right?  (note that "transport" in the above should be "locate").

I'm going to re-order your mail a bit to join this with another hunk:

> >Another niggle:  IF we allow multiple sequencer plugins, and IF you want to
> >have a global locate widget that controls them all, you need some protocol
> >to expose each sequencer plugin's sequence length.  Otherwise how does the
> >global locate widget know how to turn "I clicked at 50 of the widget" into
> >"12345678 samples" or "50 bars" position?
> 
> ?? -- This is exactly the same issue as the halfway problem, which I 
> thought you just agreed to drop...?

I don't get what it means to locate on something that does not have a known
endpoint.  Or more concisely how on earth do you draw a GUI widget for it?
Let me try to explain the problem I am seeing in my head.

When you play an MP3 in <your favorite mp3 player> you get a position
indicator.  If you want to jump to approximately halfway through the
project, you can drag the location indicator to about halfway through the
widget, right?

Now translate that to a GMPI host.  In order to have anything that indicates
"current position" relative to the project needs to know the total length.

Sometimes that doesn't make *any* sense.  If you do not have any sequencer
module in your graph, and you have something outside the GMPI graph (MIDI,
audio-in, whatever) being the driver, then you don't need the concept of a
locator control or a transport control, right?  So ignore that case.

Instead, take the more common case of a graph of plugins plus some sequencer
module(s).  To start/stop the sequencer(s) you provide a transport control
module.  This module controls some or all of the sequencers in the graph
(two transports controls are possible, but ignore that for now :).  The GUI
for that control might be as simple as one button - GO vs.  STOP.

If you want to provide a way to jump around the project, you provide a
locate control module.  This module controls some or all of the sequencers
in the graph (again, more than one is possible, but not important right
now).  The GUI for this control might be a scrollbar-like thing with a
click-and-drag enabled play-head indicator.  As you play, the indicator
moves forward.  The far left edge is the start of the project.  The far
right edge is the end of the project.

Am I clear so far?

Assuming you haven't balked already: how does that locator GUI widget know
where to draw the indicator?  It needs to know the length of <something>
which defines the end.  If there are multiple sequencer modules, there needs
to be some mechanism to get their length.  Or we need to say that this use
case is not supported.

By no means impossible, just worth noting.

> >If
> >Transport is a function of a sequencer plugin, we can (maybe) build a 
> >simple
> >cross-plugin transport protocol on top of the simpler GMPI event protocol.
> 
> Simpler than what I just described?

No, what you describe is basically what I was thinking, except I was
suggesting that maybe we would disallow a transport control outside of a
sequencer, thereby sidestepping the "how long is it" issue.

> >(side note: can a plugin GUI have multiple windows?  If we allow sequencer
> >plugins, it is almost required..)
> 
> Amplify on why?  Sequencer != Editor.

It just struck me that a sufficiently complicated sequencer plugin would
want multiple windows to be most useful.  An issue for a different topic :)

> >Imagine a dumb wav file player - no beat mapping or tempo sync.  Just plays
> >a wav file at a constant speed.  It might have time markers at certain
> >sample offsets.
> >
> >Imagine a simple piano-roll sequencer.  It obviously lines things up on
> >musical boundaries.
> >
> >If I ask them to jump to position "sample #12345", then the wav player can
> >just jump there, while the piano-roll needs to know the history of tempo
> >changes to get it right.
> 
> If the piano-roll sequencer has a fixed tempo source (map or 
> something else that behaves the same for every playback operation) 

You're not being pathological enough.  The pathological case is the
sequencer only knows the tempo RIGHT NOW.  But for the pathological case, I
don't know that there is a great answer.

> elsewhere.  Make friends with the occasional possibility of 
> indeterminate outcomes.  8-)

only when I *have to*. :)

> >pre-suppose it.  I really am starting to believe that meter and locate
> >are part of the sequencer (whether the sequencer is the host or is a GMPI
> >plugin).  I could deal with tempo being the same.
> 
> Careful about 'are part of' -- a sequencer will have to use a tempo 
> and meter at any given moment, but there's no reason why these 
> couldn't be controls that are driven by somebody else in the graph 
> (including host).

This is how I'd like my sequencer to behave.  I open a sequence window, and
it draws a graph that corresponds to the meter.  In order to get the graph
right, it needs to know about meter changes ahead of time.  Truly dynamic
meter changes make this impossible.  Maybe that is OK.

> >It is still a requirement that a plugin be able to change the tempo.  Is it
> >a requirement that a plugin be able to change the meter?  And is it a
> >requirement that a tempo change be enacted or is it optional (as in VST)?
> >How about meter - optional or not?  How about transport and locate?  Can a
> >plugin change the transport/locate of it's time controller?
> 
> Being able to have shared tempo and meter source driving multiple 
> destinations is so obviously useful an architectural idea that I fail 
> to see why the indeterminacy it introduces for some locate operations 
> in some graph configurations outweighs the benefits.

I should be more clear.

It is REQUIRED that GMPI support tempo changes.

It is REQUIRED that GMPI support meter changes.

It is REQUIRED that GMPI allow plugins to act as a tempo controller.

It is REQUIRED that GMPI allow plugins to act as a meter controller.

It is REQUIRED that GMPI allow plugins to act as a transport controller.

It is REQUIRED that GMPI allow plugins to act as a locate controller.


Is it REQUIRED that a plugin be able to change the tempo dynamically (as
opposed to exposing a static "map)?
  - I think we have established at least one use case for this.

Is it REQUIRED that a plugin be able to change the meter dynamically (as
opposed to exposing a static "map)?
  - I'm not sure the use case supports this.  Is anything really going to
    use this?  Does it outweigh benefits of having a semi-static map?

Is it REQUIRED that hosts support plugin originated
tempo/meter/transport/locate changes?
  - If it is not required, we'll end up with VSTs problem in the big hosts.
    If it is required big hosts will be unhappy.

> >1) Meter changes that are unforseen cause ugly problems.  Do we really need
> >to support plugins changing the meter in real time?
> 
> This really is a non-issue.  Forget about plugs changing meter.  The 
> problem you're describing is the inherent tension between a stored 
> sequence of events with musical timestamps, whose timestamps are all 
> internally consistent with the sequence's own meter change map, vs. 
> responding to live meter change events that have no guaranteed 
> relationship to the stored sequence.  This is still a problem even if 
> the host is sending meter changes to a sequencer plugin, or if a 
> sequencer is sending meter changes to itself.  It don't work.

Right.  So what I am searching for is a way to mitigate this.  If meter is
always communicated via a semi-static map, then plugins can be sure that
meter isn't going to change on them in realtime.  On the otherhand, maybe
the totally modular pathological setup needs to "just cope".

> SO... let's have meter change events, and let sequencers make their 
> own, hopefully intelligent, decisions about how they handle meter 
> changes during playback of stored sequences.  OK?

I *think* that is OK.  I just want to make sure I mentally explore all the
avenues.  Thanks for your patience :)

> >You didn't refute it - there are still a lot of problems with it.  Explain
> >to me what it means to locate in an environment where you don;t know the
> >end of the data?  You either have an end-of-sequence, in which case you can
> >jump to any point of the sequence, or you don't have a sequence.  Or am I
> >being dense?  By matters of practicality if you have a sequence, you have 
> >an
> >end-of-sequence.
> 
> 8-)  You're obviously not dense.  I think you're trapped in some bad 
> logic about the definition of 'sequence' and its relation to 
> 'sequencer'.  By this point you've seen a couple examples of endless 
> things that can be located.

If you have presented examples of things that don't have an end that can be
located, I have missed it.  Sorry.  Do you want to take back the bit about
me not being dense? :)

> >If you consider all music events to be aligned on ticks, where ticks re
> >defined per beat, then changing the number of beats per measure may
> >invalidate the sequenced data.  If you consider all music events to be
> >aligned to some % of a measure, then changing the number of beats per
> >measure may give you incorrect timing. If you change the base note of the
> >timesig, you may end up with unintended chords.
> >
> >So what is the answer?  It seems that it would make sense to change the
> >meter for other plugins.
> 
> Don't follow, can you amplify?  Who stays the same and who follows? 
> What if more than one seq plug-in is receiving independent meter 
> change streams, so there's no single master?  Doesn't it tangle?

It's important to note first that NOT VERY MANY plugins will care about
meter changes, I think.  Tempo changes are far more common and more
important.

It has been required that we support multiple tempo-controllers in a graph.
Maybe it is simpler to say that "every graph has exactly one active tempo
controller and exactly one active meter controller.  Hosts may create
multiple sub-graphs which can be bridged."  But that is not really any
different from having multiple tempo/meter controllers in a graph, right? 

> >So maybe the answer is for sequencer plugins to NOT receive meter change
> >events in realtime, but to make the meter be realtime controllable.

I think what I was getting at is that meter should be realtime controllable,
like anything else, but that multiple sequencer plugins will have to decide
themselves how to handle meter changes.  I was also thinking that maybe it
would be useful to make meter be "special" in one specific way.

Since realtime changes are not fun for sequecer plugins, what if the meter
controller exposed a semi-static meter map?

The vast majority of use cases will involve a meter map that does not change
in real time.  You program in your meter changes and you don't change the
map again.  There are then TWO ways for a plugin to learn about
meter changes.

The simplest way is to receive Just-In-Time events saying "the meter is
changing to X/Y at sample time Z".

For plugins that want MORE to do with meter, they can subscribe to the
exposed meter map. By "subscribe, I mean they see the whole thing, and get a
notice when it changes.  The assumption is that changes to any point in the
meter map are *SIGNIFICANT* events for these plugins, and that they want to
see the bigger picture.

This allows simple plugins to just receive events and track meter, and it
allows sequencer plugins to draw meter-based alignment graphs and things
like that.

What think?  For meter controllers that are truly dynamic (like the input
follower) the meter map might just be empty or set to some default.  Tempo
could be the same, I guess.

Am I getting clearer?
-- 
Tim Hockin
thockin@xxxxxxxxxx
Soon anyone who's not on the World Wide Web will qualify for a government 
subsidy for the home-pageless.

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