take your gen~ patches direct to @vcvrack

This looks interesting.


That does look pretty cool.

It says parameters and associated CV are processed at “block rate”. Wonder what that is?

I’m not a developer, but I’ve found this in the Max documentation: The DSP Status Window lets you control the size of the blocks of samples (called signal vectors) that MSP uses. There are two vector sizes you can control.

  • The I/O Vector Size (I/O stands for input/output) controls the number of samples that are transferred to and from the audio interface at one time.
  • The Signal Vector Size sets the number of samples that are calculated by MSP objects at one time. This can be less than or equal to the I/O Vector Size, but not more. If the Signal Vector Size is less than the I/O Vector Size, MSP calculates two or more signal vectors in succession for each I/O vector that needs to be calculated. With an I/O vector size of 256, and a sampling rate of 44.1 kHz, MSP calculates about 5.8 milliseconds of audio data at a time.

I have a MOD duo and the SHIRO plugins (made with gen~) are pretty impressive. Sadly, I think they are not open source.


Hi there! I’m the developer of this project. Cabotage_KSM is correct with his links.

Basically, gen~ exports are designed for block processing. Parameters in gen~ are updated at block-rate while audio inlets are at a per-sample rate.

1 Like

What is the block rate? (numerically, that is. Is it adjustable? Fixed? Fixed division of auto rate?

It’s fixed and in units of samples. You can configure it in the right click menu of the module that’s built. The options are 1, 4, 16, 32, 64, 128, 256, 512, 1024, or 2048.

ah, nice. Since most VCV modules use 1 (or 4 if they are mine) do these relatively small values work work well (cpu usage is reasonable)?

Yup! Most of the tests I did (using a reverb processor, so, fairly heavy processing-wise, but it was a gigaverb, so nothing too crazy :slight_smile:) were around 10% CPU for blocks of size 1. It dropped down to ~1% at 16-sample blocks.

As a bit of explanation, basically the whole per-block distinction arises as a result of [gen~]'s distinction between audio inputs and parameter inputs. Audio inputs are processed every sample and parameter ones happen every block. You can have an arbitrary number of either audio or parameter inputs, so you can just pick which ones you want to update every sample vs. every block. It’s (closely, but not completely) analagous to the decision you make when you split out pieces in your modules to process every x number of samples. I hope that makes sense! It’s definitely more obvious if you’re used to the Max/MSP/Jitter/gen world.

Well, it makes sense to me because this distinction is ancient - I think things like Music V had this distinction. I remember controversy about whether ADSR updates at Fs/16 were “good enough”. One of the innovations of VCV is that it truly runs everything on every sample, so VCV makes no distinction between audio and CV.

1 Like

This seems like the kind of thing create digital music would cover. have you mentioned it to them?