[PD] openCV and PD

[michael strohmann]

Hi!

Is anyone using openCV or anything similar regarding image analysis in pd-0.54 
right now ?
I cannot get the pix_openCV externals from Antoine Villeret to work and 
pix_video crashes pd…

Just wanted to know if anyone got this to work ? (I run osx 10.13)

Thanks!
mkl___
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)

[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

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

[Dan Wilcox]

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 mailto:por...@gmail.com>>
> To: Pd-List mailto:pd-list@lists.iem.at>>
> 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] [PD-announce] Emille 2023 - call for papers

[dudas]

2023 Call for Papers



The Korea Electro-Acoustic Music Society (KEAMS) announces a call for papers 
for the journal Emille.

Emille is an open-access and peer-reviewed journal, and was formed to promote 
active research and to share the results on computer music. Submitted papers 
are selected through the review process, and are published in Vol. 21. Authors 
are not requested for any submission, processing, or publication fees, by the 
support from Arts Council Korea.

If you want your paper to be considered for publication in 2023, please submit 
a manuscript(both a text file and a PDF document) and a curriculum vitae to 
emille[at]keams.org  by the due date.














Please visit the link below for further information: 
http://keams.org/emille/call.html






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

Re: [PD] Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)

[Alexandre Torres Porres]

Em qui., 3 de ago. de 2023 às 19:51, Linux Rouen Normandie <
linux.ro...@free.fr>

> *As my compilation finished with no warning and after the binary
> installation Pd is working well, I think it found the headers (by the way,
> which ones).*
>

it did find headers, as you were able to build a couple of objects or so,
right? It didnt complain it couldn't frin m_pd.h for instance.

but then, it found old headers, from versions earlier than 0.54 somehow...
cause you can't build the objects with multichannel support...

I have no idea how to help you find the correct headers in a raspberry
pi... you could force the pd path with something like
pdincludepath=~/pd-0.54-0/src/
as described in the readme

cheers


>
> 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).
>
> *Perhaps not as my compilation is working well, my issue is just with
> Else compilation on RPi or I've missed something.*
>
> https://github.com/porres/pd-else#building-else-for-pd-vanilla
>
> mfg.sfg.jfd
> IOhannes
>
> ___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] Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)

[IOhannes m zmölnig]

Am 4. August 2023 00:49:16 MESZ schrieb Linux Rouen Normandie 
:
>> Pd-0.54 has been released after Debian/bookworm, so you cannot use the Pd 
>> bundled with your Raspbian/bookworm.
>/Not really understanding 'bookworm'.//

It's the codename of the latest Debian release (aka "Debian 12").

Your favourite web search engine might have helped...


>> When compiling of yourself, you must make sure that the build system can 
>> find the headers.
>/    As my compilation finished with no warning and after the binary 
>installation Pd is working well, I think it found the headers (by the way, 
>which ones)./


The error messages you see are about features that are *only* present in the 
headers of Pd-0.54 (or newer).
So the compilation process of ELSE find the wrong headers.
This could be because you haven't properly "install"ed Pd-0.54, or because you 
have both the headers for Pd-0.54 and some older (incompatible) version, and 
the older ones take precedence for whatever reason.
It's it's the latter, you should uninstall the old headers (eg "apt remove 
puredata-dev", if you have also installed the puredata package from Raspbian 
and your Raspbian is new enough (I'm afk right now so please check yourself)).
If it's the former, you should properly install Pd  (using 'make install').

>> 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).
>/Perhaps not as my compilation is working well, my issue is just with Else 
>compilation on RPi or I've missed something

Your error is, that ELSE doesn't do any compile time check for the Britain of 
the Pd headers, and just assumes that everything is there.
Which I think is a bug in ELSE in any case.


mfg.sfg.jfd
IOhannes


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

Re: [PD] Building ELSE for Pd Vanilla (here RPi OS 11 32-bit)

[Alexandre Torres Porres]

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

cheers



>
> https://github.com/porres/pd-else
>
> mfg.sfg.jfd
> IOhannes
> ___
> 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