[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