Plugin Development Tutorial - How do I run commands in Windows 11?

Development
1

In Windows 11 Canary using Powershell I tried running following the PluginDevelopmentTutorial. In the Rack folder when I run commands they do nothing. I can see [helper.py] is installed in the directory and have installed everything from ‘build VCV Rack on windows tutorial video’ below

export RACK_DIR=<C:\msys64\home\m\Rack> export
The term ‘export’ is not recognized as the name of a cmdlet

helper.py createplugin MyPlugin

The term ‘helper.py’ is not recognized as the name of a cmdlet

Suggestion [3,General]: The command [helper.py](javascript:void(0):wink: was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default. If you trust this command, instead type: “.[helper.py](javascript:void(0);)”. See “get-help about_Command_Precedence” for more details.

So I run .\helper.py createplugin MyPlugin and doesn’t do anything

Tutorial: build VCV Rack on windows

2

Since you have msys64 in this path I am going to assume you have that installed, in which case, you don’t use PowerShell, you need to run the MinGW64 terminal that was installed with MSys

Screenshot 2024-04-03 135103

1 Like
3

Also, that video is 6 years old, you should follow the official tutorial

2 Likes
4

I used MSYS64 but got nothing either so assumed I’d have to use Win terminal.

m@DESKTOP-UKRU3IM MINGW64 ~ $ cd rack

m@DESKTOP-UKRU3IM MINGW64 ~/rack $ export RACK_DIR=<C:\msys64\home\m\Rack>

-bash: syntax error near unexpected token `newline’

m@DESKTOP-UKRU3IM MINGW64 ~/rack $ helper.py createplugin MyPlugin

-bash: helper.py: command not found

Directory looks fine

m@DESKTOP-UKRU3IM MINGW64 ~/rack $ dir

CHANGELOG.md LICENSE-dist.md adapters dep.mk libRack.dll src Component.plist LICENSE.md arch.mk docs libRack.dll.a template.vcv Core.json Makefile autosave helper.py plugin.mk valgrind.supp Distribution.xml README.md build icon.icns plugins Entitlements.plist Rack.d cacert.pem icon.ico presets Info.plist Rack.exe compile.mk include res LICENSE-GPLv3.txt Rack.rc dep installer.nsi settings.json

5

Yes, this is the Development tutorial I have tried but the commands aren’t recognised using Win terminal or MSYS64, as post before. I managed to install all dependencies with MSYS64.

6

please use back ticks when you are posting code or terminal output, like this: ``` code ```

This error is telling you that it cannot find the filepath helper.py

I’d imagine this is either because you do not have the location of helper.py in your PATH (or it has not been updated for your current shell), or that you simply need to be more specific with calling the command, try:

./helper.py createplugin MyPlugin
7

what Dan said, and …

inside mingw, the export you want is not the DOS path. the root folder is C:\msys64 - and DOS \ is / in msys (if you wanted the full path, use /c/msys64/home/m/Rack)

export RACK_DIR=/home/m/Rack

then the following command will make sense:

$RACK_DIR/helper.py createplugin MyPlugin
2 Likes
8

I tried this but still get the same response as below:

EXPORT RACK_DIR=/home/m/Rack
-bash: EXPORT: command not found


$RACK_DIR/helper.py createplugin MyPlugin
-bash: helper.py: command not found

I have done everything on this page for dev environment, rack and plugins. This all worked fine.

I checked Python version and path:

$ python3 --version
Python 3.11.8

$ echo $PATH
/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
9

I tested, removed and reinstalled the symlinks with Sudo and now it works!

./helper.py createplugin MyPlugin

Create a new symlink:

sudo ln -s /usr/bin/python3 /usr/bin/python

remove unused or broken symlinks:

sudo rm /usr/bin/python
10

So, I created the Plugins/MyPlugin folder and ran

make -j 4
make install

$ dir
Makefile  build  dep  dist  plugin.dll  plugin.json  res  src

How do I open the example in VCVrack?

11

ah, my fault

export RACK_DIR=/home/m/Rack

export is lowercase

Q: “How do I open the example in VCVrack?”

A: If you built rack from source in /user/m/Rack, you would


cd /user/m/Rack
make run 

and find your plugin in the module browser.

I’m not sure where “make install” puts the plugin.

I haven’t much experience building plugins this way. I usually use the docker toolchain on linux.

12

make install is broken on Win11 if you’re using OneDrive. It copies to the wrong folder.

You can make dist then copy the .vcvplugin file from to the plugins folder manually.

I just got a mail saying it’s fixed in the next release of Rack. (They’re moving the plugins to appdata rather than in documents.)

1 Like
13

I previously posted about this bug, with a ‘fix’ for the makefile that works well for English Windows, but not right for users where the “Documents” folder is localized.

For serious plugin development I recommend cloning and building Rack and at least Fundamental alongside your plugin. This allows debugging into Rack source, and ready access to the full Rack source code, which is necessary once you get beyond the raw basics.

Helper.py is only useful the first time, but quickly becomes unmanageable for iterating on a module’s design. You will soon need to learn how to edit svgs and reposition controls to match manually or via other methods.

14

This is very good advice.

15

Oh that’s a good move! The number of OneDrive support requests are beyond repair. Windows is so seriously buggered at the low level it boggles the mind :roll_eyes:

16

The only issue I’ve ever experienced with OneDrive and Rack is with make install. I do see lots of blame put on OneDrive and Windows for a variety of issues, without supporting evidence.

There is a lot of open-source software that is broken in various ways on Windows because of assumptions that aren’t valid on Windows, or trying things assuming that every OS works like Linux, or other mistakes out of ignorance or lack of concern for users.

For example there are quite a few plugins that are broken on Windows for users with non-Latin1 user names, mostly from using “cross-platform” libraries that are simply broken on moany Windows installs. Luckily there’s now a decent workaround for that, but it has a (lowish) risk of breaking other programs.