[PD] version compile-time checks, was: Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)
Christof Ressi
info at christofressi.com
Sat Aug 5 00:07:13 CEST 2023
Actually, I think we could streamline this process with a new API
function: https://github.com/pure-data/pure-data/issues/2075
On 04.08.2023 23:16, Christof Ressi wrote:
>
>> To avoid bleeding-edge red, is the following not possible with externals?
> This would work in a way that you could compile ELSE for older Pd
> versions. But then you would essentially need to ship two different
> versions: one for Pd 0.54> and another one for Pd 0.54<=.
>
> Ideally, there should be one version that works for both older and
> newer Pd versions. A simple runtime check is not enough because
> multichannel objects need to call a new API function,
> namelysignal_setmultiout(). Any external that calls this function
> would refuse to load with older Pd versions that do not have this symbol.
>
> Now, what you can do is try to load signal_setmultiout() explicitly
> with dlsym resp. GetProcAddress:
>
> typedef void (*signal_setmultiout_fn)(t_signal **, int);
> signal_setmultiout_fn my_signal_setmultiout; // in setup function:
> #ifdef _WIN32 my_signal_setmultiout =
> (signal_setmultiout_fn)GetProcAddress(GetModuleHandle(NULL),
> "signal_setmultiout"); #else my_signal_setmultiout =(signal_setmultiout_fn)dlsym(dlopen(NULL, RTLD_NOW),
> "signal_setmultiout"); #endif // in DSP method: if
> (my_signal_setmultiout) // Pd has multichannel support ... else // no
> multichannel support ...
>
> That's what I am planning to do for vstplugin~ and aoo.
>
> Christof
>
> On 04.08.2023 20:31, Dan Wilcox wrote:
>> To avoid bleeding-edge red, is the following not possible with externals?
>>
>> #ifdef PD_MAJOR_VERSION >= 0 and PD_MINOR_VERSION >= 54
>> // multichannel code
>> #else
>> // non-multichannel code
>> #endif
>>
>> Depending upon the code layout, you could also probably use some
>> macros for lots of redundant stuff.
>>
>>> On Aug 4, 2023, at 8:18 AM, pd-list-request at lists.iem.at wrote:
>>>
>>> Message: 3
>>> Date: Fri, 4 Aug 2023 03:12:27 -0300
>>> From: Alexandre Torres Porres <porres at gmail.com>
>>> To: Pd-List <pd-list at lists.iem.at>
>>> Subject: Re: [PD] Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)
>>> Message-ID:
>>> <CAEAsFmj2J+BAF3djDfUDeyaFtUjPXcFkRFiZn6fpAob06Ha5Vw at mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Em qui., 3 de ago. de 2023 ?s 16:46, IOhannes m zm?lnig
>>> <zmoelnig at iem.at>
>>> escreveu:
>>>
>>>> Personally I think this is a bug in ELSE, and would file a bug that it
>>>> ought to be buildable against older versions of Pd (even if that means
>>>> that some functionality is missing).
>>>>
>>>
>>> I'm creating new objects for multichannel fun and adding multichannel
>>> awareness to old objects, right now there are over 50 signal objects
>>> that
>>> are multichannel aware (and counting).
>>>
>>> Without 0.54 you'll just have many errors trying to deal with
>>> CLASSMULTICHANNEL
>>>
>>> So yup, 0.54 is needed. Sorry I'm always on the bleeding edge
>>
>> --------
>> Dan Wilcox
>> @danomatika <http://twitter.com/danomatika>
>> danomatika.com <http://danomatika.com>
>> robotcowboy.com <http://robotcowboy.com>
>>
>>
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20230805/2784376e/attachment-0001.htm>
More information about the Pd-list
mailing list