Build virtual axoloti VST .dll as IDE option?

#1

I doubt this would ever be possible, but if the IDE had the possibility to build a virtual axoloti.dll VST it could make for a huge leap in building the patching community and attracting new axoloti hardware buyers... Would it be that difficult?

Simulated audio out from the IDE
Improvements/Wishes for the patcher
#2

Theoretically yes... It requires two main things:

  • new code generator
  • new objects with alternative code implementations eg not relying on arm neon

Neither really hard, but also not trivial.

I do wonder about the viability, as the code is open source, it be difficult to sell - so how to fund the development work.

Note: Johaness is the only one who could make a commercial version ( say pro version) from the existing code base without making the derived code own source - this a bit limits the 'inventive' for a third party/independent developer doing it.

Id question that, I think the reality might be in drives a few sales, but this this would be nothing compared to the number of users using it to create VSTs, and therefore the support would be relative to these numbers... arguably this would skew the focus considerably. .... not saying thats bad or good, really more a matter of if this is a direction @johannes wants to go, rather than a technical challenge.

(of course, all just my opinion, using the knowledge I have of axolot/vst dev)

#3

I think the code generator does not need much modification, and cortex-M4 intrinsic functions can be replaced with generic inline functions.
The firmware needs to be ported to, perhaps, chibios-win32 and chibios-pthreads.
It is a substantial effort, there are multiple native targets: windows vst, mac vst and audiounits, linux lv2. Or running stanalone using ASIO, WASAPI, CoreAudio, ALSA.
The usb communication needs to be substituted with some sort of IPC, maybe a network socket. Parameters needs to be exposed for DAW automation etc.
A sort of dependency management system would be nice too, so the editor knows that for example GPIO objects are not compatible with a native target.
It is certainly on my wishlist, but the embedded target has a far higher priority.
I'd not like to see this develop into a closed source derivative.

#4

IPC ? Why, UI should be embedded - presentation view ( quite some effort for this but we need anyway)
Chibios ? Why? Host provides environment , use cross platform library eg juce
I can't see much need for anything other than generating full standalone VSTs like synthedit
Even then crowded market as we are starting to see quite a few modular VSTs.
Of course the main one is Reaktor, axoloti potentially offers performance but it's at the expense of live patching ... with more powerful pc is this a good trade off?
Of course for some users attractive , as its free, depends on your target user base

#5

Hi Johannes - nice to hear you have something like this on your wishlist.

The main attraction for me would be prototyping with virtual in/out midi and audio when on the move on a laptop.

Once I've gone through the many iterations (and years!) I might go through in building my red panda particle/microgranny/anti-nautilus or generative midi future retro zillion inspired frankenstein for the axoloti, only on my final version might I then start building the physical enclosure and knobs, controllers and lcd to house it.

A secondary attraction would be bringing more virtual users into the axoloti to breed ideas to benefit the community and increase the commercial success of wherever you might want to take things.

totally understand though that the embedded target is top of the list in terms of priority, that makes sense as I can still achieve what I want in terms of development without absolutely needing a virtual axoloti to get there.

#6

I had this thought as well - something like an Axoliti "emulator" would be great. So one could run patches on a computer using JACK, or standalone on Axoloti hardware. That would open a lot of possibilities, for debugging, interaction with other applications using JACK and MIDI, etc.

#7

i can say this is a feature i, too, would enjoy and something I'd even be willing to pay for as I don't have any real way to contribute to the development of something like that.

#8

Hi, Im new here with my new Axoloti Core, but I have enough time using Pure Data. So, I like a lot the idea of an Virtual Axoloti to create/debug patches without the Core. I',m agree to pay for that,

#9

I had thought of an emulator as well though not as a VST, but for building and testing patches faster by not having to upload them to the board.

I agree and had thought of using juce for a C/C++ user interface that would would enable control of patches without having java on a system.