On today's Pd-extended 0.42.5-rc3 for Ubuntu lucid i386 I get this message if I open routeOSC-help:
error: 'routeOSC-help.pd' is a deprecated name format for a help patch. Please rename to 'routeOSC-help-help.pd'!
I can't find it in the source anywhere. Does anyone know where it's coming from?
Martin
On Mon, 14 Jun 2010, Martin Peach wrote:
On today's Pd-extended 0.42.5-rc3 for Ubuntu lucid i386 I get this message if I open routeOSC-help: error: 'routeOSC-help.pd' is a deprecated name format for a help patch. Please rename to 'routeOSC-help-help.pd'! I can't find it in the source anywhere. Does anyone know where it's coming from?
It's coming from s_path.c, function open_via_helppath, label gotone_deprecated, line 428.
It's because of a bug in mrpeach/osc/routeOSC.c, function routeOSC_setup, line 146, which reads :
class_sethelpsymbol(routeOSC_class, gensym("routeOSC-help.pd"));
when it ought to be :
class_sethelpsymbol(routeOSC_class, gensym("routeOSC"));
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard wrote:
On Mon, 14 Jun 2010, Martin Peach wrote:
On today's Pd-extended 0.42.5-rc3 for Ubuntu lucid i386 I get this message if I open routeOSC-help: error: 'routeOSC-help.pd' is a deprecated name format for a help patch. Please rename to 'routeOSC-help-help.pd'! I can't find it in the source anywhere. Does anyone know where it's coming from?
It's coming from s_path.c, function open_via_helppath, label gotone_deprecated, line 428.
...which exists only in the pd-extended version I think.
It's because of a bug in mrpeach/osc/routeOSC.c, function routeOSC_setup, line 146, which reads :
class_sethelpsymbol(routeOSC_class, gensym("routeOSC-help.pd"));
when it ought to be :
class_sethelpsymbol(routeOSC_class, gensym("routeOSC"));
Ah yes, thanks. It's fixed in svn now.
Martin
On Jun 14, 2010, at 3:15 PM, Martin Peach wrote:
Mathieu Bouchard wrote:
On Mon, 14 Jun 2010, Martin Peach wrote:
On today's Pd-extended 0.42.5-rc3 for Ubuntu lucid i386 I get this
message if I open routeOSC-help: error: 'routeOSC-help.pd' is a deprecated name format for a help
patch. Please rename to 'routeOSC-help-help.pd'! I can't find it in the source anywhere. Does anyone know where
it's coming from?It's coming from s_path.c, function open_via_helppath, label
gotone_deprecated, line 428....which exists only in the pd-extended version I think.
It's because of a bug in mrpeach/osc/routeOSC.c, function
routeOSC_setup, line 146, which reads : class_sethelpsymbol(routeOSC_class, gensym("routeOSC-help.pd")); when it ought to be : class_sethelpsymbol(routeOSC_class, gensym("routeOSC"));Ah yes, thanks. It's fixed in svn now.
Martin
Really, the whole class_sethelpsymbol() function should be removed
since Pd will automatically assume the classname is the base of the
helpfile name. That function is only used for times when the help
patch has a different name than the object, which is bad practice IMHO.
.hc
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
On Mon, 14 Jun 2010, Hans-Christoph Steiner wrote:
Really, the whole class_sethelpsymbol() function should be removed since Pd will automatically assume the classname is the base of the helpfile name.
d'oh, right.
That function is only used for times when the help patch has a different name than the object, which is bad practice IMHO.
Well, I use it in order to say that the help-file of [gf/string_<] is really named "gf/string_0x3c" as one of the steps to bypass the big fuck of hexloader, its inability to handle all cases because pd won't let it do, the inability of win32 to handle "<" in filenames, and the inability of svn-win32 to continue a checkout after finding a "<" in a filename.
I don't remember : is hexloader supposed to handle the case of sethelpsymbol at all ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Hans-Christoph Steiner wrote:
On Jun 14, 2010, at 3:15 PM, Martin Peach wrote:
Mathieu Bouchard wrote:
On Mon, 14 Jun 2010, Martin Peach wrote:
On today's Pd-extended 0.42.5-rc3 for Ubuntu lucid i386 I get this message if I open routeOSC-help: error: 'routeOSC-help.pd' is a deprecated name format for a help patch. Please rename to 'routeOSC-help-help.pd'! I can't find it in the source anywhere. Does anyone know where it's coming from?
It's coming from s_path.c, function open_via_helppath, label gotone_deprecated, line 428.
...which exists only in the pd-extended version I think.
It's because of a bug in mrpeach/osc/routeOSC.c, function routeOSC_setup, line 146, which reads : class_sethelpsymbol(routeOSC_class, gensym("routeOSC-help.pd")); when it ought to be : class_sethelpsymbol(routeOSC_class, gensym("routeOSC"));
Ah yes, thanks. It's fixed in svn now.
Martin
Really, the whole class_sethelpsymbol() function should be removed since Pd will automatically assume the classname is the base of the helpfile name. That function is only used for times when the help patch has a different name than the object, which is bad practice IMHO.
OK I took it out. [unpackOSC] used the help patch for [routeOSC] so I left that one in.
Martin
Hans-Christoph Steiner (I think) wrote:
Really, the whole class_sethelpsymbol() function should be removed since Pd will automatically assume the classname is the base of the helpfile name. That function is only used for times when the help patch has a different name than the object, which is bad practice IMHO.
So it is a bad practice that the help for [+], [-], [*], [/] be a single "operators-help" patch? Or the help for [notein], [ctlin], [ctlout] etc in "midi-help.pd"?
On 2010-06-15 09:59, Matteo Sisti Sette wrote:
Hans-Christoph Steiner (I think) wrote:
Really, the whole class_sethelpsymbol() function should be removed since Pd will automatically assume the classname is the base of the helpfile name. That function is only used for times when the help patch has a different name than the object, which is bad practice IMHO.
So it is a bad practice that the help for [+], [-], [*], [/] be a single "operators-help" patch? Or the help for [notein], [ctlin], [ctlout] etc in "midi-help.pd"?
don't mistake "bad practice IMHO" for "bad practice".
fmasdr IOhannes
IOhannes m zmoelnig escribió:
On 2010-06-15 09:59, Matteo Sisti Sette wrote:
Hans-Christoph Steiner (I think) wrote:
Really, the whole class_sethelpsymbol() function should be removed since Pd will automatically assume the classname is the base of the helpfile name. That function is only used for times when the help patch has a different name than the object, which is bad practice IMHO.
So it is a bad practice that the help for [+], [-], [*], [/] be a single "operators-help" patch? Or the help for [notein], [ctlin], [ctlout] etc in "midi-help.pd"?
don't mistake "bad practice IMHO" for "bad practice".
Of course. But I meant, "do you really think that....?"
On Jun 15, 2010, at 6:58 AM, IOhannes m zmoelnig wrote:
On 2010-06-15 12:48, Matteo Sisti Sette wrote:
don't mistake "bad practice IMHO" for "bad practice".
Of course. But I meant, "do you really think that....?"
me too.
fgmasdr IOhannes
Yes, I really think that its bad practice to have multiple objects use
a single help patch. We talked about this at length in the PDDP
meetings. It makes things confusing to newbies and it usually means
the shared help patches don't illustrate the individual objects well.
The only reason to do it that way is laziness IMHO.
.hc
"We have nothing to fear from love and commitment." - New York Senator
Diane Savino, trying to convince the NY Senate to pass a gay marriage
bill
Hans-Christoph Steiner wrote:
On Jun 15, 2010, at 6:58 AM, IOhannes m zmoelnig wrote:
On 2010-06-15 12:48, Matteo Sisti Sette wrote:
don't mistake "bad practice IMHO" for "bad practice".
Of course. But I meant, "do you really think that....?"
me too.
fgmasdr IOhannes
Yes, I really think that its bad practice to have multiple objects use a single help patch. We talked about this at length in the PDDP meetings. It makes things confusing to newbies and it usually means the shared help patches don't illustrate the individual objects well. The only reason to do it that way is laziness IMHO.
Well the original post related to [routeOSC] and [unpackOSC] using the same help file. I did that because [unpackOSC] is fairly useless on its own and [routeOSC] won't work without [unpackOSC] ahead of it. Also [slipenc] and [slipdec] are easier to demonstrate using a single help patch. Is having two identical patches with different names somehow better? If I use class_sethelpsymbol the user will get the correct help patch if they right-click 'help'. I suspect most peeps do it that way instead of drilling down into the externals looking for help patches.
Martin
On 2010-06-16 01:15, Martin Peach wrote:
Well the original post related to [routeOSC] and [unpackOSC] using the same help file. I did that because [unpackOSC] is fairly useless on its own and [routeOSC] won't work without [unpackOSC] ahead of it. Also
hmm, i cannot quite follow. i have been using countless full-blown patches using [unpackOSC] without [routeOSC]. if the namespace is rather flat and you don't care for pattern-matching (which i learned to avoid anyhow, as the overhead is often too big), [route] is a nice replacement. of course you don't get the nifty [routeOSC] features, but what do i need them for with [routeOSC /amplitude /gain] ?
the other way around it's probably even more interesting. while OSC is often seen as a means to network 2 applications, it is of course more generic. people are known to use OSC messages (or at least: OSC-like messages) for all kind of things, e.g. iirc, SSSAD is using it internally. so [routeOSC] definitely has it's uses without a [packOSC]
nevertheless, i am the last to enforce a one-helppatch-per-object.
fgamsrd IOhannes
Hi,
On Wed, Jun 16, 2010 at 09:26:16AM +0200, IOhannes m zmoelnig wrote:
people are known to use OSC messages (or at least: OSC-like messages) for all kind of things, e.g. iirc, SSSAD is using it internally.
Actually Memento/rradical uses OSC-like messages, sssad just uses [route]s so it stays pure vanilla single-speed bike Pd.
Ciao
Frank
On Jun 15, 2010, at 7:15 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
On Jun 15, 2010, at 6:58 AM, IOhannes m zmoelnig wrote:
On 2010-06-15 12:48, Matteo Sisti Sette wrote:
don't mistake "bad practice IMHO" for "bad practice".
Of course. But I meant, "do you really think that....?"
me too.
fgmasdr IOhannes
Yes, I really think that its bad practice to have multiple objects
use a single help patch. We talked about this at length in the
PDDP meetings. It makes things confusing to newbies and it usually
means the shared help patches don't illustrate the individual
objects well. The only reason to do it that way is laziness IMHO.Well the original post related to [routeOSC] and [unpackOSC] using
the same help file. I did that because [unpackOSC] is fairly useless
on its own and [routeOSC] won't work without [unpackOSC] ahead of
it. Also [slipenc] and [slipdec] are easier to demonstrate using a
single help patch. Is having two identical patches with different
names somehow better? If I use class_sethelpsymbol the user will get
the correct help patch if they right-click 'help'. I suspect most
peeps do it that way instead of drilling down into the externals
looking for help patches.
This is a good example of what I am talking about. It would be silly
to make a help patch for [packOSC] without [unpackOSC], but that
doesn't mean that they are the same thing. The [packOSC] help file
should cover all the possibilities of [packOSC] and use [unpackOSC]
and whatever else to illustrate them. Adding all the possibilities of
[unpackOSC] to the [packOSC] unnecessarily complicates the [packOSC]
help patch. Therefore there should also be an [unpackOSC] help patch.
.hc
All information should be free. - the hacker ethic
On Tue, 15 Jun 2010, Hans-Christoph Steiner wrote:
Yes, I really think that its bad practice to have multiple objects use a single help patch. We talked about this at length in the PDDP meetings. It makes things confusing to newbies and it usually means the shared help patches don't illustrate the individual objects well. The only reason to do it that way is laziness IMHO.
In other news, individual helpfiles tend to not illustrate relationships and similarities well.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Martin Peach -
Mathieu Bouchard -
Matteo Sisti Sette