On 10/19/2012 03:03 AM, IOhannes m zmölnig wrote:

On 10/19/2012 06:08 AM, Hans-Christoph Steiner wrote:

...

Any objections? Shall I go with lazy consensus on this one?

.hc

On 10/16/2012 07:17 PM, Hans-Christoph Steiner wrote:

...

Hey all,

I was tired of dealing with a cryptic ./configure, so I converted OSCx to be based on the Library Template. THis is currently in the pd-extended/0.43 branch.

Anyone have any objections of me removing the old OSCx and replacing it with the 'oscx' library?

why would you want to keep OSCx alive? i would rather entirely remove this buggy and un-maintained (as in: upstream, not within PdX) library from any distribution.

Its still widely used and still the easiest way to use OSC, albeit in a limited way. If someone makes comparably easy way to use OSC, then I see no reason to keep this one.

and i don't get the point of replacing "OSCx" by "oscx".

Every other library folder in externals/ is all lower case.

.hc

On 10/19/2012 09:10 AM, IOhannes m zmölnig wrote:

On 10/19/2012 03:02 PM, Hans-Christoph Steiner wrote:

...

...

and i don't get the point of replacing "OSCx" by "oscx".

Every other library folder in externals/ is all lower case.

which is a good rule for all new libraries. imho, it's a bad idea to change a given name of an old library that is "still widely used".

Its only the source folder in SVN that will be renamed. Its always been included in Pd-extended as 'oscx', never as 'OSCx'.

.hc

On 10/19/2012 10:45 AM, IOhannes m zmölnig wrote:

On 10/19/2012 03:02 PM, Hans-Christoph Steiner wrote:

...

...

why would you want to keep OSCx alive? i would rather entirely remove this buggy and un-maintained (as in: upstream, not within PdX) library from any distribution.

Its still widely used and still the easiest way to use OSC, albeit in a limited way. If someone makes comparably easy way to use OSC, then I see no reason to keep this one.

here's 2 abstractions that implement OSCx's [sendOSC] and [dumpOSC] in terms of vanilla/mrpeach objects.

[OSCroute] cannot really be implemented in vanilla due to it's multi-outlet nature. otoh, [routeOSC] is compatible with [OSCroute] (apart from the name).

That's good to have, please post and maintain that somewhere, like maybe in the 'osc' lib. But its not yet a replacement because at the very least its not deployed.

.hc

On 10/19/2012 04:29 PM, IOhannes m zmölnig wrote:

On 10/19/2012 08:21 PM, Hans-Christoph Steiner wrote:

...

That's good to have, please post and maintain that somewhere, like maybe in the 'osc' lib. But its not yet a replacement because at the very least its not deployed.

i honestly dunno what you mean here.

imho, if you want to make changes to the OSCx library, you should rather replace the externals with the patches i sent than replacing the autoconf stuff with template/Makefile and renaming the folder (obviously, once that is done there is exactly no reason to keep autoconf stuff so template/Makefile (or even a stripped down version if you think it too bloaded) is enough. this would "deploy" those objects to all PdX-0.43 installations (if this is what you mean by "deploy"). i figure, that the replacement patches have less bugs than the external versions.

starting yet another library doesn't make sense to me (esp. since the 2 objects are almost 100% compatible (the only thing missing is multicast-group support, and i wonder whether anybody uses that).

adding those patches to mrpeach/osc (if this is what you refer to as "the 'osc' lib) is imo not a splendid idea either, as mrpeach/osc is blissfully unaware of the transport layer. (if martin thinks differently, he should go and add those patches)

I'm not going to take on the maintenance of those patches, so just copying them into Pd-extended is not an option. I'm think Pd-extended should have an 'oscx' compatible library , and 'oscx' is already there, tested, etc.

If you want to write a replacement, then please do. But for it to be truly a replacement, it needs to be released properly, widely tested, etc.

.hc

On 10/20/2012 04:07 AM, IOhannes m zmölnig wrote:

On 10/20/2012 01:26 AM, Hans-Christoph Steiner wrote:

...

I'm not going to take on the maintenance of those patches, so just copying them into Pd-extended is not an option. I'm think Pd-extended should have an 'oscx' compatible library , and 'oscx' is already there, tested, etc.

"etc" means "known to be buggy & unmaintained".

i'm not arguing against OSCx because of it's architectural flaws but because it's not working as it should.

I'd happily ditch it if there was a drop in replacement. For example, I've had many students come to me with the most popular Processing <--> Pd starter patch, and its based on oscx. If it wasn't include, that patch would not work at all. So buggy but working is still better than not at all.

.hc

On 10/20/2012 11:56 AM, IOhannes m zmölnig wrote:

On 10/20/2012 04:17 PM, Hans-Christoph Steiner wrote:

...

I'd happily ditch it if there was a drop in replacement. For example, I've had many students come to me with the most popular Processing<--> Pd starter patch, and its based on oscx. If it wasn't include, that patch would not work at all. So buggy but working is still better than not at all.

so what is wrong with my patches? they _are_ drop-in replacements.

if those students use PdX (with [initbang]) one could even writen [OSCroute] wrapper.

I don't know if anything is wrong with them or not, or whether they are fully compatible or not. I can't take on the maintenance of any more libraries, so I'm not going to test them. I encourage you to take it on if you think its important. oscx is there and already included, that's my point.

.hc