Hi! Any suggestion to compile it for Win64?

Hi @myQuil.
Great stuff!
Is it compiled for win64 to?
thanks

Hi all,
i'm trying to get in my way to compile some external for pd on Win64.
I followed a Code::Blocks configuration tutorial here (which is about win32 tho).

1. It seems that the src folder for the last pd ( http://msp.ucsd.edu/Software/pd-0.48-2-64bit.msw.zip ) doesn't contain pd.a no more.

2. So i took pd.a form the src folder of my pd 32bit installation.

3. The external (i named it "blank") compiles with no errors but when i try to load it in pd
   C:\Users\Live Machine\Documents\Pd\externals\blank\blank.dll: couldn't load

Maybe the mingw64 compiler isn't working for pd 64x on windows?

any help appreciated!

best

Great work Pierre! Thank you very much!
How about integrating this in Camomile?
a.

@seb-harmonik.ar thanks for the suggestion!! i just forgot all the filter design arsenal!

@weightless said:

@alfonso.santimone Hi, this seems to be more precise:
AS-samples-count2.pd

Indeed you need [block~ 1] as well as a a snapshot that updates at each sample. Also round instead of int seems to be more precise. I don't know if it's too expensive but I can't think of other ways to do it. I tried [bang~] attached to a [f]x[+ 1] counter but it only bangs every 64 samples even with block 1, not sure why.

@weightless Hi, thanks for the suggestions. The snapshot~, btw, is just there for monitoring purposes. I plan to use the counter with an audio rate output.

thanks!

Hi all.
Here's a simple attempt at a phase distortion based variable sawtooth.
It differs from classical Casio-style PD synthesis because the phasor distortion node point can be moved not only along the X axis but along the Y axis to.
BTW i notice a slight pitch changing when the node X position is going toward the extreme left or right.
I don't really know the cause. Is it just a psychoacoustic effect because the harmonic content just grows?
Should i nest the whole thing in a subpatcher and use a [ block~ 1]?
Is [ expr~ ] not so precise or too cpu intensive?
thanks
AS-VarSawXY.pd

Hi all. I'm trying to do a sample counter for various purposes. But i can't use externals beacause i have to do some Camomile projects (in the future Camomile may support externals but as it is now i have to go the vanilla path).
So this is a little idea. The drawback is that it can't count forever. But it can count a very high number of seconds/samples if an high number of max seconds to run is set.
Is a very rough attempt and i don't know if it is precise enough. Probably has to be nested in a subpatch with a [ block~ 1 ] object?
Is [ expr~ int($v1) ] bad for cpu performance?
anyway...
AS-samples-count~.pd

Thanks for the info @Pierre-Guillot!
@Pierre-Guillot said:

Hi @alfonso.santimone

I argue that adding external is just a matter of incorporating them in libpd.dll. Am I right?

Yes but the libpd used by Camomile is the static library (.lib/.so/.a) that why libpd is embedded in Camomile.

1. In fact, I guess that some of the external libraries are already compatible with multiinstance support because it depends on what parts of the Pd API the libraries use. But to ensure the multiinstance support you must use the C flags -DPDINSTANCE=1 (and -DPDTHREAD=1) while compiling the library or libpd and avoid all the static variables (except if they use thread local storage and you ensure to init them well on each thread). Here is one of the 1st posts by Miller about it: https://lists.puredata.info/pipermail/pd-dev/2017-04/020980.html

So i guess i have to remove directly from the external code all the static variable, so basically remove the "static" keyword from the variable declarations.
How can i compile libpd as a .lib/.so/.a and not .dll?
Should i use those flags in the various makefiles or just as a fleg in the command line? (assuming working with msys2 on Win64)

2. The same way you did it for the "standard" approach.

So it's enough to use a x64 compiler and a x64 target?

3. Including an external library with libpd is pretty straightforward (as long as, in this case, the library has the multiinstance support). See this: https://github.com/libpd/libpd/wiki/Adding-Pure-Data-external-libraries-to-your-project. And if a library is included in libpd it will also be included in Camomile.

So you also have to compile libpd then Camomile (all the instructions are on the Github repository - I updated it a week ago https://github.com/pierreguillot/Camomile/tree/dev/v1.0.6-lv2#compilation - or just do the same steps as on Travis and Appveyor and I can help if needed).

Cheers

I don't really know what Travis and Appeveyor are. I have to check them out.
How to include the static pthread lib for Win compilation? You mention it the Camomile build process readme.

PS: Another approach would have been to ship the libpd dynamic library next to each plugin. i need to try this but I afraid that, on Windows and Linux, the DAW think that the libpd library is another plugin try to load it.

I guess that most hosts have an avoid list for specific .dll. At least Reaper have a config file where is possible to remove a specific .dll from being scanned as a plugin.

thanks!

Hi @Pierre-Guillot and thanks for your continuing work on this!
I argue that adding external is just a matter of incorporating them in libpd.dll. Am I right? If I am right would be great to have a tutorial on

1. Making multiinstance support into an existing external or external library
2. How's to make it compatible and build for all the platforms (Win64, Win32, osx, Linux)
3. How to include them in libpd.dll and Camomile.

I guess every Camomile users can try to include the externals and external libraries they need.
Given the modular nature of pd I think this is essential for Camomile.
Thanks!