I think that an "oversampled x 2" kind of inlet outlets would be nice.
At the moment I implemented a few oversampled objects by using pairs of outlets (to double the number of samples).
With the new CPU horsepower, x2 oversampling is a viable option 
.
Thanks for the info @SmashedTransistors didn't know that.
I do use floats in some objects already. I just thought they were too heavy for using it a lot, as this has been mentioned several times by both TB and Johannes.
But for example if we want to have the audio in floating point too, don't we need new float in/outlet as well as floating point output stage?
It would be better indeed, we would not need to use arm::q_to_float(ix ,27); and arm::float_to_q(fx, 27); even if these are efficient, they take some CPU cycles.
Does the new hardware will natively support double precision floats ?
Most of the time simple precision floats are enough for audio but in the specific case of second order integro differential antialiasing they are mandatory (this method + x2 oversampling would allow efficient antialiasing for distorsions and oscillators).
Yeah, I did test making a k-rate division object using the arm::float_to_q conversion and then do the division in float and then back to int32_t. It worked, but it takes more cycles to process than a division method that you showed me a while a go, using a reciprocal setup.
Yeah these things start to become really interesting when we get the new powerful board 
IMO in distortion algos oversampling is essential.
The H7's FPU does indeed support double precision. I haven't had a chance to explore using it yet.
There are some other interesting hardware features we'll be able to explore later on too. The H7 includes a few programmable analog devices for IO signal conditioning: some opamps and comparators. I think we'll be able to put these to good use for controls/sensors etc.
What about making a special edition of Axoloti which also includes an FPAA in the same board for further I/o analog processing? Would that add a lot in the original price?
This is certainly an idea I want to explore. It's definitely possible technically. We can take the FPAA engine from the Zrna stack and run it along side a DSP engine on the same core, either the legacy Axoloti one or future ones and then have some mechanism for easily moving signals between the two domains. It's a longer term project. I think that we could get the price down. Another approach would be to simply do an FPAA shield and then have the possibility of talking to it from the main board.
But then you could start building hybrid ideas like doing all digital oscillators but analog filters, etc. I think that could be really cool.
By the way, take a look at the H7 datasheet for details on its included analog devices. They're pretty limited. We're not going to be pulling off the level of processing we can do on a full FPAA, but they're still interesting.
I don't have the background or understanding to fully grasp what might be possible with FPAA, but the idea of having programmable analog circuits available to provide filters on the same board sounds really cool and useful.
At the moment I'm planning to build stereo analog filters (MS20 or Yusynth Moog ladder filter) but with limited skills and $$ this means using stripboard designs and doing some kind of CV conversion stuff as well as a euro power supply. Kind of a hassle tbh.
I suppose it would come down to how much more it would cost versus how many folks are likely to make use of it, but the programmable analog filter add on idea seems communicable to me.
This is definitely possible. Here's an example of a Moog ladder style filter I did running on my Zrna FPAA system: https://zrna.org/demo/ladder
There's also an example of a simple MIDI to CV converter: https://zrna.org/demo/midi-to-cv-converter
Making versions of other classic filters like the MS20 etc is possible; it's just a matter of developing something close to the original transfer function with the building blocks available on the FPAA. There's a lot of prior analysis that people have done of most of the classic filter designs. Tim Stinchcombe's work is really great in this area: http://www.timstinchcombe.co.uk/index.php?pge=korg
Editing a Python script to do this kind of job is way easier than actually fabricating a clone of the original filter with components.
Back on the DSP/Axo stuff: I don't think there's a reason to force FPAA functionality into the main board, some people won't be interested in using it. A stacked expansion board is probably the first step. Then we can do a dedicated hybrid board if there's enough demand for it.
Several of us have been throwing out ideas about this but I think long term it makes sense to have sort of one universal patcher application that can drive all of the hardware whether it's DSP, FPAA or some combination.
FPGA are also interesting. It is quite easy to interface them through SPI. Even with a static configuration, they can be configured as dedicated DSPs and/or interfaces.
Today, both processor and FPGA can be found in the same chip. A Zync-7000S chip embeds a ARM9 processor along with FPGA fabric.
Kicking around ideas for patcher improvements I came up with this quick hack of the VCV Rack patcher that allows modules to be at arbitrary positions just like the Axo patcher:
See where I'm going with this? I'm working on importing all of the Axoloti objects in such a way that we can draw them with the Rack graphics engine.
Interesting. I wrote a bunch of vcv objects a while ago.
But I am a bit biased about anything VCV related. For one main reason, it is a huge cpu hog. I don't know if it is the graphics(endless scaling, etc.) or the facts that everything is updated at audio rate or a combination of both.
I would be really sad if the editor suddenly becomes cpu heavy and older computers would not be able to run it and I would end up having to buy a new computer to run it. I would rather have old and ugly. but efficient, rater than new and fancy, but not so efficient.
I hear you. This is purely with the intention of getting us to a more efficient and modern 2D graphics renderer for the UI and to get away from Java. Rack's UI uses GLFW so it basically gets boiled down to OpenGL calls which we should be able to run even on very constrained targets like the Raspberry Pi. Everything is compiled to native code so we have more control over performance without having to rely on a JVM. All of the audio computation would still be happening on the remote device, so it's difficult to compare prior experiences with Rack itself.
One immediate benefit of this graphics pipeline over the existing stuff is that everything is done in SVG and can easily scale and zoom on whatever screen you have. That's one of the biggest issues with the current patcher.
Isn't that kind of heavy on system, the endless scaling and so on?
Btw regarding using Rack's graphic interface:
Have you talked to Andrew about it? I am not sure he will like this. Long time ago I made some objects, based on the factory objects from VCV and he was not too happy about it. Of course everyone can make the own user interface, svg knobs and so on, but then we are getting into a whole new territory, which I am not too fond of spending time on. Anyway, my point is, that he is into heavy control of everything related to VCV.
But I do understand the though og trying to avoid Java, if that creates issues.
Yeah that is probably correct
Anyway, interesting path you are taking here 
How is the development going, overall? Everything worked out great for now? Still no date for release of the new one yet? Hehe
So excited here
Ha ha, don't worry about it! This is just an interesting experiment at this stage. I'm not going to do something that I'm not convinced makes the patcher experience better and more efficient overall. The Rack code solves a bunch of problems we need to solve more efficiently than we do right now; it makes sense to reuse as much as possible and simplify our codebase. There's also a huge user base there that might be more interested in Axoloti-style devices if the patcher were more inviting and similar to something they're used to.
By the way, the objects would be drawn automatically just like current axo objects. There would be no required manual preparation of the SVG panels like you have to do for Rack modules (although that could be interesting if people wanted to do it for certain custom objects). And we wouldn't be reusing any of Andrew's graphical assets or any of the VCV branding. We're just using normal GPL'd code.
Sounds great.
Looks simpler too. One question here:
Yes, I'm thinking that by default legacy objects would be rendered automatically from their descriptions, but an object author could easily prepare a custom layout to override.
Do you mean being able to interactively change the positions of widgets on an object? I think that could be interesting like in the case of a subpatch that exposes controls to the parent. Being able to edit that layout interactively from the parent patch could be really useful. I'm not sure if we'd want to enable that kind of thing in all cases, like we probably want factory objects to be drawn consistently.
Sounds great Keep it simple and effective
I was just thinking about being able to deviate from the standard vertical placement of knobs and buttons.
Yeah that could probably be nice.
One thing i often miss is being able to use "display on parent": being able to put displays on subpatches, like you do with knobs, buttons etc.
