it’s a posthumously released Douglas Adams book, funnily enough it can also cure light wounds
1 Like
Looking good, friend.
1 Like
Quick demo! A mix of sample loops and single drum samples:
In order to achieve this, you need to choose loops that match the BPM of the clock. Also, this is my new YouTube Channel. 
10 Likes
Wow, that’s massive. I didn’t even realize you could use longer loops and such instead of just one-shots. Can’t wait for this one!
I noticed the param knobs start out at the correct initial value but when you double click them they go to a value of 0.
Hi Bret,
any chance to get an updated beta binary for Win?
I added this as a bug and will get it fixed if possible!
1 Like
Sure! Here you go: voxglitch-2.12.0-win.vcvplugin - Google Drive
I’ve submitted the module to the library and it should be launching soon.
3 Likes
thx Bret I’ll test it asap.
may it be a real success once it’s up in the library, it really deserves it.
That’s really nice of you to say, Stephan!
Although the front panel is “satisfactory”, I’m still hoping to give it a big visual upgrade eventually! I’m also working on implementing linear (or better) interpolation for all of my sample based modules to improve the audio quality. 
1 Like
don’t all (ParamWidget) controls go to their default value when you double click on them?
True, true. However, the knobs on the groovebox module change behavior depending on which “parameter lock” you select.
For example, when the “Volume” parameter lock is selected, the default position is 50%. But the “Loop” default position is at 0.
I’ll need to say…
If the knob is double clicked, then set it to the default for the selected parameter lock.
I know that one solution might be to store pointers to the knobs when they’re instantiated, then manipulate … (something, I’m not sure what), when the parameter locks are selected. I haven’t gotten that far yet. 
oh, I see. Good luck!
I’m not sure if it’s the right call for your module, but I just want to point out that one option here is to make an entirely separate ParamWidget for each “mode” of a particular knob and then hide all those widgets except the ones which correspond to the selected parameter locks.
This is the same technique that Audible Instruments uses for the different modes of the Blend knob on Clouds:
An interesting side effect is that this allows each “knob mode” to be separately and simultaneously MIDI mapped (if mapped, you can still adjust a parameter even if it is hidden). It gives each “mode” its own discrete memory so that each mode’s knob will stay where it was left when the mode is switched, and JSON serialization of each mode’s state comes for free. It also makes it easy for each “knob mode” to behave differently WRT reset behavior, tooltips, max/min values, display values, etc.
My module Algomorph Advance appears to have only two knobs, but if you check the code there are actually 14. 
5 Likes
I’ve been thinking about submitting a formal VCV support request for new standard parameter context menu features/options
- Set Default - set current parameter value as the default
- Restore Factory Default - restore the default value to the originally “shipped” value
I think such a feature would be a welcome live performance aid.
I suppose a logical extension to this is new API function to set the parameter default (assuming it does not exist all ready - I’ve never developed a module) That ought to be helpful for your multiple mode issue.
Though the @xandra-max suggestion of multiple widgets, one for each mode, is appealing. That combined with the addition of user set defaults would be really cool - each mode could have its own user defined default.
1 Like
Yes!!
Now that is a great side-effect, midi mapping!
1 Like
1 Like
That’s brilliant! What a neat solution. I’ll try to make that happen!
3 Likes
They are totally different
- The template affects the starting “state” of all newly placed modules. My idea is to allow setting the default for a single parameter on a single instance of a module within a patch.
- Once placed, the template has no further impact - it does not change the default setting for any of the paramters (does not affect the result of double click on a knob for example)
I envision being able to build a patch with various knobs, sliders, whatever, set to my “default” values that sound good to my ears. During a performance I might want to twiddle a knob to get some variation, but I’d like to be able to quickly and reliably restore a given knob to my “default” starting point.
I realize there are Stoermelder modules that could help (in fact they are much more powerful than my simple request). But I think it would be nice if every control had a built in behavior that allowed the user to set what the double click default value is on a per instance basis.
But this is way off topic. What I think is relevant - there could be an API call that allows module code to set the default value for a given knob, which would be useful for any module that has controls with different modes. I think instantiating multiple controls, one for each mode, with all hidden but the active mode, is a great solution. But it is kind of a heavy handed approach if all you need is the ability to change the default.
In my mind, such an API call and letting a user define the default are closely related.
1 Like