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?
I’d say it’s always best to do previous-patch-effecting changes as an added option. So old patches always behave the same as when they were saved if possible.
The ideal scenario would be to have the DC offset removal as an option, which is on by default when a new instance is added from the library, but respect the state of existing patches (so if a patch is opened that was made when the VCO did not have the DC offset option, the DC offset would be off so it behaves the same.
TLDR: EvenVCO hasn’t historically had a dataFromJson override, so doesn’t save a “data” field in JSON. The updated module can’t even try to check for the existence of a “Remove DC” parameter in old patches until the patch has been saved (by which time it’s too late as default “Remove DC = True” has been saved, rather than legacy behaviour).
I’m wary of making previous-patch-effecting changes, so maybe it’s best added as an option but default off. And I learn @dhemery’s lesson:
Lesson learned: Always override dataFromJson() to create a “data” field.
I was just thinking of this difficulty earlier today. I think the always override JSON is probably good advice. But I don’t always take it. Lately I’ve been declaring a param called “SCHEMA_PARAM” and I init it to 1. Then in the future if I need to update I can check for it, because it will actually be there. And of curse in “the future” I default it to 2.
There’s probably some butterfly effect reason why this won’t work, but I’m hoping it will.
BTW, when I “discovered” this DC business maybe a year ago I just updated all my VCOs to remove it, with no option. I’m not saying you should do that, but I had zero complaints.
It’s a tough choice - you don’t want to break old patches, on the other hand almost no-one is going to flip the new “correct” option on, so they will just get all the bad side effects of DC on the output.
Not yet I’m afraid (you might see from port tooltip!) - I actually don’t have the hardware so I might reach out to Manu and get that moving. That said, I think can get quite far just by following the Fundamental VCO-1 sync implementation. Just whenever I get a bit of time set aside.
Yeah, I would copy the fundamental sync. It’s good and easy. When I made my EV3 I added sync, but I did I it a dumb way that is limited, but even so took me a long time to get right.
What better way to celebrate the Rack 2 release than to make some Noise! Definitely the biggest project I’ve worked on for Rack, Befaco Noise Plethora brings 30 unique algorithms for making weiird sounds.
Noise Plethora is a multitimbral noise monster in 14HP. The module consists of three digital sound generators, followed by three analog multimode Filters. This combination makes it easy to sculpt different textures and noises and play with them intuitively and musically. The first two channels let you choose from dozens of different algorithms and can be controlled dynamically by two CV controls. Textures, rumbles, low-fi blips, spikes, oscillator clusters, harsh noises, and much more can be chosen and changed on the fly. The third channel has three independent outs: Gritty noise to create crispy and crackling sound landscapes, White noise, and a filtered version with either of those two.
On a technical level, the project has required manually porting sections of the Teensy audio library (from ARM!). More details to follow on that process if people are interested. The module is now nearing the final stage, nightly builds are available to try out. Still outstanding:
code cleanup / refactoring
calibrating filters as best as possible
added DC removal option (hardware has this too)
stress testing
fixing playability of gritty noise
making sure results are sample rate invariant (Teensy assumes 44.1kHz, I’ve tried to address this so far)
Mm interesting, is there anything in the log? If you’ve not already I’d: close rack, delete Befaco folder in the plugins folder, place .vcvplugin in plugins.
I’ve only tested the automated GH build on windows, maybe something is up with the script?
Also a question for wider #development, I notice include force_link_glibc_2.23.h has been removed from SDK in v2, is this reflecting a change in requirements? Do I need to do anything clever for linux compatibility in the GH builds?
And I learn 
