Re: [PD] version compile-time checks, was: Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)

[Alexandre Torres Porres]

Yeah it's possible to have code that works for both. And I do agree it
makes good sense in some cases like the single vstplugin~ external.

But not in ELSE though and I guess you weren't asking this so I shouldn't
say anything, but here it goes anyway just in case. I'm not happy with the
idea of doing this for all my externals. I'm now offering multichannel code
for over 50 objects and that's a lot of work... most of these are old
externals, but there are about 16 new ones I just created that are new
objects solely devoted to multichannel fun, so they're meaningless and
shouldn't exist at all in the release. I'm planing more new ones to come
and add mc features to virtually all the existing ones (but there way are
over 200 signal objects in there and I haven't really thought it through).

Anyway, I'm trying to make this library stable, I swear, and I'm trying to
pair it up with PlugData's 1.0 release (version 0.8 is coming soon). In the
meantime, the best I can do is have at least an older pre 0.54 release
there in deken for a reasonable time.

cheers



Em sex., 4 de ago. de 2023 às 18:18, Christof Ressi 
escreveu:

> 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, namely signal_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");
> #elsemy_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-requ...@lists.iem.at wrote:
>
> Message: 3
> Date: Fri, 4 Aug 2023 03:12:27 -0300
> From: Alexandre Torres Porres 
> To: Pd-List 
> Subject: Re: [PD] Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
>
> Em qui., 3 de ago. de 2023 ?s 16:46, IOhannes m zm?lnig 
> 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 
> danomatika.com
> robotcowboy.com
>
>
>
>
> ___pd-l...@lists.iem.at mailing 
> list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] version compile-time checks, was: Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)

[Christof Ressi]

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-requ...@lists.iem.at wrote:

Message: 3
Date: Fri, 4 Aug 2023 03:12:27 -0300
From: Alexandre Torres Porres 
To: Pd-List 
Subject: Re: [PD] Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)
Message-ID:

Content-Type: text/plain; charset="utf-8"

Em qui., 3 de ago. de 2023 ?s 16:46, IOhannes m zm?lnig 


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 
danomatika.com 
robotcowboy.com 




___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management 
->https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management 
->https://lists.puredata.info/listinfo/pd-list___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] version compile-time checks, was: Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)

[Christof Ressi]

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-requ...@lists.iem.at wrote:

Message: 3
Date: Fri, 4 Aug 2023 03:12:27 -0300
From: Alexandre Torres Porres 
To: Pd-List 
Subject: Re: [PD] Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)
Message-ID:

Content-Type: text/plain; charset="utf-8"

Em qui., 3 de ago. de 2023 ?s 16:46, IOhannes m zm?lnig 
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 
danomatika.com 
robotcowboy.com 




___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management 
->https://lists.puredata.info/listinfo/pd-list___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list