Module development template

Development
1

Hey folks, I am new to module development. Is there a good module template that someone could point me to that would be a good starting point.

Thanks, Anthony

2

The documented process in the manual will work. I don’t really like it, because I am superstitious and don’t believe in code-gen.

I have a very simple example (and some good documents) in this repo: GitHub - squinkylabs/Demo: A collection of code and articles of interest to VCV users and developers.

There are other things around on github, don’t know much about them.

1 Like
3

@Squinky has a repo with a demo plugin with some basic modules, and a full-on readme full of information on getting started.

the full repo is here:

and this is the readme that should at least give you some info on getting started:

1 Like
4

lol beat me to it

1 Like
5

I agree with Squinky that the Rack tutorial leads you down an unsustainable path, especially in regards to UI development and maintenance. So I created a Rack plugin template that IMO puts you in a better place to evolve from.

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

This is the bare-bones absolute minimum of a loadable module with an SVG panel.

This is blank plugin template to start with so that you can first work out the basics of building and getting a plugin to load. You can use the github features to create your own repo from this template to bootstrap yourself. It comes with documentation for getting started. This module has no inputs, outputs, or do any DSP, but there are commented placeholders for the framework you need to add these features.

Once you have the business of building, loading, and debugging out of the way, you’re ready for I/O and DSP, and the Squinky repo is a great place for learning these aspects.

3 Likes
6

this comment in your blank template is kind of blowing my mind right now. this concept never once even occurred to me before.

// To save precious CPU, many modules will process parameter changes at 
// a slower rate than the audio rate.
//
// This example shows a simple parameter update rate of 1/64th the sample rate.
// You can use a ::rack::dsp::timer to update relative to clock time, rather
// than change based on sample rate.

i think i might need to try this out myself. :thinking:

7

You should read my ancient paper on efficient plugins. It talked about this. The plugins in my demo repo do this.

1 Like
8

huh. i never noticed before. will look more into that for sure.

9

It’s in there, but a bit subtle.

10

I first came across this separation of control-rate and audio-rate signals in the Music N family of languages by Max Matthews (after whom Cycling ’74’s Max is named).

1 Like
11

well, “back in the day” everyone processed CV at less than audio rate. You had to.

12

Yep, me included (and no doubt a lot of other people here) :wink:

1 Like
13

In the Voyetra-8 I processed everything at 1khz, and it still could bog down that 2 Mhz 6502 CPU… And we walked to school in the snow…

3 Likes
14

They made them tough in those days aye Bruce? :laughing:

3 Likes
15

Really nice!

In Blank.cpp you have an off-by-1 error in “if (++check_params > PARAM_INTERVAL)”. Either “if (++check_params >= PARAM_INTERVAL)” or “if (++check_params > PARAM_INTERVAL -1)” will do, depending on what’s fastest if you wanna get real nanosecond about it :slight_smile:

Or you could have the two assignments be “check_params = 1” instead, that would be cheapest.

1 Like