[gmpi] Re: wrap up 3.8 - gesture start/end
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 14 Jan 2004 02:25:24 +0100
On Wednesday 14 January 2004 02.01, Chris Grigg wrote:
> Marc wrote:
> >--- Chris Grigg wrote:
> >> Tim wrote:
> >>>host->get_gesture_id();
> >>
> >> You probably just meant that as a shorthand, but just in case:
> >> How exactly does a control surface call a host function? So we
> >> might want to structure that as a message-based transaction
> >> instead. (Or were you thinking that there'd be some kind of
> >> driver interface on the host for control surfaces...?)
> >
> >A control surface can't do any direct interaction with GMPI,
> > setting parameters or anything like that. Somewhere, there will
> > be some software layer doing the communication to and from the
> > hardware, either a driver or a plugin or the host itself, but
> > somewhere there will be software for the control surface.
>
> (And Tim wrote something similar.)
>
> Well... that's one of the ways of doing it, but not necessarily the
> only way. Consider the case of MIDI Machine Control, where a
> control surface can control stuff inside a computer without
> requiring any control-surface-specific driver or
> configuration/set-up at all, because the communication is
> message-based (and the message formats are pre-standardized). If
> the GMPI host could be controlled by messages and not just function
> calls,
If GMPI turns out anything like XAP, function calls will only be for
very low level host/plugin interaction. All normal communication (ie
control events and stuff) will be done using events, which *are*
effectively messages. A plugin sending control events to another will
be performing one-way communication, so it doesn't matter (to the
plugins) if there is wire induced latency between them.
> then you have a possibility for smart control surfaces that
> just speak and listen GMPI directly (protocol could be IP or
> Ethernet, etc.; transport may be USB, Ethernet, 1394, IAC, even
> MIDI-DIN); if not, then drivers and config files is all it'll ever
> be able to do. There are also obvious networking & interconnecting
> opportunities here, just like with the remote GUI issues. Really,
> gesture control on a control surface is just a special case of
> remote UI, so why treat it differently from the remote machine GUI
> support we (I believe...?) already agreed we should have?
Well, I think we'll have a hard time avoiding two-way communication
when making connections, but other than that, I don't see any major
problems with sending "XAP style" events over wire.
One-way communication lines would be usable as well, but if you use
that between two hosts running normal GMPI plugins, the connection
behavior will be a bit funny, I think... I don't see why two-way
connections would be a problem in such a setup, though. It'd probably
be 1394 or Ethernet or something similar; not SysEx over a single
MIDI wire.
> Anyway, this is a side-topic, so everyone should feel free to just
> drop it.
Lots of stuff is closely related, which is why these discussions come
back to life every now and then. We should probably condense whatever
we conclude into some comments for the requirements doc.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
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:
