Building uGens on Windows

Development Server plugins
1

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.

2

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".

3

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.

4

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?

5

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.

6

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.

7

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

8

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

9

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

1 Like
10

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: How to Check if a Program (.EXE or .DLL) is 32-bit or 64-bit Ā» Winhelponline

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.

11

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
12

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

13

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.

14

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

15

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.

16

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
17

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

2 Likes
18

great! i will try to get this documentation improved

20

Thanks a lot all of you! Finally I can compile on Windows 10.

@VIRTUALDOG the cookie-cutter is not supposed to work under windows, right? Iā€™ve tried to use it but it seems that the diference between \ and / on Unix vs Windows is messing all the process. Is it possible to tweak it somehow for this ?

Instead of compiling directly from Win10, wouldnā€™t it be easier to cross compile using a linux virtual machine on windows ? Is there a recipe for that? Iā€™ve tried to follow some steps from here Tutorial: SuperCollider server plugins in C++ but could manage to the exact commands for cross compilationā€¦

21

For those begging in this journey, these are the steps:

(When installing below make sure that you add CMake and GIT to your system PATH for your user)

Download and install CMake
Download and install GIT

Create a desktop folder called MyUgens

Open terminal and type

cd C:\Users\YourUserName\Desktop\MyUgens

Now you will download the folder with example plugins and the SuperColliderā€™s source code (which will provide an API and components for your homemade building process)

git clone --recursive https://github.com/supercollider/example-plugins.git
git clone --recursive https://github.com/supercollider/supercollider.git

Move to the directory of the plugin that you want to compile:

cd C:\Users\YourUserName\Desktop\MyUgens\example-plugins\01a-BoringMixer

Create a build folder and move to there:

mkdir build
cd build

Set the flags for cmake Modify the user name to access SCā€™s source code folder :

cmake -A x64 -DSC_PATH=C:\Users\YourUserName\Desktop\MyUgens\SuperCollider ..

More cmake options:
cmake -DCMAKE_BUILD_TYPE=DEBUG ..

Compile:
cmake --build . --config Release

This will output a .scx file at C:\Users\YourUserName\Desktop\MyUgens\example-plugins\01a-BoringMixer\build\Release

Now you need to copy 01a-BoringMixer.sc, 01a-BoringMixer.scx and 01a-BoringMixer.schelp into a folder
of your Platform.userExtesionDir, which is generally:

C:\Users\YourUserName\AppData\Local\SuperCollider\Extensions

Go to SuperCollider, recompile the class library, boot the server and test your UGen

2 Likes