Chris, I just want to say that I really enjoy getting enormously long emails in response to my long emails...
> >...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?
...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 :)
> >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?
> b) if thereare multiple chunks in the session, the end of the session is the end of the last chunk,
Not sure what you mean by chunk?
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?
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.
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.
(side note: can a plugin GUI have multiple windows? If we allow sequencer plugins, it is almost required..)
> >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 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.
> >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?
> sense of transport control. Then you can broadcast transport controlto 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.
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?
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?
1) Meter changes that are unforseen cause ugly problems. Do we really need to support plugins changing the meter in real time?
2) Transport changes are hard (but not impossible) to sync across sequencer plugins. Do we really need to?
> >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.
> >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.
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.
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.
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.
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.
---------------------------------------------------------------------- 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