Next-gen and mini Axoloti hardware discussion

#211

Quick update: firmware development is proceeding smoothly. I have an H7-enabled build up and running on the prototype. There are a couple of rough edges to smooth out here and there but nothing too bad. All of my testing so far is looking good.

#212

Sounds great! Just to be clear - you’re able to load a patch and get sound?

#213

just seeing this now... this looks great! I hope it all works out and becomes available. while the axoloti is infinitely better for so many reasons I find myself still trying to use patchblocks a lot when I need to fit installation work in very small spaces or need things to be highly portable but multi-channel. having 2 or 3 of these would make getting multichannel set ups in small spaces so much easier.

If another board could be developed easily to fit on top with just a couple knobs and buttons and a mini led screen it would be gold. nice work and good luck.

#214

By the way, to clarify, yes, I can load patches and get audio on the prototype.

Several of you have asked me for more detail and timelines, etc. My plan is to hold off releasing hardware until everything is meeting my standards as far as performance and stability. I want to make sure that all features from the legacy hardware are up and running and stable. I'm not quite there yet, but everything is looking good. I would rather take the time up front to get things right rather than rush something out before it's ready. I want to make sure that we're in a good position to implement the enhancements I have in mind down the road. I appreciate your patience.

#215

So happy about the way this project is going.

#216

@Urklang If you need help with firmware tweaking, keep me tuned.

Hardware Update
Call for patches that push Core to its limits, expose issues
Anyone has a Axoloti Core for sale in the EU?
#217

hello,
hope the final testing is going smooth and fine !
have you an idea of an average issue date ?
thanks !

#218

Hey everyone. I appreciate your patience on this. Quick update: I'm waiting on fabrication of a revised version of the hardware that moves to dual USB-C as we discussed before. The firmware on the v1 prototype is looking good; all of the core features are up and running. I've been really happy with the DSP performance so far although there is more optimization to be done. I've built several stress test patches that would be tough to run on the original hardware but run just fine on the new hardware, one with a huge numbers of oscillators (300+ sine oscillators in one case) and one with many stacked reverbs. The plan is to validate the new USB-C v2 prototype and then open it up for pre-order on a larger run. More details to come.

#219

Will we still be using fixed bit for audio? From what I understand it's unnecessary even on Axoloti since the board has an FPU that's going largely unused.

#220

@urklang - Aside from the change to dual USB-C, were there any other changes from the first prototype, which were developed in response to testing?

I'm looking forward to this gadget.

#221

The first release will be fixed point, just as in the current system. But I'd like to expand float support in the long term both for efficiency and to be able to be more interoperable with other systems.

@tele_player Mostly minor changes to optimize for pinout usability and part count/cost. USB-C is the biggest change. It's functionally almost identical to the v1 prototype.

#222

Not sure if this is something to mention now or later in the developement, but concerns are if later I might forget, and hard to know if details are required for setting the GPIO. I should get to the point...!
Being able to connect K-rate and S-rate lines directly to PWM output pins.
With RC filters, the k-rate output could be used as a sort of voltage control, the S-rate could be used as an audio output, I am sure there are alot more details to go into to set it up, but if setting the GPIO requirements early in developement is required, maybe its something to consider.
Even doing it may not be favoured, but just puting it out there.
:grin:

#223

I was just thinking about that last night. Since we get more cpu and memory, it would be really lovely to be able to use floating point math for more precision and better sound quality. And also ease of use, as floats are just a bit easier working with. Would that mean we would need new inlets/outlets and output stage made with floats?

#224

Even on the current hardware, floats are very efficient.

Even if the objects communicates with fixed point q27 (frac32),
you can use floats inside the objects as long as you translate them
back and from the with instructions like

arm::q_to_float(ix ,27);
and
arm::float_to_q(fx, 27);

These are efficient.

Floats inside objects are very efficient because there is 32 float registers in the FPU. This means that local float variables won't be stored in SRAM but in registers.

Fixed point fractional are very useful when you deal with accessing and interpolating tables (addressing, modulo a power of two and use of 1 cycle mul acc).

In many occasions i optimized my objects with a mixture of floats and fractionals.

#225

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 :smiley:
.

#226

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?

#227

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.

#228

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).

#229

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 :slight_smile:
IMO in distortion algos oversampling is essential.

#230

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.