On 14.11.2024 13:56, IOhannes m zmoelnig wrote:
On 11/14/24 13:45, Christof Ressi wrote:
i don't really see why we cannot consider sending a message to a global receiver to be part of the API, at least for procedures that do not return anything.
Because this is not idiomatic. I really don't want to assemble a Pd message just to make an API call. Do you know of any other API that is *only* accessible through a Pd message?
tuning dsp on/off?
canvas_suspend_dsp() + canvas_resume_dsp()
fast-forwarding?
I'd argue this is a patch level feature and not part of the external API.
in the worst case (of an older Pd version that does not yet have the given message), Pd just spits out an error ("unknown message").
You just hit another downside of Pd messages: no opportunity for error handling
and in this case, we don't even need error handling. we can do a runtime check of the Pd version and don't trigger an error in the first place.
It's a general downside with this approach, so let's better not start it. That being said, I do see a chance for error checking: Pd could check if a suitable extension file exists for the current GUI backend and return failure otherwise.
if instead we bake it into a proper C function call, then an older Pd version will simply refuse to load the external that "naively" uses the function (without checking whether the function actually exists).
That's why we now have sys_getfunbyname() :)
yes. but with Pd I prefer to be very conservative. so I'll wait a couple of years to make sure that practically all installations of Pd that might use my externals do have the sys_getfunbyname()
Well, by that logic we can't introduce any new API functions. Or do you want to make all new API functions only available as Pd messages for the next 10 years? I hope not...
mgfdr IOhannes
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/LGCJGQIITWE...