Some patches run great at lower buffer/latency settings, others can only run at higher buffer settings. Could be nice to have a way to specify ‘ideal buffer/rate setting’ within the yml of a patch that temporarily changes the system settings right when that patch is loaded, so that if anybody tries out a shared new a hoggy patch that runs best on 128-512, they won’t ever have any issue just loading and running it. Or they won’t have to go to their system settings and change the buffer manually to something other than what they normally leave it set on, just to be able to run a single patch, and then have to change their system setting back to whatever their normal preferred buffer/rate setting is when they are done with the patch. An override setting like this would really come in handy down the road once a plethora of patches are shared, to ensure things should run ok across the board for everyone.
One idea: perhaps on the metamodule in vcv there could be a right-click setting to specify the ideal override buffer/sample rate to be saved within the yml (with a default ‘none’ option that just uses main system setting on mm)?
Another (maybe easier?) idea: perhaps a way(system pref?) for the mm to just automatically temporarily adjust the buffer to 512 if it detects that a patch is hoggy
3 Likes
or… could be nice(easier to implement?) to just be able to specify the “rate/buffer” in the first line of the description of a patch: e.g. user just types “32/512” first line of description. and the system will set itself accordingly right before the patch plays (and reset back to user’s default when another patch is loaded that doesn’t have any rate/buffer typed out in the patch’s description area)
1 Like
+++1 for this. This is really a must have feature.
We could also imagine to have the possibility to give these specifications within the patch setting in the MM with a “SAME AS DEFAULT” (system settings) option.
1 Like
where do you change the buffer and rate settings please?
Settings > Prefs
The top section is titled “Audio Settings”
Under that heading is the ability to change the Sample Rate and Block Size. I believe those are the options that the OP is calling Buffer and Rate.
Thanks!
Settings in VCV Rack or Meta Module? I’m on Mac and the only setting I see is Engine->Sample Rate in VCV Rack and no Prefs or Audio settings in either MM or VCV.
In the Meta Module itself. When you start the MM, the first thing you see is “Load Patch”, “New Patch” and “Settings”. Click “Settings” and that will bring up a page with a sidebar on the left. Prefs is the third item down in that sidebar. (further down that sidebar is “Update” where you navigate to update the firmware on the MM).
Currently the Sample Rate and Block Size are specific to the device, not a specific patch. If you have a patch that cannot run within the default values of 48K/64, you have to back out of the patch, access the device system settings and manually change sample rate and block size. The requested change is for a patch to be able to specify a sample rate and block size to the device so that it does not require manually changing those values before loading the patch.
1 Like
I really appreciate the info! I don’t know how I didn’t see that!
I also appreciate the additional information. Super helpful.
My VCV Rack 2’s sample rate is 44K. Should I change it to 48K?
I changed MM to 24K/512 and now I can run Blippoo Box 
I suggest to show the current bit/sample rates at the top of any patch, i.e. like a system setting (maybe top left?). Also two little LEDs to show MIDI in/out activity too.
midi in out indicators would definitely be useful! perhaps a new feature request for that (otherwise it might get lost in this thread)
I think the screen is small enough that Id not want to “clutter” it with more details.
however, I do think have a midi monitor screen would be in the settings.
as per OP, definitely useful to have per patch sample rate/buffer.
that said, I think care has to be taken in this area, making it ‘normal’ for users to start changing the SR/buf size - creates complications, and possible support implications (SR specific behaviour of a module) , esp for new users (to the MM).