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.
Sadly it doesn’t look like that’s an option AFAIK.
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.
This has been mentioned elsewhere, but FYI there is now a working v2 branch: GitHub - hemmer/Befaco at v2
Hi Hemmer - has the Even VCO sync been fixed now or is that still as it was?
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.
I spotted that tap tempo from the menu no longer works in Rack 2. In Rack 1, the following would stop the context menu from closing:
Is there a different mechanism to keep the menu open in Rack 2?
You need to unconsume the ActionEvent with e.unconsume() to prevent the menu from being closed.
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:
Demo 1
Demo 2
Oh MY.
Wow, great demos, this looks very interesting. Thanks!
The latest nightly build does not work on Mac for the pro version The Befaco folder exists but seems not been loaded? The downloadable version works.
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?
Here is the related part of the log:
[1.299 info src/plugin.cpp:153 loadPlugin] Loading plugin from /Users/sync/Documents/Rack2/plugins/Befaco [1.303 warn src/plugin.cpp:206 loadPlugin] Could not load plugin /Users/sync/Documents/Rack2/plugins/Befaco: Failed to load library /Users/sync/Documents/Rack2/plugins/Befaco/plugin.dylib: dlopen(/Users/sync/Documents/Rack2/plugins/Befaco/plugin.dylib, 6): Symbol not found: __ZTI19NoisePlethoraPlugin Referenced from: /Users/sync/Documents/Rack2/plugins/Befaco/plugin.dylib Expected in: flat namespace in /Users/sync/Documents/Rack2/plugins/Befaco/plugin.dylib
impressive work i ll try this
Just WOW!
Noise Plethora !! I have my eye on this as soon as a kit is available on Thonk. Thanks for your work in bringing this so quickly to Rack.
Very interesting, there will be hours of fun to have with this! 
Please do explain more details about the development process. And thanks for making this available for Rack!
As reported above, the nightly build didn’t work for me on Mac either (the same error log), but it does run on Windows.
Same thing happened on my Mac with the most recent nightly build.
Really looking forward to the new module! Looks really cool!