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

Chris, I just want to say that I really enjoy getting enormously long emails
in response to my long emails...

I think you were basically apologizing here, and if so, no need. This is all good.


 > >...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
this stuff as MIDI events bound for a specific port:channel (with all the
events in series) or you think of it as a bunch of virtual wires (with all
the events in parallel) the protocol is the same as any plugin->plugin
control.  Was that what you meant?

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.



...So everything works just like a traditional
 > >all-in-one host, right?


 Except that in traditional hosts there's frequently only one possible
 musical timeline.


As I said above "Assume a host with no sequencer or mixer or anything built
in.." :)  This is not a traditional host we're talking about - it's a
pathologically dumb host :)  If you set things up as I assume above, and
play from the start with no transport jups, it will "work" like a
traditional host.  The fact that there COULD BE things that are different is
not applicable right now :)

I think you misread me, I was commenting on your assumptions about what a traditional host is, not what your dumb host is.


> >Suppose I want to jump halfway into the track. What is halfway? Halfway 
 >through each sequencer track?  What if two streamers are different lengths?
 >What if the streamers and piano-rolls are the same length at  one tempo,
 >but
 >not at another?  Further, how does the host know how long each sequencer
 >plugin's data is?

 I thought we covered this case before and thought it wasn't very
 useful: a) In many cases, track length has no meaning;


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.


> b) if there 
 are multiple chunks in the session, the end of the session is the end
 of the last chunk,

Not sure what you mean by chunk?

Look at a MIDI + audio sequencer with audio files and/or regions thereof placed in tracks, staggered so they don't start at the same time. Each region of file is a chunk, and session length runs from start of earliest chunk to the latest chunk end.


I want to look at the 4th piano-roll plugin and
jump to the spot right before some note starts playing.  With a multitude of
sequencer plugins and a transport that is independent thereof, how?

Ask the plug you care about what sample time corresponds to the musical time you want. Then locate the whole graph to that sample time. Each sequencer plug-in will chase to its own correct position.


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?


This is just a quick think-up:

Each sequencer plugin has a TRANSPORT output which emits transport-change
events.

The host receives transport-change events and sends them to the other
sequencer plugins.

I can then jump to any point within any sequencer plugin, and all the other
transports will sync.

The alternatives seem to be:  a) don't provide cross-sequencer transport sync;
or b) don't support sequencer plugins.

I don't get where your "can't" comes from.

Also, I would turn the control system around and generalize it: Sequencer plug-ins that support external control (who knows, maybe there are use cases for ones that aren't externally controllable) have a transport control input, and a locate input, and a locate output. Transport control inputs can be driven by anything: host, plug-in, control surface, etc. Users can configure transport control routing ad lib.

This way you can gang up multiple sequencers with different characteristics and drive them all from a common control panel. You can also make any sequencer chase any other sequencer if you want, and you can get any sequencer's location when you want it.


(side note: can a plugin GUI have multiple windows?  If we allow sequencer
plugins, it is almost required..)

Amplify on why? Sequencer != Editor.


> >Audio file streamers fundamentally operate on sample offsets (unless they 
 >do
 >beat mapping/time stretching, but let's call that the same as a piano-roll,
 >for now).  They want to be jumped in samples.
 >
 >Piano-rolls fundamentally operate on musical units.  Given a sample offset
 >from start, they CAN convert to musical units with some knowledge of tempo
 >and meter, but they require that extra knowledge.  They really want to be
 >jumped in musical units.

 Not sure what you're saying.  In a mixed musical time + samples
 environment, musical time is always (in my experience, at least)
 pulled by the sample time.  GMPI isn't going to change that.

Let me try to clarify (maybe I am seeing an issue where there is none)

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) then this is no problem. If the piano-roll sequencer's tempo is being driven by wiggly random live events, then there's no way of knowing what would be 'correct'. Same problem you're wrestling with elsewhere. Make friends with the occasional possibility of indeterminate outcomes. 8-)


If I ask them to jump to position "bar 12, beat 3", then the piano-roll can
just jump there, while the wav player needs to know the history of tempo
changes to get it right.

