Building uGens on Windows

Hi there SuperCollider Community, I am new here but a bin fan and long user of SC, I would like to ask. Has anyone had any luck building uGens on Windows? As far as I am aware this is undocumented in SuperCollider. I am trying to make a uGen that already builds and works on MacOsx but of course I would now like to use it on my Windows machine with fewer hardware restrictions. Unfortunately, Linux is not an option for this computer thanks to Nvidia not supporting drivers for my graphics card. So far I have tried to build the uGen using the CmakeLists.txt file in the Example Plugins directory (have also tried and failed to build the BoringMixer example) and as well tried to build using the sc3plugins CmakeLists.txt file. As mentioned, I have ruled out the issue being my code, as it builds and works on Mac, also the exact issue I’m having thus far (in windows) is not the generating of the .scx files but of them being recognized as valid by scsynth. They either behave as if they are not in the file path or scsynth shoots out an error that they are not valid 32 bit exe programs, I have tried on both 64bit and 32bit SC. Thank you to anyone who reads this and if someone can help me, thank you greatly in advance! S.

hi Sam!

you can’t take a binary you compiled on macOS and use it on Windows, they have completely different binary formats and require different system libraries. it is generally the case that you should not expect a binary compiled on one OS to work on another OS. most OS’s do provide compatibility for the same program to run on multiple versions of the same OS.

since every code project is different, there is no single way to build a UGen on Windows, or any other operating system for that matter.

have you tried compiling your project on Windows?

one note about asking for help on a programming forum, it goes a long way if you share what exactly you did and what exactly the result was. rather than saying “I tried [some process] and it failed,” it’s better to be specific and say "i installed xyz and ran make install but it printed error: file not found".

Hey, thank you for replying to my question. I meant to say that I have indeed built on both MacOsx successfully then built again on Windows unsuccessfully, apologies if I was unclear. You are right sorry for being not very helpful, here is what I have done specifically on Windows listed below.(My system is Windows 10 64bit, with an AMD processor.)

For the ‘Example Plugins’ attempt:

Get a copy of the plugin examples git clone https://github.com/supercollider/example-plugins
Get my SC source files git clone --recursive https://github.com/supercollider/supercollider.git
cd my/filepath/example-plugins
mkdir build && cd build
example-plugins/01a-BoringMixer/build/$ cmake -DSC_PATH=/path/to/my/sc3source/ ..
example-plugins/01a-BoringMixer/build/$ make
I then took the scx file put them with the class files and moved to the extensions folder. The result was simply that the uGen does not get recognized as valid but the class is recognised including the help file.

The SC3 Plugins build attempt:
I thought seeing as there is a note on the Example Plugins page saying " Currently, this build system is missing Windows. Sorry, we’re working on it…" I should try this way instead. What I did was the following:

Get my SC3Plugins Sourcegit clone --recursive https://github.com/supercollider/sc3-plugins.git
Get my SC source files git clone --recursive https://github.com/supercollider/supercollider.git
I moved the Boring-Mixer example to the directory of the uGens in SC3 source.
I then edited the ./Source/CmakeLists.txt to include it in the build. Then I did the following:
mkdir build && cd build
cmake -DSC_PATH=/path/to/my/copy/of/scsource/ -DCMAKE_BUILD_TYPE=Release -DSUPERNOVA=ON ..
cmake --build . --config Release
cmake --build . --config Release --target install

Some warnings to note:
The following are some notes on the errors I got for all build targets

After  ```cmake -DSC_PATH=/path/to/my/copy/of/scsource/ -DCMAKE_BUILD_TYPE=Release -DSUPERNOVA=ON ..```  the following error for all build targets 

```This warning is for project developers.  Use -Wno-dev to suppress it.
CMake Warning (dev) in source/CMakeLists.txt:
  Policy CMP0021 is not set: Fatal error on relative paths in
  INCLUDE_DIRECTORIES target property.  Run "cmake --help-policy CMP0021" for
  policy details.  Use the cmake_policy command to set the policy and
  suppress this warning.

  Found relative path while evaluating include directories of
  "HOAEncEigenMike2":

    "FFTW3F_INCLUDE_DIR-NOTFOUND"

CMake Generate step failed.  Build files cannot be regenerated correctly.```

After running ```cmake --build . --config Release``` there we lots of type conversion warnings, here is one example:

``` warning C4244: '=': conversion from
'double' to 'float', possible loss of data [C:\mymachinepath\buildUgen\sc3-plugins\build\source\complexRes.vcxproj```

After running ```cmake --build . --config Release --target install``` there were a few warnings relating to the ffttw3 library that was not found, they look like this:
```cmake --build . --config Release --target install```

Finally after putting the .scx files (build/source/release/) generated during the build into my SuperCollider Extensions folder I got the following errors on booting scsynth, one as an example:
```*** ERROR: LoadLibrary 'C:\ProgramData\SuperCollider\Extensions\Release\VOSIM_supernova.scx' err '%1 is not a valid Win32 application.```

Hope that is clear, its a issue probably mainly to do with my lack of experience doing this and hope to be able to build uGens (on Windows) in the future.

Which compiler are you using? Since “make” seems to work, I guess you’re using Msys2 or another MinGW flavour?

*** ERROR: LoadLibrary 'C:\ProgramData\SuperCollider\Extensions\Release\VOSIM_supernova.scx' err '%1 is not a valid Win32 application.

That’s strange… scsynth shouldn’t even attempt to load Supernova plugins. Or are you using Supernova on Windows? Which SuperCollider version do you use?

