V0.4.x Firmware Workout: Goofing off never felt this hard

Did anyone mention internal routings not being currently saved in presets? I’m not sure about the scope of it but it definitely seems like a bug.

Harder to explain than to just show so I filmed the preset I was working on (unlisted YT):

Oh yes: the same routing is also lost when copying and pasting so that’s probably exactly the same problem.

I believe that you are assuming that all oscillators are in phase. This is not the case. The only case when 2 oscillators are in phase are when you have sync’ed them with the same trigger and they have exactly the same frequency.

As for the mixing of the bands: Each band is scaled by 1/N and summed together where N is the number of bands. Averaging the bands this way means that the output signal will have the same amplitude as the input signal as long as each band has unity gain.

i think i found a bug.
0.4.08 normal 48khz version.
insert this mixer channel preset into a stereo chain,
load whatever sample you want into the manual grains,
try to assign to the speed (or other params) one of the two “pingable scaled random” bespoke units via locals, no way to assign them.
Micro Grainz Kick.unit (8.9 KB)

@odevices it is a known issue?
p.s. i have a clock patched in b1

it is doing this even outside mixer channels, but only on stereo chain.
if i move the unit to a mono chain, no problem.
weird, i never noticed this behaviour before

39 posts were split to a new topic: Units that block their inputs

I can no longer create controls on custom units (fresh unit, no content), the 301 always ends up with a crash. Here’s the log: https://drive.google.com/file/d/1-UvBfVqENePNk3qeO-T44APbJcwBWdeS/view?usp=sharing


/ok updating from 4.07 to 4.08 (was not aware of it) solved the problem. :relaxed:

1 Like

hey all, sorry if this question has already been answered, but do we have a semblance of guarantee that custom units will be forward compatible from now on? I’ve been meaning to get back to work on my 301.

Personally I don’t look at anything in the firmware as being fully stabilized until we reach 1.0. That said, it seems like Brian tries to maintain some forward compatibility whenever possible.

okay, that sounds pretty reasonable. I don’t really mind playing sisyphus for the time being :stuck_out_tongue:

1 Like


Possible intermittent bug while renaming units. I cannot consistently reproduce this as it is either a combination of key strokes or scrolling up against the top of the rename menu (or a combination of both). The encoder will switch scroll direction. If user exits the renaming screen, the behaviour will reset to normal.

Normal: CW = scroll down, CCW = scroll up
Bug: CW = scroll up, CCW = scroll down


Renaming Global Chains does not auto populate previous name.

1 Like

a feature, not a bug :wink:

Hehe. As @hyena implied, it is intended behavior. Your first turn of the encoder determines the direction for scrolling down but only for that one session with the keyboard. I’m experimenting with it. Different from the faders, there is an ambiguity with the keyboard: are you scrolling the foreground (selection bar), or, are you scrolling the background (the letter & numbers)?

Anyway, bug report noted. Experiments will continue.


Very interesting. Thanks for the explanation.

Another possible cosmetic bug or perhaps clever reason?

When assigning a Source in the Meter Menu (e.g. INx, Ax, Bx…) CV signals will show up but immediately fade to 0. When drilled down in the sub Scope Menu (e.g. Dx, D1, D2, D3) The CV will show actual value without fade.

Is the upper source meter menu screen meant to show change rather than absolute value?

Essentially, yes. Those meters show loudness in decibels. A constant signal is silent.

1 Like

Really enjoying working with v0.4.x and all its lovely new features compared with the v0.3 releases. So nice!

It’s been about a month since v0.4.08 was released and I’m wondering if maybe I have missed any clues about when another update might be on the way and what might be in it…

I’m actually quite happy with the current version except that I have some largish v0.3 custom units that I would love to have available. If it doesn’t look like a v0.4 version will support loading v0.3 presets any time soon I can just re-implement them in v0.4 with only a moderate amount of moaning and groaning, but I would hate to spend hours doing that and then have a new version come out that imports them automatically :slight_smile:


Sorry for the delay on that. I’ll have an answer for you this weekend. :bowing_man:


Any possibility will we every get long convolution reverb? Or is it impossible with the current processor?

When it comes to exact convolution, based on the current literature I believe I have already implemented the most efficient algorithm or at least 90% of the current state of the art. However, when it comes to approximate convolution there are still a lot of things to try, some of which I’ve already started working out on paper. If they work out then you will see an improvement but the amount of improvement will probably depend on the IR.


this is great news! exact convolution is uber-interesting, but i’d like to see a stripped down, less precise unit we can use with more nonchalance in complex patches!!! thanks @odevices for the never ending research & development!!!