Hi,
Are there help patches for dumpOSC, OSCsend, unpackOSC? If so, where can they be found? I have Pd Extended and the dll's are in the folders "mrpeach" and "oscx"; however, the help patches for the mentioned objects are not there (in oscx there's no help patch at all)
thanks m.
On Wed, 2010-04-21 at 10:14 +0200, Matteo Sisti Sette wrote:
Hi,
Are there help patches for dumpOSC, OSCsend, unpackOSC? If so, where can they be found? I have Pd Extended and the dll's are in the folders "mrpeach" and "oscx"; however, the help patches for the mentioned objects are not there (in oscx there's no help patch at all)
In order to help IOhannes not having to repeat himself, I say it again, loud and clear, also here on the pd-list:
Do _not_ start to use the OSCx externals, since they are buggy and unmaintained. Use the OSC and net objects from mrpeach instead (packOSC, unpackOSC, routeOSC, udpsend, udpreceive etc). The OSCx externals are still there only for legacy reasons.
Roman
Roman Haefeli escribió:
Do _not_ start to use the OSCx externals, since they are buggy and unmaintained. Use the OSC and net objects from mrpeach instead (packOSC, unpackOSC, routeOSC, udpsend, udpreceive etc). The OSCx externals are still there only for legacy reasons.
Ok thanks for warning. I will _not_ use them.
If a library or external that is obsolete or deprecated is included in Pd-External, there should be a way for the user to know that. I guess it has already been said a few times in the list, but when you browse the extra folder (or the help browser) and you find an external you don't usually do a search in the list archives to see if it is deprecated...
A way could be to include help-patches (which are missing right now) and put a comment that read "DEPRECATED" in each of them.
thanks m.
On 2010-04-21 13:30, Matteo Sisti Sette wrote:
Roman Haefeli escribió:
Do _not_ start to use the OSCx externals, since they are buggy and unmaintained. Use the OSC and net objects from mrpeach instead (packOSC, unpackOSC, routeOSC, udpsend, udpreceive etc). The OSCx externals are still there only for legacy reasons.
Ok thanks for warning. I will _not_ use them.
If a library or external that is obsolete or deprecated is included in Pd-External, there should be a way for the user to know that. I guess it has already been said a few times in the list, but when you browse the extra folder (or the help browser) and you find an external you don't usually do a search in the list archives to see if it is deprecated...
A way could be to include help-patches (which are missing right now) and put a comment that read "DEPRECATED" in each of them.
another way could be to _not_ include help-patches, so people don't learn how to use them :-)
anyhow, i have now added a "deprecated" line to these objects, so whenever you create one of them, you will get a warning. i thought i already did that once, but probably only in my dreams.
fgmasdr IOhannes
IOhannes m zmoelnig escribió:
another way could be to _not_ include help-patches, so people don't learn how to use them :-)
Mmmmmmmmmm (maybe by completely removing the oscx subfolder from the doc/reference folder)
anyhow, i have now added a "deprecated" line to these objects, so whenever you create one of them, you will get a warning. i thought i already did that once, but probably only in my dreams.
Much better :)
On Wed, 21 Apr 2010, IOhannes m zmoelnig wrote:
another way could be to _not_ include help-patches, so people don't learn how to use them :-)
And so that people don't know how to translate old OSCx-based patches to mrpeach-based patches ?
It might not be such a good idea...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Wed, Apr 21, 2010 at 07:42:17PM -0400, Mathieu Bouchard wrote:
On Wed, 21 Apr 2010, IOhannes m zmoelnig wrote:
another way could be to _not_ include help-patches, so people don't learn how to use them :-)
And so that people don't know how to translate old OSCx-based patches to mrpeach-based patches ?
Didn't someone write wrapper abstractions for this? oscx might be deprecated, but I still like their simple patching interface more than the slightly more complicated (but of course sensible) approach of Martin's objects.
Ciao
Frank
On Wed, 2010-04-21 at 13:30 +0200, Matteo Sisti Sette wrote:
Roman Haefeli escribió:
Do _not_ start to use the OSCx externals, since they are buggy and unmaintained. Use the OSC and net objects from mrpeach instead (packOSC, unpackOSC, routeOSC, udpsend, udpreceive etc). The OSCx externals are still there only for legacy reasons.
Ok thanks for warning. I will _not_ use them.
If a library or external that is obsolete or deprecated is included in Pd-External, there should be a way for the user to know that. I guess it has already been said a few times in the list, but when you browse the extra folder (or the help browser) and you find an external you don't usually do a search in the list archives to see if it is deprecated...
A way could be to include help-patches (which are missing right now) and put a comment that read "DEPRECATED" in each of them.
Absolutely..
Again, it seems just a matter of someone doing the work (tm)
Roman
On 2010-04-21 13:46, Roman Haefeli wrote:
Absolutely..
Again, it seems just a matter of someone doing the work (tm)
in the meantime i have added a "deprecated" message to the OSCx objects (right; i have written that 3 times in the last 15 minutes; i'll stop now)
Roman
ah, matteo: i guess the reason why you didn't get the error message i found in the code is, that it was added rather recently: http://pure-data.svn.sf.net/viewvc/pure-data?view=rev&revision=13084
mfgasdr IOhannes
IOhannes m zmoelnig wrote:
On 2010-04-21 13:46, Roman Haefeli wrote:
Absolutely..
Again, it seems just a matter of someone doing the work (tm)
in the meantime i have added a "deprecated" message to the OSCx objects (right; i have written that 3 times in the last 15 minutes; i'll stop now)
Obviously maintaining deprecated libraries is needed for compatibility, but what's the usual 'life' of deprecated stuff in Extended before it actually gets removed? I mean .x releases, major release? Just curious.
Lorenzo
On Wed, 21 Apr 2010, Roman Haefeli wrote:
On Wed, 2010-04-21 at 13:30 +0200, Matteo Sisti Sette wrote:
A way could be to include help-patches (which are missing right now) and put a comment that read "DEPRECATED" in each of them.
Absolutely.. Again, it seems just a matter of someone doing the work (tm)
It's not just that. I wonder if IOhannes is currently getting a complaint from Hans for editing a file that doesn't belong to him, without asking the person's permission ? If not, when will he get a complaint ?
who is externals/OSCx/* belonging to, anyway ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 2010-04-22 03:18, Mathieu Bouchard wrote:
On Wed, 21 Apr 2010, Roman Haefeli wrote:
On Wed, 2010-04-21 at 13:30 +0200, Matteo Sisti Sette wrote:
A way could be to include help-patches (which are missing right now) and put a comment that read "DEPRECATED" in each of them.
Absolutely.. Again, it seems just a matter of someone doing the work (tm)
It's not just that. I wonder if IOhannes is currently getting a complaint from Hans for editing a file that doesn't belong to him, without asking the person's permission ? If not, when will he get a complaint ?
i don't know why you want to depict a scenery with hans sitting there like a bulldog and watching people to not mess around with other's code. it's not like that.
however, i guess the main reason why i did not edit those files earlier was that i did not felt responsible for them (read: it is not my code, it belongs to somebody else)
i can assure you, that this is an entirely internal business of mine, and has nothing to do with any watchdogs.
who is externals/OSCx/* belonging to, anyway ?
iirc, it's belonging to oswald; since he has left Pd a long time ago in favour of SC, i don't think he minds so much if somebody modifies this code (he's probably happy to not be associated too much with unmaintained and buggy code)
gsmdft IOhannes
On Thu, 22 Apr 2010, IOhannes m zmoelnig wrote:
i don't know why you want to depict a scenery with hans sitting there like a bulldog and watching people to not mess around with other's code. it's not like that.
I don't have to "depict" it, it happened for real. I just don't want to paste private mails to pd-list. :(
But, when thst happened, I just deleted my sourceforge account, so, that solved the problem for me.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Hi,
On Thu, Apr 22, 2010 at 09:08:04AM +0200, IOhannes m zmoelnig wrote:
iirc, it's belonging to oswald; since he has left Pd a long time ago in favour of SC, i don't think he minds so much if somebody modifies this code (he's probably happy to not be associated too much with unmaintained and buggy code)
oscx is community-maintained. I did some commits, mainly to [OSCroute], which is not buggy AFAIK, others did other commits.
Ciao
Frank
On 2010-04-22 16:26, Frank Barknecht wrote:
oscx is community-maintained. I did some commits, mainly to [OSCroute], which is not buggy AFAIK, others did other commits.
ok. i did some commits as well.
but still it shows how bad a maintainer community can be.
fgmasdr IOhannes
On 2010-04-21 10:14, Matteo Sisti Sette wrote:
Hi,
Are there help patches for dumpOSC, OSCsend, unpackOSC? If so, where can they be found? I have Pd Extended and the dll's are in the folders "mrpeach" and "oscx"; however, the help patches for the mentioned objects are not there (in oscx there's no help patch at all)
do not use OSCx!
if you need help-patches, then not all is lost and you can still switch to mrpeach's objects.
mfgasdr IOhannes
PS: if the installer forgot to include the help-patches, you can also get them via svn. e.g. https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/mrpe...
PPS: indeed there is no help patch for [unpackOSC]! however, you should be able to understand the object from unpackOSCstream-help.pd; i guess martin would gladly include a simple help if you could provide one.
IOhannes m zmoelnig wrote:
PPS: indeed there is no help patch for [unpackOSC]! however, you should be able to understand the object from unpackOSCstream-help.pd; i guess martin would gladly include a simple help if you could provide one.
The help patch for [unpackOSC] is the same as for [routeOSC]. I should probably set the help symbol for unpackOSC to be "routeOSC".
Martin
-
Frank Barknecht -
IOhannes m zmoelnig -
Lorenzo -
Martin Peach -
Mathieu Bouchard -
Matteo Sisti Sette -
Roman Haefeli