Befaco modules development blog

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?

1 Like

Bog’s pulses don’t seem to have a duty cycle dependent shift, but if that gets fixed…

I’m just trying to keep the math cheap. :stuck_out_tongue_winking_eye:

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.

1 Like

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. :confused: 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.

1 Like

This has been mentioned elsewhere, but FYI there is now a working v2 branch: GitHub - hemmer/Befaco at v2

1 Like

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. :slight_smile:


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.

1 Like

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)
  • port tooltips etc
  • code optimisation
  • tester feedback

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 :slight_smile: i ll try this