Hello, thanks for your reply. I am using the CMake 64 bit binary for windows accessed from here: https://cmake.org/download/. The error shows a supernova plugin but this is just a coincidence as I had the same errors for all the uGens in SC3 and just posted that as an example, I ran the SUPERNOVA=ON option during the build as it was recommended in the instructions. Could this be an issue? My version of SuperCollider is the latest version 64bit 3.11.1 , thanks for your help.

CMake is only used to generate the actual build system. But which build system and compiler do you use? Visual Studio or MinGW? If you didn’t specify manually, have a look at the build folder and check whether it contains a Visual Studio solution or a Makefile.

The last few Supercollider releases don’t support Supernova on Windows, so there’s no point in compiling with Supernova support.

Ok thank you, noted! It generates VS build solutions to answer your first question also.

The 3.12 release will have supernova on Windows! it’s already in the develop branch (so not 3.11.x)

1 Like

this is normal. scsynth needs to open every dll to check if it is a supernova or scsynth version. LoadLibrary is Windows equivalent of dlopen.

Sam, i would guess you have accidentally installed 32-bit SC and are trying to load a 64-bit plugin with it. that is the most reasonable explanation for the error message you saw about the plugin not being a valid Win32 application. i don’t normally work on Windows and i don’t know if there is an easier way to check whether an executable is 32 or 64 bit, but i found this article that lists a few methods: https://www.winhelponline.com/blog/find-out-if-a-program-exe-file-is-32-bit-or-64-bit/#headers

if that’s not the problem i’d be curious to see the entire build log for this plugin that doesn’t load, including output from the first cmake step.

i don’t know if there is an easier way to check whether an executable is 32 or 64 bit

I can recommend https://www.dependencywalker.com/. It is usually used to show the exported symbols of a DLL or list the dependencies of a given binary, but it also shows the architecture: if there is 64 next to the name, it’s a 64-bit binary, otherwise it’s a 32-bit binary. You can simply drag and drop scsynth.exe into the program.

For installed programs it’s actually easier: 32-bit programs live in Program Files (x86) and 64-bit programs live in Program Files. It is not mandatory, but every decent installer will do this, unless you change the install path manually.

1 Like

Hey, I tested scsynth in dependency walker and it is 64 bit. I have just attempted to build the example plugin Boring Mixer again and below is the process I went on, and the terminal output. This time make just doesn’t recognise a target, which reminded me that last time I opened the VS project solution and built the .scx using that, maybe (probably) why this was the first issue of just not being recognised as installed… This is separate from my attempt in building sc3plugins and the 32 bit warning.

From an empty directory I did this:
git clone --recursive https://github.com/supercollider/example-plugins.git
git clone --recursive https://github.com/supercollider/supercollider.git
example-plugins/01a-BoringMixer/$ mkdir build
example-plugins/01a-BoringMixer/$ cd build
example-plugins/01a-BoringMixer/build/$ cmake -DSC_PATH=/path/to/Mysc3source/ ..
cmake -DSC_PATH=C:\Users\username\Desktop\buildUgen\supercollider ..

TERMINAL OUTPUT:
– Building for: Visual Studio 15 2017
– Project name is BoringMixer
– Selecting Windows SDK version 10.0.17763.0 to target Windows 10.0.18362.
– The C compiler identification is MSVC 19.16.27031.1
– The CXX compiler identification is MSVC 19.16.27031.1
– Detecting C compiler ABI info
– Detecting C compiler ABI info - done
– Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.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:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe - skipped
– Detecting CXX compile features
– Detecting CXX compile features - done
– Configuring done
– Generating done
– Build files have been written to: C:/Users/USERNAME/Desktop/buildUgen/example-plugins/01a-BoringMixer/buildUgen

Then did this:
cmake -DCMAKE_BUILD_TYPE=DEBUG ..

TERMINAL OUTPUT:
– Project name is BoringMixer
– Selecting Windows SDK version 10.0.17763.0 to target Windows 10.0.18362.
– Configuring done
– Generating done
CMake Warning:
Manually-specified variables were not used by the project:

  CMAKE_BUILD_TYPE


  -- Build files have been written to: C:/Users/USERNAME/Desktop/buildUgen/example-plugins/01a-BoringMixer/build

I then ran make from the build directory as instructed via example plugins page:
make
TERMINAL OUTPUT:
make: *** No targets specified and no makefile found. Stop.

Thanks again for the patient help. (edit) here is also a screenshot of the build directory at the end. screencap

i haven’t built these plugins on Windows but make won’t work here because you aren’t using a makefile generator in cmake. the last command should be cmake --build . --config <config>, assuming this will build at all on Windows.

this is giving me motivation to polish the cookiecutter repository and archive example plugins. it’s confusing too many people.

Hey, thank you. I ran cmake --build . --config Release It built but now again the 32 bit error occurs.
*** ERROR: LoadLibrary 'C:\ProgramData\SuperCollider\Extensions\Custom\01a-BoringMixer\build\Release\BoringMixer.scx' err '%1 is not a valid Win32 application.
At least now it is a consistent error I guess.

Oh! It’s the opposite problem then, I would have thought 64bit applications can dynamically load 32bit ones but that’s apparently not the case according to stackoverflow. (https://stackoverflow.com/questions/2265023/load-32bit-dll-library-in-64bit-application#2265102) I’ve actually never thought to check this. Anyway, you need to compile these plugins for 64bit architecture. The easiest way to do that that I know of is to pass -A x64 during the first call to cmake.

Btw, I can tell you are compiling them as 32-bit because (1) i happen to know thats the default for MSVC generators and (2) your post above has this line which shows cmake finding the x86 (32 bit) toolchain:

– Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe - skipped

Hey! cmake -A x64 -DSC_PATH=C:\Users\USERNAME\Desktop\buildUgen\supercollider .. works… Thanks a lot. Off to make some uGens now :slight_smile:

1 Like

great! i will try to get this documentation improved