Bogaudio seems to overload MM

[deniSound]

Hi,
I spent a few hours to trying to make a small fm voice (with bogaudios plugin) working on MM. With three Operators, it already overloads though.
I’m a bit desappointed. It’s really a light patch. Is somebody able to play it?
Patchtest2bogaudio.yml (16.6 KB)

Other thing. In vcv, showing the labels is super cool. By unmaping a knob, label remains… not good.

Thank you. For me, MM still remains a promising product.

Denis

[offthesky]

i ran into that same problem with bog fm op ones in a simple patch i made. in this post, dan states they are actively working to fix the bog ones:

Gain staging and headroom

i wonder if mm is running at 16bit internally. i would think that could maybe cause clipping in the signal path. also i noticed some bog audio modules caused clipping for me. the bog umix one has a soft/hard/none clip setting in vcv, if you right click on the module in vcv(i dont believe the alt settings for modules are available to choose on the mm itself). but im guessing maybe your clipping is coming from somewhere else in the patch.

[TheTechnobear]

as this is about FM Op, I’ll add another ‘issue’ for @danngreen

it appears that BogAudio feedback parameter is not always initialising correctly when loading a patch.

Ive got a patch w/ 2 fm op, which when I load up after power cycling module, just outputs noise…but if I load another patch, then re-load it will sound fine.

I noticed if I turn up the feedback parameter I get the same kind of noise.
so it would appear to not be initialising the to the value saved in the patch.

notes:

• I do have feedback mapped to a knob (in set 2), should be unrelated - but I thought id mention it ‘just in case’.
• patch is not cpu bound, quite a bit of headroom.
• stop/play patch does not help.

[danngreen]

OK I found an issue with one of the dsp classes (ShapedSlewLimiter) in the Bogaudio plugin, and it’s very strange. The code looks fine, the math is fairly straightforward and I see no issue with it. But it does not behave as expected on the MM.
Lots of the Bogaudio modules use this class, which explains issues with them (LPG is what led me there). I might expect to see some other dsp classes with similar issues too. I’ll get to the bottom of it… but just letting you know I found something and am on it!

[danngreen]

Ok! I think I found it. I was using a math optimization compiler flag (-funsafe-math-optimizations, sounds fun and safe, right? ) that was making the math calculations in some Bogaudio dsp produce the wrong results. Presumably this might be effecting other plugins, as well.
I am going through and making sure this doesn’t effect performance at all

[danngreen]

I tested all the plugin modules with and without the unsafe-math-optimizations flag and there’s very little difference in CPU load. So I’m going to create a new release for all modules with this flag removed.

BTW, here is my post with all the CPU load numbers:

CPU load number database

I wrote some code to measure CPU load for every module under various conditions. I have the raw PRELIMINARY results here. Goals The goal is to create some new features on the MM hardware and in VCV that leverage pre-recorded CPU load data to make a reasonable estimate of CPU usage of a patch. For example, the MM firmware could tell you in real-time how much the CPU usage would change if you added a certain module. Or to be able to browse modules and choose the lowest CPU utilizer that does the …

@deniSound : now that I have this, I can more properly analyze your patch. Thanks for your patience!

[danngreen]

@deniSound
Ok, with the patch load spreadsheet, I can see a few things about the patch. Here’s the modules in the patch, with the “All Inputs Patched” CPU load. The %age numbers are worst-case (so our actual numbers are less than these).

1: 'Bogaudio:Bogaudio-LFO':     32% 
2: 'Bogaudio:Bogaudio-VCA'      12%
3: 'Bogaudio:Bogaudio-AddrSeq'  13%
4: 'Bogaudio:Bogaudio-DGate'     8%
5: 'Bogaudio:Bogaudio-FMOp'     29%
6: 'Bogaudio:Bogaudio-FMOp'     29%
7: 'Bogaudio:Bogaudio-FMOp'     29%
8: 'Bogaudio:Bogaudio-Matrix44' 16%
9: 'Bogaudio:Bogaudio-Mix4'     38%

Plus consider ballpark 10% for the audio engine’s internal stuff, plus processing the 19 internal cables and the active knob set.

Total all that up and we’re at 226%. These numbers are “worst-case”, that is, all jacks patched, and since this patch has many jacks un-patched we are able to play it (at least I am at block size 64, but it’s around 93%).

Some surprising things here:

• Bogaudio-Mix4 might be the heaviest CPU load of the patch. Maybe try another mixer: the 4ms StMix uses at most 10%, Befaco mono mixer is around 9% and stereo mixer around 14%.
• Bogaudio-LFO has a heavy CPU load. It looks like you’re just using the square output with PW, Offset, Scale controls. Maybe this could be replaced with another source? 4ms MultiLFO + Befaco DualAtenuverter, or just the 4ms DEV (which has variable PW and offset/scale built-in). Just some options I’m familiar with, there are probably a lot of other ways to do it.

[deniSound]

@danngreen
Hi Dan,

Thanks for these updates and all your work.
I’ll try this out and see how it’ll work.
BTW, I noticed something strange about the matrix switches modules of bogaudio. I’ve used one of them before choosing the matrix mixer for this patch (switches are more effective to use in the context of choosing a FM algorythm). And I mapped knobs the same way I did for the matrix mixer in the patch I sent here. And I noticed that the buttons, which IMO schould be just ON or OFF, behave like continuous attenuators (Like the mixer). I saw on the manual that the color of the buttons are changing countinuously regarding the amount of signal that passes through the jacks… this might explain this issue… I haven’t tried to replicate this in vcv with the Stoermelder’s module, but this is the the behaviour I’ve noticed mapping these switches with MM in vcv. I suppose that’s within the code of the bogaudio’s module and have nothing to do with MM itself, so I suppose that this question should be asked to Matt Demanett?
Cheers

[Drozas]

I have an issue with plugins from Bogaudio aswell LPG and LLPG; they work pretty well when I create a patch from scratch, but when I reload the patch, the sound is all messed up:

I have bogaudio on autoload by the way.

[Nvgtr]

I have also had issues with Additator overloading anytime the partials are taken above around 50%. Happens pretty reliably.