I learned about the Axoloti a few days ago and I'm totally in love with it already. I'll be ordering quite a bunch of them when I have the chance. But in the meantime it would be extremely handy to start designing and imagining all the creations that have already gone through my head with just the IDE on my computer. Simple MIDI and audio I/O should be easy implement, maybe VST and other plugin formats in the future. I think that this feature would lower the threshold for getting an Axoloti, and generally learning node-based programming. Especially for people who feel intimidated by these things, but would definitely want a multipurpose audio tool in their gear. To my understanding, the IDE calculates the DSP load from the compiled code so that you shouldn't be able to create patches that the board can't handle, or would the simulator need to be emulated to the hardware level?
Simulated audio out from the IDE
this would be possible if someone wanted to do it, but its non-trivial esp. as many objects have have ARM code in them, and also issue surrounding sample rate.
this has been discussed in various topics, I think the last one was this;
(saying that I thought, I half remember a more in depth discussion in a different topic)
the ide makes no attempt to calculate dsp load.
I think also to counter the above, whilst the above would be useful , and widen appeal (for the software rather than hardware?!)
the workflow for axoloti if you have a board is very fast.
the going from editing to the patch running , takes what, 5-10 seconds? so its not really a chore, and I know this is still an area Johannes has talked about trying to improve e.g using incremental compiling.
so whilst, as a programmer, im all for reducing the compile, test lifecycle, its really not that bad on axoloti - I spend lots more time thinking about how to arrange/design a patch, compared to compiling/running it...
not saying its not a good idea, it is, and has been suggested many times - its just no one has wanted to take it on.
I also wonder, how much extra revenue would axoloti editor producing vsts create for axoloti/Johannes - perhaps a little in cross sales.
but on the flip side there would be more support costs for the axoloti editor (from non paying users) which Johannes cannot charge for... would this be offset by an increase in axoloti sales?
axoloti is a bit unusual, the hardware sales finance not only the production/distribution of hardware, but the dev of software, support costs, even this forum...
and because the software has been open sourced, theres no opportunity to derive more income from that by extending its functionality/scope..
but that's just my viewpoint, it almost a hypothetical question really,
as only Johannes can make that call, we can just speculate 
Oops, rookie mistake. Should've searched the forum before asking.
I'm not a programmer, but I read code quite efficiently, although I haven't had the time to go through the source code yet (actually haven't been able to install it yet). Do a lot of the objects have inline ARM assembler other than port manipulation? Isn't most of the math code C? And if there are some often used inline assembler commands, they could easily be ifdeffed to basic math for the simulation mode.
My thought was that the hardware-related objects (GPIO, ADC, DAC) would not be simulated, testing would be done with GUI faders and buttons, or MIDI. And as the IDE is Java, simple MIDI and audio I/O should be quite easy to implement on all platforms. Latencies would be fine in the 100s of milliseconds since the purpose wouldn't be realtime work, just testing things and checking out how different algorithms sound like in 32 bit fixed point.
What's the problem with the samplerate? Isn't it just 48000Hz and 3000Hz for control?
I have a feeling that creating patches with a laptop and headphones could be the best way to kill time on public transport. I play with modular synth apps on my phone, but for live playing, I don't like computers. It would be so much more rewarding knowing that next week I'll have this sound in a stompbox or toy keyboard.
Not focusing on low latency performance (Java audio and MIDI) and staying away from plugin development could weed out the needy feature requesters who will never buy an Axoloti. I have a lot of musician friends who would order a couple right away, if they could check what kind of sounds they could get out of that magic little box before ordering.
theres quite a lot of arm specific dsp code in the objects. (you can look at them in GitHub if you want)
sample rate is not fixed on desktop, people also use 44.1k a lot, so to do it 'properly' you have to support non-48k sample, but there are various dependencies (e.g. lookup tables) what would need updating.
fyi: a while back I did get axoloti creating code for another platform, so ive been through this loop, so I know its possible - just it highlighted to me its non-trivial and has it limitations.
at the end of day, it just comes down to if someone has the time, motivation and skills to want to do it - its all open source - for sure id love to see it too.