Live data from Hacker News

Show HN: Anyma V, a hybrid physical modelling virtual instrument

aodyo.com

1–10 of 30 posts

Show HN: Anyma V, a hybrid physical modelling virtual instrument

#1
Hi HN! We're a small team in Lille (France) who make synthesizers and MIDI controllers. We've just released a virtual plugin version of our hardware synth Anyma Phi, which offers a semi-modular environment with a focus on physical models, although there are several other kinds of synthesis.

Here's a video: https://www.youtube.com/watch?v=6efDQ9GmRpg

We're not pivoting to VSTs, it's just that it was a practical way of investigating several issues and helping us with the ongoing development of our upcoming Kickstarter-backed synth (Anyma Omega) and MPE controller (Loom), and a gift to thank our backers for the wait they gave to go through due to several manufacturing and production issues.

I enjoy reading music-related entries here, so I thought I'd contribute this time and I hope it will interest some. I'm here for any question or remark.

Show HN: Anyma V, a hybrid physical modelling virtual instrument
aodyo.com

Re: Show HN: Anyma V, a hybrid physical modelling virtual instrument

#3
Cool to see you on HN!

What do you see as setting your synths and hardware apart from, say, the Osmose and Hydrasynth?

If you don't mind me asking, for your hardware, what's running under the hood? Big ARM cores / SOC? RTOS on a Cortex-M? What challenges have you faced working on whichever you're less used to? (The VST if you have more hardware background, the hardware if you have more desktop software background)

Re: Show HN: Anyma V, a hybrid physical modelling virtual instrument

#4
post #2

What is your sound engine built with? What tools are you using for the GUI? I’ve found the GUI the hardest part of VST development (but I’m not on a traditional C++ Juce stack).

We use JUCE for building the app/plugin. It handles the GUI, the audio/MIDI devices and the plugin API. The synth engine was originally developed to run on a STM32F4 (what the Anyma Phi uses), so almost everything is purpose-built (with good old Makefiles). On the hardware, we use an immediate-mode UI and it's hard to go back to something like JUCE, which is flexible but a bit quirky. I often write GUIs with Cocoa for our internal tools (simulators, DSP models, etc) during the development of our hardware products and it's a much more comfortable environment.

In 2019 I had an early version of the Anyma engine running on Dear Imgui, it was really fun, but it would have required too much effort to properly manage audio/MIDI/plugin aspects in a cross-platform way, and the backends were incomplete at the time. JUCE was too much of a time saver to ignore for a team of 1.5.

I'm curious, if you don't use C++ and JUCE, what is your stack?

Re: Show HN: Anyma V, a hybrid physical modelling virtual instrument

#6
post #5

Looks very cool but note, Virus Total fails the windows installer (twice) https://www.virustotal.com/gui/file/29c67d9d9725178a2337f6d0...

Thanks. It's weird, we cross-compile using llvm-mingw from macOS and then run the Inno Setup compiler using Wine inside a fresh Docker image (Linux guest). I'm not sure how I could obtain more info on what caused both antivirus to trigger, but we'll look into it.

Re: Show HN: Anyma V, a hybrid physical modelling virtual instrument

#7
post #3

Cool to see you on HN! What do you see as setting your synths and hardware apart from, say, the Osmose and Hydrasynth? If you don't mind me asking, for your hardware, what's running under the hood? Big ARM cores / SOC? RTOS on a Cortex-M? What challenges have you faced working on whichever you're less used to? (The VST if you have more hardware background, the hardware if you have more desktop software background)

The EaganMatrix (inside the Osmose) and the Hydrasynth are both great and each one has its own approach. I think the Anyma synths are less beefy, in terms of computational resources, but the synth engine offers more kinds of modules, more freedom in some way. Not that it's always useful to have 16 LFOs or envelopes, or to be able to modulate the curve of a mapping, but it sometimes makes trying an idea easier during sound design. As we started with a wind instrument (Sylphyo), we also take special care to make support for this kind of MIDI controllers effortless.

The synth engine in the Anyma Phi runs on a STM32F4. The UI and MIDI routing runs on a separate STM32F4. No RTOS, we find it much easier to reason with cooperative multitasking, and easier to debug. So far, we don't have any latency/jitter issue with this approach, although it required writing some things (e.g. graphics) in a specific way. The Omega runs on a mix of Cortex-A7 and STM32.

I have a pure software background but I came to appreciate the stability, predictability and simplicity of embedded development: you have a single runtime environment to master and you can use it fully, a Makefile is enough, and you have to be so careful with third-party code that you generally know how everything works from end to end. The really annoying downside is the total amount of hair lost chasing bugs where it's hard to know whether the hardware or the software is at fault. In contrast, programming a cross-platform GUI is sometimes hell, and a VST has to deal with much more different configurations than a hardware synth, you're never sure of the assumptions you can make. The first version of Anyma V crashed for many people but we never had the case on the dozen machines we tested it on.

Re: Show HN: Anyma V, a hybrid physical modelling virtual instrument

#8
post #4
post #2

What is your sound engine built with? What tools are you using for the GUI? I’ve found the GUI the hardest part of VST development (but I’m not on a traditional C++ Juce stack).

We use JUCE for building the app/plugin. It handles the GUI, the audio/MIDI devices and the plugin API. The synth engine was originally developed to run on a STM32F4 (what the Anyma Phi uses), so almost everything is purpose-built (with good old Makefiles). On the hardware, we use an immediate-mode UI and it's hard to go back to something like JUCE, which is flexible but a bit quirky. I often write GUIs with Cocoa fo…

Did you entertain choosing anything outside of juice?

Re: Show HN: Anyma V, a hybrid physical modelling virtual instrument

#9
post #7
post #3

Cool to see you on HN! What do you see as setting your synths and hardware apart from, say, the Osmose and Hydrasynth? If you don't mind me asking, for your hardware, what's running under the hood? Big ARM cores / SOC? RTOS on a Cortex-M? What challenges have you faced working on whichever you're less used to? (The VST if you have more hardware background, the hardware if you have more desktop software background)

The EaganMatrix (inside the Osmose) and the Hydrasynth are both great and each one has its own approach. I think the Anyma synths are less beefy, in terms of computational resources, but the synth engine offers more kinds of modules, more freedom in some way. Not that it's always useful to have 16 LFOs or envelopes, or to be able to modulate the curve of a mapping, but it sometimes makes trying an idea easier during…

Interesting prespective. I can definitely see how you have the immediacy edge over the pain of the EaganMatrix, and having different engines besides the core wavetabel-y of the Hydra is a win, IMHO - though, yeah, both fit different needs.

I'm mostly an embedded guy (Usually much lower power ST parts), so it's neat to hear about how you approached it. Having multiple chips separate so can't underrun as easily if the UI needs to react is really nice design!

I see a lot of your engine is modified from from Mutable Instruments, but you do have a good selection of original sound sources as well. What sets yours apart? Did you have a strong background in DSP before Aodyo?

Re: Show HN: Anyma V, a hybrid physical modelling virtual instrument

#10
post #4

Earlier quoted context omitted.

We use JUCE for building the app/plugin. It handles the GUI, the audio/MIDI devices and the plugin API. The synth engine was originally developed to run on a STM32F4 (what the Anyma Phi uses), so almost everything is purpose-built (with good old Makefiles). On the hardware, we use an immediate-mode UI and it's hard to go back to something like JUCE, which is flexible but a bit quirky. I often write GUIs with Cocoa fo…

Did you entertain choosing anything outside of juice?

We also investigated iPlug2, but ultimately decided on JUCE partly because it was easier to find help.
Post reply on HN