|
David Zicarelli created a protocol that allow Max (3.5+) patches to share
data via standard TCP connections (it's based on the chat paradigm where an
arbitrary number of people can log on a server and share an arbitrary
number of "controllers", either to all (broadcast) or to a specific
individual). It's relatively light, and even on a 28k ppp/modem link you can
pump a reasonable amout of data through.
The protocol can encapsulate any type of data Max can handle, except MSP
streams. It has has very few limits (or "intelligence") built-in, but you
are responsible for making good use of what you're sending & receiving.
It's a standard socket connection, so it's easy to implement in most
development env's. The server is a bit more work than the client, but
there are at least two implementations i'm aware of (David's and mine...).
Right now work is done on timestamping and buffering the data, so that
people with different latencies (which is almost inevitable when routing
out of your LAN; the internet is not isochronous...) can still communicate
and keep some coherence over their data's enveloppes. There is also hope
for MSP streaming, but the bandwidth/latency problem is even more delicate
(although i beleive Miller Puckette's Pd has netsend and netreceive
objects that can handle audio and video streams as well as numbers and
lists; i don't know what sort (if any) of buffering scheme is used to
maintain a level of audio quality).
(The only problem i see with adding such features to csound is the fact
that csound remains a somewhat "static orc & score compile" affair. Since
very little is dynamic, it would be hard to make the login, pings&buffer
adjust sequence, and sharing of realtime data with others a practical
thing within a "session". If anyone has ideas how this could be added to
csound in an elegant way, i'd be very interested to hear about it. (I have
hacked Cecilia so you can log, send & receive data through that protocol
and then interface with csound with pipe events, but i have
not found any "usefull" use for it yet...)).
Alex Burton.
Michael Gogins :
> I think an Internet protocol for musical messages is an excellent idea.
>
> Simplify things, however, and just make it MIDI exactly except that all
> fields are floats or, better yet, doubles. Then it would be easy to feed
> MIDI into and out of this protocol, and it would still be easy to use for
> finer control.
>
> Another possibility would be to "tunnel" MIDI data through the new protocol,
> but I prefer the first idea, above.
>
> Higher value status codes (above 256) could be used for new semantics, a
> streamlined and simpler scheme for music messages.
>
> There could be user-defined message types as well.
>
> The protocol should address how to make and break connections, broadcast and
> multicast, and other similar issues likely to be relevant in studios and
> performance.
>
>
> -----Original Message-----
> From: Mike Berry
> To: csound@noether.ex.ac.uk
> Date: Wednesday, April 22, 1998 6:50 PM
> Subject: Re: Creamware
>
>
> >mike wrote:
> >>
> >> versions of the kyma system. Something that concerns me is the lack of
> >> anything other than midi to drive these new synths. realtime csound
> >> stylee without floating point pfields is like fine paint with a trowel
> >> on the end of a stick.
> >
> > I am planning to add Open Sound Control (OSC) support to GrainWave. It is
> a
> >packet-based IP protocol for sound control data. It easily support floats,
> >and just about any other data structure. I would be happy to provide
> csound
> >opcodes for OSC once I have the stuff worked out (within a couple of
> months, I
> >would guess). I could also provide the PPC-specific network socket code.
> If
> >someone else can write the specific code for the other platforms, then we
> >could step csound into a more useful real-time control realm. I know that
> >CNMAT (who developed OSC) has code for UNIX machines (if I can get at it, I
> >don't know).
> > Basically, the idea is that you could address csound directly via Internet
> >Protocol, which is supported by all machines, and for which most people
> have
> >hardware and software. Then you don't have the same specialized hardware
> >dependence that MIDI has. Of course, no one makes an OSC keyboard yet, so
> >this would (at least at first) be purely for software-csound communication.
> >--
> >Mike Berry
> >mikeb@nmol.com
> >http://www.nmol.com/users/mikeb
> >
> >
> >
>
>
Alex.
"the map is not the territory"
(korzybski)
|