Could Someone Give me Advice on Developing Modules for VCV Rack?

Development
1

Hello there,

I am excited to dive into module development for VCV Rack and would greatly appreciate some guidance from experienced developers here. I am relatively new to plugin development.

I have few queries in my mind related to this like;

What is the recommended development environment for creating modules? Are there any specific IDEs, compilers, or libraries that are commonly used and recommended for VCV Rack development?

Are there any best practices or recommended architectures for designing VCV Rack modules? I am particularly interested in understanding how to structure my code for efficiency and compatibility with the VCV Rack ecosystem.

What approaches do you recommend for testing and debugging modules? Are there any tools or techniques that have proven particularly useful for ensuring the reliability and stability of modules?

Also, I have taken help from this: https://community.vcvrack.com/t/getting-started-with-development/8469sap which definitely helped me out a lot.

Apart from this forum, are there any other resources or communities you would recommend for someone starting out in VCV Rack development? I’m eager to learn from others; experiences and contribute to the VCV Rack ecosystem.

I am grateful for any advice or assistance you can provide.

Thank you in advance for your time and support.

1 Like
2

I think most of us use very simple tools. some bash shell for building, some editor (usually Visual Studio Code) for editing. Some people go to lengths to get visual studio or c lion or some other IDE working, but I think that’s uncommon. Most of us build and debug from the command line, just like the VCV documentation suggests.

1 Like
3

I started here:

I develop on Windows using Notepad++ and MSYS2, and Inkscape for graphics. That’s all :sunglasses:

4

Notepad++, MSYS2, and Inkscape for me too.