Right. Musical time expressions are only concretely meaningful in reference to a particular tempo+meter map context. This is why you have to go to whoever knows what "bar 12, beat 3" means to convert that time to a common reference time, like samples, and use that instead of musical time to locate all the sequencers.


> >Figuring out transport position for multiple independant sequencer plugins
>is not fun.

 Why would you need to?  Other than for the jump-halfway problem, why
 can't each sequencer plug-in figure out its own position?  Just send
 them all the same locate command, for a sample time you like.  Each
 sequencer will chase to that spot.


Right - they all need to seek to the same position.  Whichever unit we
choose means one type of plugin has to know tempo history, right?

Sure, but every musical-time sequencer either can find out from its tempo map, in which case there's no problem, or has a fixed tempo, in which case there's also no problem, or else is completely off the map because it's listening some wild real-time-variable tempo source, in which case there's no way of knowing with certainty (only guessing).


> sense of transport control. Then you can broadcast transport control 
 to the sample clock and all musical timeline masters and allow each
 musical timeline to handle its own location respecting its own tempo
 & meter changes.


This pre-supposes that tempo and meter are functions of each sequencer
plugin.  Not that I am necessarily against that, I just don't want 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).


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.


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


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.

However there are other useful things you can do in a graph with meter change events. For example, a sequencer that's recording (not playing) needs to get live meter change events if it's going to record the musical event times correctly. Maybe you set up one metronome sequencer with the meter map, and record that into a second sequencer along with a performer's live playing, to make the recorded sequence follow the scored meter changes. And a time-sig display plug-in can receive live meter change events and make them visible to performers. So IMHO we definitely need to allow meter change events in the graph, and we need to allow them to be connected to sequencer plug-in inputs.

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?


2) Transport changes are hard (but not impossible) to sync across sequencer
plugins.  Do we really need to?

Not that hard, see above.


> >What this leads me to believe is that sequencer plugins should not be 
 >micro-plugins like I started with, but monolithic plugins.  They sequence
 >audio and music and whatever they want.  They control the meter, and they
 >control the transport.

 This is mainly predicated on 'If you assume that transport is only
 applicable to something with a known
 length' which I refuted above.  Without that predicate, most of your
 constraints fall away and the conclusion isn't needed.  Also I'm not


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.


> >But what does the sequencer DO if it receives a meter-change from 4/4 to
>3/4? Drop the last note? shuffle it to the next bar?

 All else being equal, the actual time intervals (scaled by tempo of
 course) between events stored in the sequence probably need to be
 preserved.  (Time sig is in many important ways just a matter of
 perception, anyway.)  If you start with 4/4 time and a note on beat 1
 of bar 2, and then you change the piece's meter to 3/4, the note
 should happen on beat 2 of bar 2.

That's one answer.

It's the only answer that preserves the musical timing of the recorded sequence, yes? Treating it as fractions of bars is sort of academically interesting, but for the vast majority of composition and production situations musically inappropriate.


What I am saying is that changing the meter on an
existing sequence is undefined.  There is no right answer.  In fact,
probably ALL answers are wrong for some intents.

We agree, which is why mandating a 'correct answer' for all of GMPI seems like the wrong thing to do. Above I said it could/should be left up to each plug developer to decide what to do with meter changes received during playback of a stored sequence.


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?


An auto-drummer would want to know that the meter
changed from 4/4 to 7/8.  I can even believe that a plugin (such as the
plugin that analyzes realtime input for tempo) would send a meter change to
the auto-drummer.  But it just seems wrong to change the meter on sequenced
data.

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

Are we saying the same thing? Can't tell.


Maybe the answer is a semi-static tempo/meter map that is exposed by some
entity.  Changes to tempo/meter can be sent dynamically, too. Plugins can
access that map if they want a view of the meter that does not change in
realtime.  Plugins can opt to receive events if all they care about is the
current tempo/meter.  Plugins should not do both, but they could.

Don't get the 'opt to receive' meme. Looks to me like meter change events arrive (are received) all the time, and it's up to the receiver to ignore them when it's in modes where meter change is nonsensical, like while playing stored sequences. Do you just mean 'ignore'?

-- Chris G.

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