fons@xxxxxxxxxxxxxxx: ... > OSC does two things: > > 1. It encodes packet type in textual strings, which > can be structured in the same way as pathnames in > file system are. > > 2. It defines a way to describe and encode the data that > follows, so you are not limited to a set of predefined > formats. > > Both are done in a way that make the conversion from/to > a textual representation very simple, which is some > cases is a desirable feature. As an unix guy, I'd skip the encoding and send the whole thing as space separaed text, since then you could simply do a telnet to the other host and run it by hand. Compare e.g. to smtp. The performance loss of printf() and scanf() at sending/receiving sides are minimal, and plain text is much easier to debug. But, this is of cause moot, since OSC is already there. ... > And anyway, until the fundamental hardware design issues > are solved, all this is in fact quite irrelevant. I see no problem of simulating this on one "master" pc and "two" slaves, and there is only the low cpu performance that is specific to the embedded controller. The protocols can be developed on ordinary pc's with their on-the-motherboard sound cards. And hopefully the netjack people solves it for us. Regards, /Karl ----------------------------------------------------------------------- Karl Hammar Aspö Data karl@xxxxxxxxxxx Lilla Aspö 148 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting -----------------------------------------------------------------------
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
