New open source physically modeled Wurlitzer 200A plugin

[torgover]

Hello all. New here, so I hope the post is not inappropriate.

I came to let you all know of a new free & open source multiplatform Wurli 200A plugin I'm working on which isn't perfect, but sounds better than most free (and many paid) wurli plugins. It was built directly from the genuine 200A schematics with the most accurate modeling and physics I can manage. Additionally, it uses a tiny MLP neural network node as "polish" over the core plugin to enhance realism and "wurli bark".

Update: The circuit modeling portion of OpenWurli has been spun off into a more general purpose tool called melange. Details coming when it's a little more stable and ready for public testing.

There's still work to be done, but it sounds pretty good as-is.

https://github.com/hal0zer0/openwurli

Oh, yes, Claude aided in development, but I think you'll find that the quality is not "slop"

Edit: Updated video to 0.5.0 demo

[karrikuh]

Hello all. New here, so I hope the post is not inappropriate.

I came to let you all know of a new free & open source multiplatform Wurli 200A plugin I'm working on which isn't perfect, but sounds better than most free (and many paid) wurli plugins. It was built directly from the genuine 200A schematics with the most accurate modeling and physics I can manage. Additionally, it uses a tiny MLP neural network node as "polish" over the core plugin to enhance realism and "wurli bark".

There's still work to be done, but it sounds pretty good as-is.

https://github.com/hal0zer0/openwurli

Oh, yes, Claude aided in development, but I think you'll find that the quality is not "slop"

Thank you for sharing, this is impressive work (AI assisted or not). Results seem very authentic to me, although I'm not an expert, having never owned a real Wurli.
Two things I discovered from quick testing (Linux build in REAPER):
- I get randomly muted notes (only hear a short attack click). The problem seems to disappear if I either set tremolo depth to zero or disable "MLP corrections".
- CPU usage seems to be rather high overall. Interestingly, CPU meter (in REAPER, which general is quite accurate) doesn't always reflect this. If I quickly play many notes one after another, the displayed CPU usage does increase, as expected, and audio output starts to crackle due to overload. When I just hold 8 notes, however, I also get crackles, but CPU display stays at a moderate value. My suspicion is that the amount of processing varies significantly between audio buffers and this somehow skews the CPU usage measurement.

Anyway, looking forward for this to stabilize!

[Music Engineer]

Hello all. New here, so I hope the post is not inappropriate.

Welcome! It's totally appropriate! Much thanks! It's always great to see new open source audio plugin projects pop up!

[VariKusBrainZ]

Sweet

[torgover]

Hello all. New here, so I hope the post is not inappropriate.

I came to let you all know of a new free & open source multiplatform Wurli 200A plugin I'm working on which isn't perfect, but sounds better than most free (and many paid) wurli plugins. It was built directly from the genuine 200A schematics with the most accurate modeling and physics I can manage. Additionally, it uses a tiny MLP neural network node as "polish" over the core plugin to enhance realism and "wurli bark".

There's still work to be done, but it sounds pretty good as-is.

https://github.com/hal0zer0/openwurli

Oh, yes, Claude aided in development, but I think you'll find that the quality is not "slop"

Thank you for sharing, this is impressive work (AI assisted or not). Results seem very authentic to me, although I'm not an expert, having never owned a real Wurli.
Two things I discovered from quick testing (Linux build in REAPER):
- I get randomly muted notes (only hear a short attack click). The problem seems to disappear if I either set tremolo depth to zero or disable "MLP corrections".
- CPU usage seems to be rather high overall. Interestingly, CPU meter (in REAPER, which general is quite accurate) doesn't always reflect this. If I quickly play many notes one after another, the displayed CPU usage does increase, as expected, and audio output starts to crackle due to overload. When I just hold 8 notes, however, I also get crackles, but CPU display stays at a moderate value. My suspicion is that the amount of processing varies significantly between audio buffers and this somehow skews the CPU usage measurement.

Anyway, looking forward for this to stabilize!

VERY useful feedback, thank you!

[sinkmusic]

It sounds very nice!
Congratulations

[torgover]

Anyway, looking forward for this to stabilize!

