Re: [Linuxsampler-devel] Sampler engine / GUI communication

[Phil K. <phi...@el...>]

Thanks Steve, (note to self, press reply to all not reply ;)

My idea's were similar but are lower level, more akin to ARP broadcasts.

An app broadcasts the DMIDI meta-command for 'who's there' and all
devices reply.

The session could look something like:

Enquirer -> ff:ff:00:00
Device 1 -> ff:ff:00:01 [node id] description
Device 2 -> ff:ff:00:01 [node id] description

The exact format hasn't been 100% defined yet but it should be close to
that of above.  I've some very basic code for this but it hasn't been
integrated into anything fully working. 

Although SOAP and WSDL are good choices in themselves they are heavy and
having to include XML parsers does add bloat.  I'm not sure if going
down the CORBA road would be good but it does work.

John has started work on a coding guide to MWPP and we should be able to
use his examples.  Do we have access to any OSC code?

-P

On Wed, 2002-11-06 at 14:58, Steve Harris wrote:
> [putting this back on the list]
> 
> On Wed, Nov 06, 2002 at 02:26:40PM +0000, Phil Kerr wrote:
> > The biggest difference between DMIDI and MWPP is it's networking scope. 
> > MWPP has been optimised for Internet transmission whereas DMIDI is
> > optimised for LAN's and is much closer to raw MIDI. The device
> > identification schema also follows MIDI closer than MWPP which uses
> > SIP.  
> 
> OK, makes sense. I gues that means we should support both, and probably
> OSC, as that seems quite popular and has better resultion than MIDI.
> It is also UDP based IIRC.
> 
> All incoming event protocols should be normalised in some way IMHO.
> 
> > You mentioned a service discovery mechanism, do you mean some form of
> > application introspection that can be broadcast?  This is an interesting
> > area I've been doing some thinking about.  Any further thoughts in this
> > area?
> 
> Yes, thats it. I've done some work in this area.
> 
> There are two forms of serveice discovery, syntaic (API level) and
> semantic (er, harder to define ;) but we probably dont need it).
> 
> There are some existing standards, eg. WSDL (web sevice description
> language, http://www.w3.org/TR/wsdl), but they tend to be SOAP (XML-RPC)
> biased, and are probably overkill for what we need unless you want to
> describe specific services, eg. an envelope editor.
> 
> Basicly the deal is you have either a well know broker or broadcast your
> requirements ("I'm an Akai GUI, protocol v3.4, I want an engine"), and you
> get back a list of candidates. XML is your friend here.
> 
> The scheme I would suggest goes something like:
> 
> Broker fires up
> Engines reister with Broker (easy if the top level engine is also the Broker)
> UI starts, queries Broker
> Broker queries each engine in turn to find out if it can handle the UI
> Broker retrurns list to UI
> 
> This also scales to multiple Engines on multiple machines, it just means
> that the Engine has to register with an external Broker.
> 
> If the Engines are external, but they hold open a socket to the Broker
> then they can tell if it sudenly goes away (or vice versa), which helps.
> 
> - Steve
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel