trying to build on windows

[guillaume-leo]

Hello everyone, I'm trying to build these externals on windows, with no success. When I try to generate the solution with visual studio 2017 I get a lot of errors.. I think I'm missing something, someone achieve to build this on windows?

Thank you for your help

Guillaume

[guillaume-leo]

After trying to build them by following the purr-data method. I still have errors. I paste here what I have

If someone achieve to do this, I would really like to know how to do it or at least having windows 64 bit builds of these wonderfull objects :)

Thank you very much everyone

[sidec]

I managed to compile in msys2 MinGW 64-bit on win10 after adding this to CMakeList.txt

if(WIN32)
    message("windows support limited")
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DTEST -fPIC" )
    set(PD_CMAKE_PATH "C:/Program Files/Pd") 
    set(EXECUTABLE_NAME mi4pd)
endif()

also, to force cmake to use Unix Makefile generator instead of default MSVC
I added file next to CMakeList.txt called PreLoad.cmake with following:

set(CMAKE_GENERATOR "Unix Makefiles" CACHE INTERNAL "" FORCE)

So,

mkdir build && cd build && cmake .. && make

produces DLLs in ./release/bin/ with some minor warnings, but all audio object causes segmentation fault and crashes Pd straight after enabling DSP. Only grids is usable.

Output from cmake ..

cmake ..
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- The C compiler identification is GNU 10.3.0
-- The CXX compiler identification is GNU 10.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/msys64/mingw64/bin/cc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/msys64/mingw64/bin/c++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
windows support limited
-- Build type: Release
-- Processor: AMD64
-- Configuring done
-- Generating done
-- Build files have been written to: Mi4Pd/build

Example of warnings from build:

Scanning dependencies of target rngs
[ 85%] Building CXX object rngs/CMakeFiles/rngs.dir/rngs~.cpp.obj
Mi4Pd/rngs/rngs~.cpp:96:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   96 |     t_rngs_tilde *x = (t_rngs_tilde *) (w[1]);
      |                       ^~~~~~~~~~~~~~~~~~~~~~~
Mi4Pd/rngs/rngs~.cpp:97:20: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   97 |     t_sample *in = (t_sample *) (w[2]);
      |                    ^~~~~~~~~~~~~~~~~~~
Mi4Pd/rngs/rngs~.cpp:98:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   98 |     t_sample *out = (t_sample *) (w[3]);
      |                     ^~~~~~~~~~~~~~~~~~~
Mi4Pd/rngs/rngs~.cpp:99:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   99 |     t_sample *aux = (t_sample *) (w[4]);
      |                     ^~~~~~~~~~~~~~~~~~~

As toolchain is pretty the same as for linux x64 so this might refer to #10 but I don't know if anyone on linux has the same problem

[guillaume-leo]

that's a first step (and a nice one :) )
I will try this soon and report if it's the same on my side

guillaume

[sidec]

Obviously this seg fault has something to do with the main dsp routine, how to interpret this warning I don't know, and I am not sure if this is the culprit. Also, these externals AFAIK were tested with 32 bit builds of Pd, so this might be the issue. That's true? @TheTechnobear

[TheTechnobear]

Ive updated the Cmakefie.txt, which hopefully means it will now compile on Windows , as it defines TEST (which was missing for a number of platforms)

re: set(PD_CMAKE_PATH "C:/Program Files/Pd")
I would NOT want to include specific paths.. this is why I supply m_pd.h

why do you think you need?)
set(CMAKE_GENERATOR "Unix Makefiles" CACHE INTERNAL "" FORCE)

I suspect, what happened is you generated the makefiles, incorrectly for a platform, then tried again.
in this case, normally, I would just delete the 'build' directory and recreate it.
no point in complicating matters ;)

(issue #10 had nothing to with this issue, that was simply missing TEST macro)

I dont think this is an issue with 64 bit or not... since macOS has been 64 bit for quite a while,
and Ive compiled on a new M1, which is only 64 bit ;) (though not tested yet)

interestingly, I don't get the warning that you do... which I do agree is likely the cause of the issue

[TheTechnobear]

ok, had a quick look....

so I think the issue is m_pd.h and probably sizes of types on AMD64?
its an old m_pd.h, so my guess is perhaps its not dealing with some new processors etc.

if we look at the code

t_int *rngs_tilde_render(t_int *w) {
    t_rngs_tilde *x = (t_rngs_tilde *) (w[1]);
    t_sample *in = (t_sample *) (w[2]);

so this is correct, in the sense that in points to t_samples (sample buffer)
w is just a vector of pointers...

the above is idiomatic of externals Ive seen before...

I think what we can do is:

a) m_pd.h
it could be worth trying a newer version of m_pd.h

b) check a current build of external.
perhaps the render function uses something a bit better than t_int to represent the points.
(void pointers would be better!)

if its crashing, Im guess that the size of t_int has changed, or rather its not he size of pointers.
so when we reference as an array it gets the wrong size, and so gets has the pointers for the input and output buffers.

that is my guess... I dont usually build on windows, so there could be something else going on.
but at least, if we looked at a pd external that was building and working on your platform this might give us a hint.

[TheTechnobear]

k, another look...

ok, in this area m_pd.h hasn't changed

void dsp_add(t_perfroutine f, int n, ...);

is the the same in 47 (older) and 51 (new)

the only assumption here is that an int, which is t_int is large enough to hold a point, which it should be as its a long!

I was wrong in last comment about array referencing being problematic, this is not true....
its getting a set of pointers, when dereferencing its offseting by a pointer size, not what its point to.
(so thats going to work fine)

I guess the code above, should probably be written as
t_rngs_tilde *x = static_cast<t_rngs_tilde*>((void*) w[1]); t_sample *in = static_cast<t_sample*>((void*) w[2]); t_sample *out = static_cast<t_sample*>((void*) w[3]); t_sample *aux = static_cast<t_sample*>((void*) w[4]);

but as you can see, all we are doing is casting away the warning...

note: this is all because PD what to essentially give you the ability to use the w array for what ever you want.

anyway, upshot is...

unless a long it not big enough to hold a pointer on your platform (which is a big surprise), then I think this might be a red-herring... and woud suspect it a build issue still.

[TheTechnobear]

BTW: I should point out, I dont really support this on desktop platforms.

really this was created for things like the rPI/Organelle... but I just shared it.

the issue is the MI code assumes a 48k sample rate - which is invariably wrong on a desktop.
to solve this you have to up/down sample from 48k to your host rate.

however, I did not want to include this, since it was not required for my purpose, and would potentially have a performance impact on the platforms i am targeting.

you could of course do this, by ensuring the up/down sample rate converter has zero impact IF the sample rates was 48k, but it just was not something I was using, and so particularly motivated to implement..

also I know building on things like Windows can be a pain at times ;).

[sidec]

if we look at the code

t_int *rngs_tilde_render(t_int *w) {
t_rngs_tilde *x = (t_rngs_tilde *) (w[1]);
t_sample *in = (t_sample *) (w[2]);
so this is correct, in the sense that in points to t_samples (sample buffer)
w is just a vector of pointers...

the above is idiomatic of externals Ive seen before...

Yes, I am not an expert in externals but from I know, this is idiomatic.

re: set(PD_CMAKE_PATH "C:/Program Files/Pd")
I would NOT want to include specific paths.. this is why I supply m_pd.h

Of course hardcoding paths is never good, this was just for sole purpose of ilustrating the thing. But also worth noting that win10 builds require some additional linking like here

why do you think you need?)
set(CMAKE_GENERATOR "Unix Makefiles" CACHE INTERNAL "" FORCE)

cmake on mingw defaults to generate Visual Studio project files, most likely you can simply set it with -G 'Unix Makefiles instead, but on my system I had somehow problem with it. This solution is from stackoverflow

Any way, as you mentioned/warned and I am fully aware of it, this external is not intended for desktop, and to be usable there it requres some more investigation. TBH I am good with vcvrack versions on desktop, but if someone really want it in Pd, your code is an exelent starting point.