Working on some fixes right now. There's a good chance everything you described is due to overworking the cpu/buffer, so implementing some tweaks like caching some computations and skipping tremolo math when not needed. 0.1.4 will be out later today to address your issues. Thanks again!

[sinkmusic]

Do you have any plan to make a GUI for it at some point?

[torgover]

Do you have any plan to make a GUI for it at some point?

Yes-ish

OpenWurli is intended to be pretty bare bones - just a modeled 200A and that's it
Vurli will be the user-focused version, with additional effects, GUI, and polish

This is so anyone else can easily take the OpenWurli code and make their own thing from it.

[xhunaudio]

Interesting, following with much interest.

[Uncle E]

Needs to distort and compress. Also needs more polyphony.

[karrikuh]

Anyway, looking forward for this to stabilize!

Working on some fixes right now. There's a good chance everything you described is due to overworking the cpu/buffer, so implementing some tweaks like caching some computations and skipping tremolo math when not needed. 0.1.4 will be out later today to address your issues. Thanks again!

Thanks a lot! I checked out the new 0.1.4 build today and found that it brought the CPU usage down a bit, although less than I had hoped.

It did NOT fix the issues with MLP Corrections enabled, however! Can you please take another look?

Since I got curious about CPU optimization opportunities, I started studying the code and also run it with a profiler (samply [1] under Linux, in case you're curious). Here is what I found:
1) The preamp is processed with 2x oversampling. This is done with a host samplerate of 44/48 kHz in mind. I normally run my DAW at 96 kHz. It would make sense to only enable oversampling if host samplerate is < 80 kHz or so.
2) After I disabled the preamp oversampling, the profiler revealed that more than 50% of the CPU time is spent within ModalReed::render(), specifically calls to math sin(). Luckily, the whole class seems to be a great candidate for optimization. Some random ideas:

• Replace sin() by fast approximation.
• Use SIMD to process the 7 modes in parallel
• Instead of evaluating sin(phase) scaled by some exponential envelope, you could use a damped quadrature oscillator, which should be extremely cheap.
• Maybe the phase jitter can be updated at a rate lower than the audio samplerate
• Combine arrays into single array of struct Mode (that is, as long you don't use SIMD). This reduces/avoids index-based loops (see below) and overall seems more readable.
• The jitter random generator impl could be improved. Look up e.g. Minstd PRNG and combine the multiple scaling factors (the compiler might not be allowed to this for you due to strict FP rules, see below).

3) Some general observations about the code, if you don't mind:

• I see index-based loops all over the place instead of iteration. Not only is this non-idiomatic, it is also a potential performance pitfall, since bounds checks are still enabled in release builds
• There are still lot's of places where expensive math functions instead of fast approximations are used. Best to check with a profiler where it matters
• Replace x / constant by x * (1.0 / constant). Rustc doesn't have something like -ffast-math / -freciprocal-math so the optimizer can't perform arbitrary algebraic manipulations to reduce CPU cycles. You need to apply these manually. A similar case could be x * (c1 * c2) instead of c1*x*c2 or x*c1*c2 (not totally sure).
• It might be beneficial performance-wise to use f32 instead of f64 processing, especially if you decided to use SIMD. Of course this bears the risk of numerical issues, but it is generally a good idea to make the algorithm numerically robust first and not rely on 64-bit precision (there may be valid cases were this is not possible).

[1] https://github.com/mstange/samply

[karrikuh]

One more thing. I found the nonlinear scaling of the Volume parameter weird. Currently, the signal is driven too quickly into saturation. I modified the code to use linear scaling and found it to behave much more natural

[karrikuh]

OpenWurli is intended to be pretty bare bones - just a modeled 200A and that's it
Vurli will be the user-focused version, with additional effects, GUI, and polish

For the record, I like it as it is. Loads instantly, doesn't waste screen estate, does one thing only and does it well (just like the real thing).

[torgover]

Anyway, looking forward for this to stabilize!

Working on some fixes right now. There's a good chance everything you described is due to overworking the cpu/buffer, so implementing some tweaks like caching some computations and skipping tremolo math when not needed. 0.1.4 will be out later today to address your issues. Thanks again!

Thanks a lot! I checked out the new 0.1.4 build today and found that it brought the CPU usage down a bit, although less than I had hoped.

...

Consider yourself the proud owner of a new best friend