New Dev — Where do I even start?

Development
1

Hi friends, I’m Wyatt. I’m a 3rd Year Electrical Engineering and last semester Audio Production Technologies student. I started with VCV Rack 2 last year because of an electronic music class I took, and absolutely fell in love with it. I’ve now gotten to the point where I want to make my own modules for my compositions. Here’s where the one million questions come in… :

There seems to be a million resources out there from different people at different times giving their opinions on the best workflow and development strategies, but no matter what I follow, I seem stuck at step one (maybe even zero). I first followed the official VCV development guide, but felt a lack of clarity, especially with the transition between plugin to module and the SVG blank that feels kinda slid in there. I followed the Medium article about setting up VSCode for a smoother experience with development, but it seems that the tutorial is just a bit out of date, especially now that intellisense has been replaced by Copilot (yuk.) and that one also gets complicated fast. I’ve been recommended a book too (Developing Virtual Synthesizers with VCV Rack by Leonardo Gabrielli) which seems extremely promising! I just lack the funds at the moment.

All in all, I just feel like there’s an overflow of information, but I’m primarily getting stuck with where the hell this SVG stuff comes in. Can I code the plugin/module without it? Cause it doesn’t seem like I can if I use helper.py. Speaking of, I’ve seen people dogging on using helper.py but I’m unsure of how to not use it. I tried using Inkscape and SynthPanelsDesigner, which was cool, but kept crashing.

I apologize for my first post being so long winded, but I trust that this community can help me in my endeavors.

TLDR; I find the development tutorials given a bit confusing, and it would be great if you wonderful devs could point me in the best direction to learn what I need to and get making modules. Useful info: your IDE of choice, what sources you used to get started, any other general tips for traversing the creation process.

Thanks all!

Wyatt

2 Likes
2

Useable modules are comprised of two different things: the module logic itself and a module widget.

The logic takes care of processing IO, producing audio, controlling lights… it drives whatever your module is supposed to do. To use a videogame analogy, this part would be the one that handles what Mario is supposed to do when he jumps.

The widget handles what the module looks like: where controls are placed and their visual representation, IO ports, the position and kind of lights your module handles; displays, etc; to continue with the videogame analogy, the widget takes care of how Mario looks when he’s jumping.

Now SVG files…

SVG files can be the backplates for your module; backplates are needed to set the size of modules.

SVGs can also be used to draw components such as jacks, knobs, buttons…

That said, some developers draw the backplate and components in code without using SVG files or use a combination of svgs + code.

You can code the module’s logic without the SVG or without coding the backplate’s drawing code; once that is done, some sort of backplate, either drawn or coded, is needed for the module to be actually used inside Rack (unless you want your components flying everywhere; your lights looking like eerie colored ghosts, and to, probably, make the module browser kind of unusable).

An SVG is an image comprised of vectors (unlike a bitmap, which is comprised of pixels); but also has a width and a height; the manual for Rack includes the specs for the backplate’s height; width is calculated in HP; 1 HP = 5.08 millimeters, so you can draw your backplate using Inkscape or other programs capable of saving files as SVG, whichever you are comfortable with, as long as you follow the spec. I don’t know what the HP limits are for Rack; but some modules are quite wide!

You can skip the helper script; but you have to set your backplate by hand and place your components manually as well (not a complicated endeavor); but you’ll probably end up rolling an automation solution that works for you after a while, if you keep developing modules, because, well, it can get tedious, more than anything, after making a few.

There’s a good alternative tutorial here, you may find it useful:

My current IDE of choice is Visual Studio Code (all the AI stuff can be disabled; the annoying and privacy invading telemetry can be turned off as well); why use it? Because it works well with Rack sources, unlike every other IDE I tried (Eclipse, Visual Studio and Code:Blocks) and has some useful extensions for my workflow; as for sources… I read the official manual and looked at code for open source modules, such as Audible Instruments and Befaco. I don’t recommend my own sources in this case because the part you are getting stuck on (the SVG stuff), when it comes to my modules, is not at all conducive to learning how to do it.

4 Likes
3

I started out using Paul’s generic panel, as @Bloodbat already linked to, and worked out from that (started to add input/output-ports and knobs). Browsing from the VCV library you can find links to multiple GitHub project so you can see how others are building panels (e.g. how ports/knobs are added, and used).

I was already proficient using SVG, when I started out, however the Developer information provided described the size of panels in mm, and I couldn’t get it working. So the link below is the reply I got as how to scale the SVG panels using pixel instead (15 pixel for each HP in width, and 380 pixel high):

Scaling-of-rack-controls-in-svg

1 Like
4

I have this book, it is a good resource, especially for the DSP stuff, but it is substantially out of date now. Potentially even a hindrance to someone new to rack dev.

If you are not adverse to using AI, rather than just using a coding agent, you could try making a reference using https://notebooklm.google/ (plenty of tutorials online for this, but essentially you would paste in all the tutorials and weblinks to reference material, and then you can create your own tutorials on specific topics, or drill down into certain areas that you want to understand better).

The other route I would suggest is to just go ahead and write some code. Your first module is probably not one you will end up releasing to the library, at least not until after a lot of rework. So it doesn’t really matter if it builds cross platform, or if it has edge case crashes…

If its not going to the library then there is no consequence for making mistakes, and that is a fertile learning environment.

I also use VSC as my main editor, I have an unfinished guide that might have some tips for you GitHub - Miff-Real/vcv-dev-dant-method · GitHub

and I have an open source plugin that has an annotated module that draws the panel with code, not using SVGs DanT.Synth/src/modules/aocr.cpp at main · Miff-Real/DanT.Synth · GitHub

Let us know how you are getting on, good luck on your dev journey

3 Likes
5

Thank you all for your help and advice! You guys all gave great resources and notes for me.

I think I’m just going to start with the Vult Language in VSCode, creating some sort of simple utility. Right now I’m thinking of something that’ll take a clock pulse input, a cue button/cv input, and a “beats” knob parameter, and once cue is pressed, it will countdown each beat before sending a +10.0v trigger out — just a simple something that can help me cue different parts of my arrangements better rather than trying my hardest to start them on time.

1 Like
6

Not here to stop you from developing, just to inform you of 2 modules.

and

7

Aw damn! Haha. That first one is pretty much exactly what I was thinking. I really like Martin’s execution, but I have some slightly different ideas, so I may still try and make my own for practice. Thanks for letting me know!

1 Like
8

i also built two modules to help me do this

and

Building a module that solves an actual issue you have is a great way to teach yourself how things work and how you like features to work…

Don’t fall in love with your first design, evolve it

9

Another good practice is: build the module you want in a patch out of existing modules. Then make a design to incorporate that all in to a single module.

That’s how i do a lot of my module designs, if i find myself making the same connections in multiple patches, is it worth making a single module to do that thing?