[gmpi] Re: 3.9 (draft) use cases and stuff
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 24 Feb 2004 17:08:56 -0800
On Wed, Feb 25, 2004 at 01:21:37AM +0100, Koen Tanghe wrote:
> Just my thoughts:
Thanks for the reply - we need more!!
> > 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?
>
> Intuitively: yes. If a plugin can track tempo and meter changes, it should
> be possible to hand these changes over to the host or to other plugins that
> need this info.
Intuitively, it should all be dynamic. Given the consequences of changing
the meter is it REQUIRED? This is not a loaded question, I'm asking because
I really don't know :)
> > And is it a requirement that a tempo change be enacted or is it optional
>
> Preferably yes, but I realize some host makers will not want to deal with
> this as most of the plugins don't need this. So, maybe: hosts must support
> it, but they are free to do something useful with it. (I don't like these
> "undecided" things, but since you allowed an "it's optional" choice...)
Obviously, nothing should blow up under any case, but is it REQUIRED for
hosts to allow plugins to change tempo? If we don't require it now, then it
will likely end up like VST - only one host supports it. If we do require
it, guys like Ron who have hosts that don't support it will need to jump
through hoops (thereby decreasing the chance of GMPI succeeding).
So what do you people think?
> > How about meter - optional or not?
>
> Same as for tempo.
It is and it isn't. I think the repercussions of changing meter are more
significant that those of changing the tempo.
> > How about transport and locate? Can a plugin change the transport/locate
> of it's time controller?
>
> transport/location:
>
> Well, the only use case I can see is an automatic score-following setup
> (however exotic this might seem for some of you, this functionality already
> exists in some very few dedicated standalone applications, at least for
These are more things that we can choose to require of hosts, support but
not require, or not support. I think that building support for them is not
technically hard if we have an established event protocol. What is hard is
deciding whether they are useful or just wasted complexity.
> - all parts of a piece of music are layed out on tracks in a sequencer
> - a musician mutes one instrument track
> - the musician starts playing the muted instrument live
> - a plugin "listens" to the incoming audio or MIDI signal performed by the
> musician
> - as soon as the plugin recognizes what the musician is playing, it sets the
> transport location to the corresponding position in the sequencer and sets
> its transport state to "play"
> - if the musician decides to skip or repeat a part of the music piece, the
> plugin recognizes this and adjusts the playback position accordingly
> - when the musician plays a specific end sequence of notes, the plugin
> recognizes this and changes the transport state to "stopped"
As Mike said - this sounds like an experimental host, to me. All of these
"advanced" features we're talking about (changing tempo, meter, transport,
and sequencer plugins, etc.) are really ancillary to the MAIN goal of GMPI.
The vast vast vast majority of users today survivie without them. If we can
add them cleanly and simply and without too many corner cases, I'm for it.
If we can't, then I say screw 'em.
I'd rather see a complete, simple, elegant plugin API that only handles
instruments and effects than a monstrosity that is totally modular but has
all sorts of gotchas for hosts and plugins.
Now if we can do a complete, simple, elegant plugin API that is totally
modular, then let's get to work :)
> Now, before I have all of you kicking me to death ;-), let me say the
> following:
> This is the kind of things I expect to see more and more of in the future.
> It would be nice if music technology was prepared to allow such systems to
> integrate with existing music production/performance systems using a plugin
> format.
> *But* as I realize this is (probably?) a rather exotic use case today for
> many people, I will not insist on making this possible if it makes the GMPI
> design too complex or if it slows it down significantly.
> I just think it's good to at least talk about these things now, so that we
> all know what will be possible and what not...
>
> Koen Tanghe - Smartelectronix
> http://www.smartelectronix.com/~koen
>
>
> ----------------------------------------------------------------------
> 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
--
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:
