Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
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?
No, nothing was wrong, OSCroute always built fine in the past. What I would like to achieve is a clearer separation of OSCroute, which is just a simple, but very useful Pd message external, with nothing specific to OSC about it at all actually, and the UDP networking and scheduling code in OSCx. Even when somebody starts doing a new implementation of the networking code, OSCroute will be a pretty important external and it doesn't need to change much.
So basically all I did was remove the OSC-common.h header from OSCroute.c, as that is also used in the other OSC externals, to make OSCroute stand-alone and to make it possible to move it anywhere else in the future.
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.
OSCroute isn't a hack, it's a pretty normal Pd external, it just has collected a bit of dust, which I'm trying to shake off. For that I cleaned up the code a bit, removed a lot of commented Max code and some practically unused variables and some code paths, that were just taken if TRUE == FALSE. This wasn't a lot of work actually.
Frank Barknecht _ ______footils.org_ __goto10.org__