Hi,
I have a library with /optional /multi-channel support. If you try to create the object with the "-m" flag and Pd does not have multi-channel support, it would print an error message. This works all fine, but there's a tricky problem with the help patches. Of course, I want to document the multi-channel feature, but I don't want the help patch to print errors when loaded in older Pd versions.
The only solution I see at the moment is to have two version of the help patch and then register the appropriate version in the setup function with "class_sethelpsymbol". However, this would be a maintenance nightmare. Also, the help patches would obviously need to have different names, so only one of them would match the name of the object.
Has anyone run into a similar situation? Any ideas?
Christof
Ok, I have a come up with the following solution: I moved the multichannel section into a dedicated patch and open it with [;pd open <name> <dir> 1( when the user clicks a bang button in the main help patch. It's not perfect, but kind of works for my purposes.
I am still wondering if anyone has run into the same issue and found other solutions.
Christof
On 05.12.2023 22:00, Christof Ressi wrote:
Hi,
I have a library with /optional /multi-channel support. If you try to create the object with the "-m" flag and Pd does not have multi-channel support, it would print an error message. This works all fine, but there's a tricky problem with the help patches. Of course, I want to document the multi-channel feature, but I don't want the help patch to print errors when loaded in older Pd versions.
The only solution I see at the moment is to have two version of the help patch and then register the appropriate version in the setup function with "class_sethelpsymbol". However, this would be a maintenance nightmare. Also, the help patches would obviously need to have different names, so only one of them would match the name of the object.
Has anyone run into a similar situation? Any ideas?
Christof
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
On 12/11/23 15:29, Christof Ressi wrote:
Ok, I have a come up with the following solution: I moved the multichannel section into a dedicated patch and open it with [;pd open <name> <dir> 1( when the user clicks a bang button in the main help patch. It's not perfect, but kind of works for my purposes.
so the user only gets the error if they click on the bang? hmm.
I am still wondering if anyone has run into the same issue and found other solutions.
i don't, but here's my thoughts:
- i think class_sethelpsymbol() is evil in practically all cases (that
do not deal with names that cannot be represented as filenames; and even these cases some hexmunging might be a better solution than class_sethelpsymbol())
- personally i wouldn't care to much about error messages in help
patches (as in: going through hoops in order to avoid them). since in this case you control the actual error message make sure that it is friendly enough (e.g. just telling people that they will need a newer version of Pd in order to use this cool feature) - i strongly believe that we can expect people to actually read and understand an error message (and not just seek help just because "lines were red"). it's not that Pd's error messages are very obtrusive)
if you absolutely insist on not having error messages and do not share my aversion against class_sethelpsymbol() you could create two help patches and in the multichannel version *only* document the multichannel features and include the non-multichannel help patch as an ordinary object (probably with some "auto open" code. that way you wouldn't have to duplicate the common documentation.
mhdgs IOhannes
On 12/11/23 15:29, Christof Ressi wrote:
Ok, I have a come up with the following solution: I moved the multichannel section into a dedicated patch and open it with [;pd open <name> <dir> 1( when the user clicks a bang button in the main help patch. It's not perfect, but kind of works for my purposes.
so the user only gets the error if they click on the bang? hmm.
Yes, it is not perfect. This could be avoided, if Pd had a way to query the version at runtime (see https://github.com/pure-data/pure-data/issues/928). I thought about adding a (private) message to the AOO objects that returns the actual Pd version via sys_getversion(), but this seems a bit overkill.
- personally i wouldn't care to much about error messages in help
patches (as in: going through hoops in order to avoid them).
I do...
since in this case you control the actual error message make sure that it is friendly enough (e.g. just telling people that they will need a newer version of Pd in order to use this cool feature) - i strongly believe that we can expect people to actually read and understand an error message (and not just seek help just because "lines were red"). it's not that Pd's error messages are very obtrusive)
The error message itself is friendly, but in this case the user did nothing wrong - they just opened a help patch! - so I would *really* like to avoid them.
you could create two help patches and in the multichannel version *only* document the multichannel features and include the non-multichannel help patch as an ordinary object (probably with some "auto open" code. that way you wouldn't have to duplicate the common documentation.
Interesting. The big disadvantage is that the roles are reversed: what should be a subpatch is now the root window, so when the user tries to close it, it closes the whole help patch... So I guess I'd rather prefer my current solution.
But thanks for your input!
Christof
On 12/11/23 16:04, Christof Ressi wrote:
Interesting. The big disadvantage is that the roles are reversed: what should be a subpatch is now the root window, so when the user tries to close it, it closes the whole help patch... So I guess I'd rather prefer my current solution.
totally. i was just trying to come up with alternative solutions.
But thanks for your input!
so how about that one: your object could do some context-check, and suppress the error message when it is invoked in a help patch. (the simplest check would just be whether the filename of the containing patch ends with "-help.pd"; alternatively you could embed some magic string in your help patch (on patch-level) and suppress the error only if this string is (also) present.
On 11.12.2023 16:10, IOhannes m zmoelnig wrote:
the simplest check would just be whether the filename of the containing patch ends with "-help.pd"
I actually had this thought, but rejected it for being too gross :-D
Also, it does not really work because [aoo_send~ 2] and [aoo_send~ -m 2] have a different number of signal inlets, so I would get errors about failed connections. (That was another nasty aspect I forgot to mention!) Also, the help patch naturally contains other multichannel objects, most notably [snake~], which don't exist in older Pd versions. I really need to prevent the whole (sub)patch from being loaded.
Christof
-
Christof Ressi -
IOhannes m zmoelnig