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!

@Pierre-Guillot thanks!! great improvements!

@jancsika I followed step 1 (but before i deleted all my old purr-data build) and i have this
purr-data-light-win64-branch-build-log.sh

@jancsika How can i try it? I don't know how to select this branch for compiling

@cuinjune Is there any building instructions?

@jancsika Let me know if you need any help! Meanwhile i'm trying to take a little confidence with make and gcc/g++ ( i'm more used to VS and CodeBlocks).

@jancsika I wrote a .txt with alle the instructions to have a working building process for Win64. Building Purr Data for Windows 64bit.txt
Maybe you can just upload it in the page where the Win32 instructions are?
There are some change in the purr-data/externals/Makefile and several changes in the purr-data/packages/win32_inno/Makefile

@jancsika Yeah, i'll try today or tomorrow to sum up all changes i've done.
How the merge request work?
I mean, i commented out some crossplatform stuff to exclude Gem. So i don't want to do something that can harm the whole building system.

@jancsika

Some report after testing Purr Data compiled for Win64.

1. I have a strange bug related to MIDI device. I'll have to check if it exists in PD vanilla 32 bit. I have the same bug in PD vanilla for 64bit compiled by Lucas. I don't think it is a multiclient midi driver issue. But i'll check it better. BTW if i choose a MIDI device and apply so it goes saved for the next start of Purr Data..well Purr Data doesn't start anymore and i have to clean the prefs via regedit because it seems that a command line pd.exe -nomidi does not work for Purr Data as it does with Vanilla

2. zexy library does not work even if the .dll externals files are compiled. I have to check the build log because i remember there were some red warnings about specific zexy externals. So every zexy help file i tried shows red outlined externals because the zexy stuff can't be instantiated.

3. there are minor naming errors in some help files that i guess are in the official Purr Data 32bit release (i.e. linearpan~ in pan lib should be linear_pan~

4. timestretch~ just crash Purr Data and the program quits.

5. moocow folder is empty

6. pixelTango does not work but i guess it has something to do with Gem externals dependencies

7. SMLib help file is not present

8. pmpd loads but does not seem to work

9. Gem and fluidsynth~ don't compile for win64 target (so as you know i removed those from the building process)

@jancsika Yeah! that's true. So installed and working correctly at least with simple MIDI and audio test. Portaudio ASIO working. Now i'll check some external helpfile.
So i guess the only things to work on various Makefiles are

1. some path adjusting
2. some file name adjusting
3. correct target architecture
4. invoke correct .dll libraries
5. Solve Gem issues not compiling for Win64
6. Solve fluidsynth~ issues not compiling for Win64

some good additions could be

1. new cyclone library
2. pd-else library
3. oFelia library
4. aubio library

@jancsika Thanks. Now building seems to be ok

Successful compile (177.719 sec). Resulting Setup program filename is:
C:\purr-data\packages\win32_inno\Output\Purr Data 2.5.0-20180404-rev.ff8afc1.exe

win32_inno install succeeded!
copying pd-l2ork-specific externals...
done with l2ork addons.
done.

But C:\purr-data\packages\win32_inno\Output\ is empty. I try to recompile tomorrow running MSYS2 in administrator mode because could be that Win10 doesn't like tho write files in the root directory. I'm not sure but could be. I'll check it tomorrow! Thanks for your help.