I’m starting a development thread for the ongoing work with Befaco (distinct from the announcements thread which is just for release updates), I hope this makes sense. This thread will be more for technical details and feedback from beta testers.
Since the last release (Percall, Kickall, Hexmix, Chopping Kinky), I’ve been working hard to bring the next batch of modules to VCV rack. This upcoming release (v.1.2.0) should see:
Muxlicer (and special friend!?!)
Morphader
STMix
VC ADSR
Sampling Modulator
join the ranks. You can follow the release progress on the github issue here.
I’d like to spend a bit longer with the modules in beta than last time in order to stress-test / catch as much as possible, but they will hopefully end up in the library before too long. The most recent dev build can be found here.
If you are interested, please take a look, and let me know if you have any feedback (either in this thread, or on the github issue). I’m particularly keen on checking things like polyphony (Muxlicer/Morphader/STMix), or anti-aliasing (Sampling Modulator) are done correctly. I’ve also created a “Differences from hardware” section in the readme.
Finally, here’s a little preview video of a few of the new modules in action:
I am hoping for @Squinky keen eye tbh , it’s a little hard to know how best to handle anti-aliasing in a module that is effectively a Sample Rate reducer. I’ve gone for the MinBlep implementation on Clock / Trigger out (with DC removal), and minBlep for the “Out” of S&H, but I’m not 100% sure what exactly is best to do there (it should sound “clangorous”).
I don’t know it there s a good answer for that. If it doesn’t alias, then it’s just a low pass filter. Sure glad you are paying attention to dc offset!
It’s an amazing module, but the hardware has things that are tricky-to-impossible in software (various things like “push and twist” vs “twist” for different knob functions, momentary switches, and 8-to-1 vs 1-to-8 for the switch).
Hopefully I’ve managed to stick to the spirit of the original with my compromises!
Let’s stop with the jabs all around. I assure you that Bruce is not the only one who cares about low aliasing, or sound quality in general. Each to their own and there’s plenty of room for all our different concerns and priorities.
" * The hardware Muxlicer assigns multiple functions to the “Speed Div/Mult” dial, that cannot be reproduced with a single mouse click. Some of these have been moved to the context menu, specifically: quadratic gates, the “All In” normalled voltage, and the input/output clock division/mult. The “Speed Div/Mult” dial remains only as a tap-tempo button."
Totally understand why some interface elements need to be treated differently in VCV and just a thought but could the “Speed Div/Mult” dial not act as both a ‘tap tempo button’ (when clicked) and ‘input/output clock division/mult’ when the dial is turned (click/hold/move)?
For “push and twist” vs “twist” for different knob functions mentioned above - perhaps you could use a keyboard modifier like alt/option to be the ‘push’ part of “push and twist” (if you have not solved that in another way already). Sometimes it can be good to have both a context menu way of doing things (for visibility when people are new to the module) and a keyboard modifier too (for speed when people become familiar with it).
Yeah these are good points, I’ll have a play to see if something can be worked out. I quite like the either/or approach (context menu or modifier). Control-Click is out (that’s fine tune), but maybe Alt/Option as you say.
I’d normally try to avoid that multiple functions per-knob as not everything will work (e.g. Stoermelder uMap wont be able to function with the Alt mapping), but in this case it sounds like a sensible compromise.
I agree wholeheartedly. I like to make keyboard instruments with as few uncontrollable artifacts as I can manage. I’m happy to have Bruce in my corner championing this cause.
Alt is not a good choice for a click modifier. Alt-click will pan the rack in Rack 2 as an alternative to middle-click drag. Some keyboards don’t have an Alt key. Fewer modifiers for users to worry about is best. And fourthly, there’s no reason you can’t just use left-click to trigger the action when the mouse has not moved outside a distance threshold.
In general, the less custom UI code you have to write for generic interaction, the better. Let Rack handle interaction consistently so users can learn one behavior instead of a different behavior for each module.
Ah ok good to know, and I know what you mean - if I start having to write janky UI code it feels like I’m going down the wrong path.
And fourthly, there’s no reason you can’t just use left-click to trigger the action when the mouse has not moved outside a distance threshold.
This is true, say for tap tempo versus normal drag of the knob (indeed I got this from your initial work on Muxlicer - thanks!), but the press and twist I think doesn’t have a natural software mapping (hence the Alt-combo).
In this scenario, would the prefered outcome be:
tap the knob for tap-tempo
drag the knob for main clock mult/div
go to context menu for output clock mult/div (rather than alt+drag)
Context menu is good for weird electro-mechanical hardware emulation, especially if the value you’re controlling is discrete.
I’ve made clicking-and-releasing on a Knob call onAction() in Rack 2, so you’ll be able to simply override to to receive button presses.
To disable double-click from resetting the knob, override onDoubleClick() to do nothing.
However, for your use case, you want to handle mouse-down which is better for tap-tempo, so I’d use a menu item for that as well. You can consume(NULL) the Action event in the MenuItem to prevent the menu from closing.
OK I think I follow, might be worth me refactoring / revisiting once Rack 2 is available.
For now though, I’ve pushed an update that moves tap tempo to context menu (only enabled if no clock in). To be honest I think the tap tempo is less relevant in VCV with there being so many clock sources, but I’ve left it in for completeness.
Now the Mult/Div knob is purely used for division/mult of the Input Clock. Output clock is just in the context menu (also Input Clock for consistency, but in sync with the knob), and removed Alt-Drag. Hopefully this is a sensible compromise. It seems more playable to me than before, and no multiple function per knob confusion.
Sometimes I want a signal in [0, 1] for control reasons. If all PWM osc are DC corrected, that leaves me in a bad place. Example use case: gate a saw with a twice frequency PWM to simulate the Alpha Juno 2’s PWM saw mode. The signal would need to be DC filtered later, but I’d really like to multiply that saw by a minblep pulse in a fixed range.
so maybe the best would be an option for AC/DC coupled, like my Shaper always had? But with no choice, wouldn’t AC be a better general default than DC?
Sampling Modulator, which is the “VCO” referred to here, has optional DC offset removal (default on, “off” is as is found in the hardware).
However this makes me think about the conversation about EvenVCO, and whether that change (which isn’t in the library yet) might impact people’s existing patches? I could make it optional from context menu? And default on or off?
, it’s a little hard to know how best to handle anti-aliasing in a module that is effectively a Sample Rate reducer. I’ve gone for the MinBlep implementation on Clock / Trigger out (with DC removal), and minBlep for the “Out” of S&H, but I’m not 100% sure what exactly is best to do there (it should sound “clangorous”).