Best advice I can give is to grab the source for the VCV Free modules (AKA Fundamental and figure out how they work.

The developers here are very friendly and generally pretty quick to answer questions but a quick search before you ask may give you what you’re looking for before opening it up to the wider community.

3 Likes
5

this maybe helps your serch in the youtube channel of VULT there is several info about Slds

6

:face_with_peeking_eye: Dangerous questions there… image

Joking aside, there are no standards, only personal preferences (which may, or may not, have good reasons).

My personal preference is; I develop on my main Windows 11 PC, I use MSys2 as detailed in the VCV Dev guide, I edit in Visual Studio Code with some C++ extensions, I also use the VSCode terminal to test and build my plugin, I have previously used InkScape and Adobe Illustrator for panels but currently make my panels programmatically, and of course my code all lives in a GitHub repository, this also means my plugin manual is hosted for free on GitHub.

My advice here would be to ignore this initially, just build a few modules for yourself and get them working how you want, that will give you some experience which you can then use to make decisions on code structure. When I first started coding my plugin, I did everything in the module file, and shared nothing, as I didn’t know what would need to be reused. As I created new modules it became obvious what code needed to be factored out into shared files.

I did buy this book a few years back and it helped me, but it is fairly out of date now so might not be the best recommendation anymore

I am considering buying this book

Good luck

7

I’m also very new to developing on VCV. I started making myself a bit of a bullet point list of tips for developing in VCV rack as I make mistakes. It’s just a starting point really, but these are a few things I learned while making my first couple of modules. I’m sure the community here could add like 100 more things to the list.

  1. Avoid Dynamic Memory Allocation:
  • Use statically defined arrays or member variables instead of dynamic memory to avoid memory leaks and fragmentation in real-time DSP environments.
  1. Initialize All Variables:
  • Properly initialize all variables before use to prevent undefined behaviors that could lead to crashes or erratic behavior across different platforms.
  1. Avoid Static Variables:
  • Do not use static variables within module classes. Static variables shared across multiple instances can lead to unexpected behavior and data conflicts.
  1. Use Safe Pointer Practices:
  • Ensure pointers are initialized to valid addresses before use and check for nullptr before dereferencing to prevent crashes.
  1. Floating Point Safety:
  • Protect against division by zero and ensure floating-point operations are safe. Use functions like fmax() or std::max() to establish safe minimum values.
  1. Efficient GUI Updates:
  • Limit updates of display items like lights or text to 30-60 frames per second to avoid excessive CPU usage. This can be managed by only updating these elements when necessary and not in every single process loop iteration.
2 Likes
8

oh, right, graphics.

I used to use Adobe Illustrator, now I use AdobeXD. I looked at Inkscape - it looks pretty bad, so I didn’t want to put a lot of time into learning it.

Also, while you might use helper.py to make your first module, you will soon find that workflow is too restrictive and janky. I think the huge majority modules in the library were not developed with helper.py.

As you can see, different devs do panel controls different ways. I think it’s safe to say that most at least start with the widgets that are built into the SDK. Some people then go all code, most don’t is my guess.

9

I highly recommend cloning Rack and building it from source, rather than using the SDK. Also clone Fundamental, and other open source modules you use frequently. Plugin sources, including your own should be under the cloned Rack source plugins folder.

Doing this lets you see good examples of how things are done, and lets you step through Rack code to see how Rack interacts with your module. Stepping through in the debugger is a great way to observe what Rack and your code actually does.

Lots of us use VS Code, and searching here will have a number of posts that give a number of ways to set up building and debugging for your host environment.

(Optional) I modify Rack/compile.mk to turn off optimizations to make it easier to step into Rack code in the debugger, as follows:

#FLAGS += -O3 -funsafe-math-optimizations -fno-omit-frame-pointer
FLAGS += -funsafe-math-optimizations -fno-omit-frame-pointer

This requires a modification to Rack/dep/oui-blendish/blendish.c (line 64):

    //#define BND_INLINE inline
    #define BND_INLINE static

For debugging in VSCode it can be useful to see the Rack logs in the embedded console, which on Windows may require this change in Rack/Makefile for STANDALONE_LDFLAGS:

ifdef ARCH_WIN
	STANDALONE_TARGET := Rack.exe
	# STANDALONE_LDFLAGS += -mwindows
	STANDALONE_LDFLAGS += -mconsole

Until Rack 2.5x is released, make install is broken on Windows with OneDrive. This change in Rack/plugin.mk (line 46) works around the issue:

ifdef ARCH_WIN
	TARGET := $(TARGET).dll
	LDFLAGS += -static-libstdc++
	ifdef OneDrive
		RACK_USER_DIR ?= $(OneDrive)/Documents/Rack2
	else
		RACK_USER_DIR ?= $(USERPROFILE)/Documents/Rack2
	endif
endif

If you’re on a non-English machine, replace Documents with the localized name of the docs older.

Other notes

  • Squinky has some great docs on antialiasing, and other DSP and plugin development and in his repo. See the thread at Help dealing with Aliasing? for references.

  • The Rack tutorial has you use helper.py, which others have warned about. It’s only good for boostrapping the first time, and you really can’t use it for continued development when you need to change your UI. Using my template repo might be an easier place to start:

    See Paul-Dempsey/GenericBlank: Template for a VCV Rack Blank module (github.com).

  • px vs mm: Might want to search on the topic of which units to use when designing your UI. The tutorial recommends mm and conversion in code, but in practice most of us use px. IMO the only reason to use mm is when you’re faithfully cloning a hardware module that uses mm in its design spec.

  • Case. Take care with the letter case of filenames, both on disk and referenced from code and makefiles. Make sure to match case exactly. If you’re developing on Windows, case mismatches will go unnoticed, but your plugin will have issues on Mac and Linux.

  • There are a few other common pitfalls and stumbling blocks that every new developer faces. If you run into something that’s taking a long time to figure out, search here and if you don’t find a solution, reach out here or on the VCV Discord. This is a friendly and helpful community.

3 Likes
10

Excellent advice. For sure build rack and fundamentals yourself. And unless you are perfect, you will mix up case, so for sure have a Linux system or vm just to find it when you make that mistake. Oh, and don’t call your GitHub repo “vcv stuff”, use some name unique to you.

11

This is all great advice

The best way to avoid frustration is before you even write your first module make sure you can build some known to work plugin and make a change in it and see that change. Then make it print and see the statement in the log or console. Then see if you can attach a debugger. Then once that’s done make another change and see how long it is between pressing build and being able to test the change

If the press build to see change time is long you will be sad when iterating in your module.

For my modules I use a bit of a different setup which I don’t recommend for a newcomer but that “press build and run in my ide to see rack with my module loaded” is a sub 5 second operation for me and that’s super important to productivity

Oh and finally have fun. Modules people liked writing are modules people like using!

1 Like
12

LOL - I hardly ever run my plugin. just edit, build unit tests, run. Takes a fraction of a second :wink:

13

My GenericBlank template repo gives you that minimal running module to start from.

2 Likes
14

Yeah I started with working dsp so the entire rack project is rack plumbing and ui. If that’s not the case then your mileage may vary of course.

15

yeah, I discovered long ago that if I didn’t make unit tests for my DSP that… it would usually not work. In really terrible ways. Like flipping all the floats in an sse backwards. Or filters whose corner freq was off by a factor of 2*pi, or worse bugs… It’s amazing what your ears can ignore when you are coding away…

16

I agree. For me voice management tests weee the most useful, and microtuning, but indeed nothing beats a good regtest under the module.

1 Like