On Tue, 20 Dec 2005, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I just had the same thought. It seems to me that Pd's OSC objects could be implemented so that they just do the protocol, then we'd have separate network objects that handle all of the networking. It would be a much more flexible system, and there would be less overlap in code to maintain (i.e., you would only have network code in the network obects, and OSC code in the OSC objects)
For a start, I just did a big cleanup of OSCroute.c and relatives. With that OSCroute is a single source file external and can be compiled without any dependencies to the rest of the OSC externals, especially it doesn't deal with any networking code anymore.
It was possible before to compile the OSC objects as single externals, the Pd-extended.app have included them like this for a long while. Maybe it didn't work on GNU/Linux. Was there a problem with the OSCroute file that I setup?
I also moved the stuff from OSC-pattern.[c|h] to OSCroute.c. This might not be a good idea, it was just done to simplify compiling even further to basically just
$ cc -c -o OSCroute.o OSCroute.c $ cc -shared -o OSCroute.pd_linux OSCroute.o
The code is not in CVS, however I'd love to hear some comments on this approach (and tests on Windows as well, as I removed some stuff there, too, like the __declspec(dllexport) in the original code, which better goes to a makefile, I think.)
I say leave this code as is, for the most part, except to get it building properly and to fix bugs. OSCx (this current OSC lib) is kind of a hack. It would be nice to see some clean OSC objects, perhaps with the networking handled by a separate object.
But ultimately, I don't have a strong preference, as long as it compiles, installs, and works when I cd packages && make install
.hc
zen
\
\
\[D[D[D[D