Axoloti Core

[eesn]

@zrnsm

Ping me if you have other questions.

obviously, what about an Eurorack version?

[zrnsm]

Hi @eesn. Appreciate your interest in the project. What would qualify as a full Eurorack version to you? Proper faceplate and plug and play euro power header support? That’s easily done.

[kasselvania]

I’ve been getting in to this type of programming and having this as a dedicated CV/Audio in to my computer (to compliment my ES-8) seems really interesting! The opportunity to add some DSP effects internally to, say, add reverb to those inputs ALSO seems interesting!

What is the feasibility to adding a sort of ADAT process to this to speak directly to the ES-8’s inputs?
What about USB Audio capabilities?
Am I asking WAY too much of this device?

[zrnsm]

@kasselvania I think having a USB audio interface mode makes perfect sense. It’s something I want to implement for sure.

I look at flexible digital audio IO as must have as well. The processor has several serial audio interfaces and support for various formats. Only one of them is in use by default for the included codec. They’re all available at test points for expansion and breakout use.

[kasselvania]

Awesome! I don’t really know, at the moment what the full process would entail of more or less creating an output that could feed in to an optical ADAT port would be, since that would require some specific parts on my end that would then require some sort of software detail, for sure. It would be really fascinating to use it as an extension of something like the Expert Sleepers toolset because it can house its own DSP and data manipulation tool set. Thus, routing, either from an in/out perspective, you could do all sorts of cool effects.

Even if the communication to the computer stood as a USB system, it could lead to an exceptionally complex and useful tools.

I will continue to look at everything as it progresses! I am learning more about this form of GUI/Object based programming and would like to apply some of what I learn to this system.

[license]

I’m curious about i2c here too.

Also, I’m assuming that backwards compatibility implies that the architecture is again based on fixed-point (integer) 32-bit values?

[toneburst]

@license

I’m assuming that backwards compatibility implies that the architecture is again based on fixed-point (integer) 32-bit

It’s still a 32-bit ARM MCU, but more powerful than the original.

I’m not an expert on embedded systems by any means, but as I understand it, both the original Axo and the new version have hardware floating-point units, so there’s no reason you can’t use floating-point arithmetic on either.

That said, it’s still more efficient to use fixed-point/integer maths, as I understand it.

The extra power of the new MCU might make it feasible to use more floating point code, though.

[toneburst]

I don’t know if the FPU is turned on, in either the new or old hardware, mind you…

[zrnsm]

@license The legacy code is based on a fixed-point approach, but I look at it in exactly that way: legacy. My understanding is that it was done for efficiency reasons, but I’m of the opinion that even on the original hardware floating point would have been faster. There’s an interesting FFT benchmark on page 13 of this ST app note that gives a comparison between fixed and float performance. In the long run I see converting everything to float. It’s much more intuitive for people to work with coming from DSP applications in other areas and will make it a lot easier to bring in third party code.

By the way, the FPU is indeed enabled. It’s possible to use it as is. I at one point as an experiment ported over one of the SuperCollider Moog filter implementations and ran it in floating point.

[license]

Awesome! Yeah in my limited experience with Axoloti the fixed-point thing made the math pretty awkward, so this could be a huge improvement.

[zrnsm]

By the way @license on I2C: there are four native I2C interfaces in the H7 device. Two of them are completely free and available at testpoints in the design. The other two are normally in use but could be bypassed if absolutely necessary.

I need to express the testpoint pinout more clearly in a diagram but at a high level the H7 has 4x I2C, 4x USART, 6x SPI, 4x SAI (serial audio interface). One SAI is normally in use. One USART is normally allocated for MIDI DIN but only needs to be used if an expansion for that is present. SPI is not normally in use. 2 of the I2C interfaces are normally in use like I mention above. I made a conscious effort to make every processor function that might be useful for expansions available at a test point.

[weasel]

since it has been asked a couple times i just wanted to point out that there already is basic i2c OLED support for the most common types (ie. SSD1306/1309 and SSH1106) - basic as in, displaying the axoloti patcher’s oscilloscope wavefoms and 4-8 lines of text. courtesy of one of the most active object developers @SmashedTransistors:

at some point i spent a day trying to hack it into a more universal gfx interface, adding a full screen buffer and stealing some arduino line routines. but after that lost energy pretty fast:

axoloti oled control ja

i am sure someone with actual coding knowledge could make this into something real quite easily.

just like everybody else i am extremely excited about @zrnsm new hardware!

[a773]

I’d love a eurorack module of axo2. Of the top of my head is should

1. come as PCB/panel + axo2 as minimum, full kits and build modules would be great.
2. expose USB connection(s) and SD card on faceplate (so you can leave it in while programming it)
3. be reverse power protected
4. expose as many cv, trigger/gates and audio io on the front as possible.
5. accept and deliver modular levels.
6. have protection on all io (so you don’t burn something if plugging out to out).
7. be able to navigate stored patches, a knob + small LCD with large text and 2 chars would be better than super tiny text on hires OLED in my book. CV over patch selection would be great too.
8. have a few (2?) additional knobs for interfacing directly with the patch without patching.
9. be relatively compact
10. no menus

So basically a rounded eurorack module that is sturdy and feels like a finished product.

[Emile]

Sounds like something I would get! Would be a very interesting module.

[sakul]

I think I‘ll just want to put it behind a panel crow style. Front panel + power sorted, nothing more needed if I understand correctly.

[ParanormalPatroler]

@a773

So basically a rounded eurorack module that is sturdy and feels like a finished product.

I’d buy that in a heart-beat.

[zrnsm]

@a773 @sakul I think you are both on the right track here. Short term: direct deploy crow-style as a 2hp module. I’m reasonably confident that we can expose all of the standard IO that way. The technical details are there already for this in the base design. I’m probably going to run a 2hp faceplate as quickly as possible because I think that will be a useful intermediate solution for people.

Longer term: a much larger panel where the default IO is not necessarily exposed directly. Much more IO, screen, knobs, etc. The main board would probably be hidden behind somewhere or sort of directly adjacent. @weasel and I have discussed this concept at length. One idea is to keep the 2hp module accessible but have a ribbon cable that connects over to a much larger panel positioned directly to one side.

The other interesting thing to contemplate is that the board itself can function standalone without a normal Euro case and can still process CV in that mode. This is kind of a subtle point. It generates all of the necessary power rails without needing a proper Euro case supply. So you could think about having a sort of “micro” standalone patchable device. I think that the larger panel should support this idea in some useful way. Like it should allow useful patching without necessarily having a huge system around it. It could be a way for people without big existing systems to get their feet wet with modular.

I could see doing a very generic patch panel, maybe 8x8 or something, where each jack has a textual display associated with it and the assignment between jacks and software is arbitrary. And then it’s like you’re positioning “virtual” modules inside of that grid. But you might only expose a subset of the virtual module’s IO out to the patch panel. I think the bigger panel probably fundamentally needs some kind of reconfigurable nature like that.

[sakul]

Btw, axolotti is a great midi host/device/din router/converter

[a773]

So the reverse power protection and i/o protection is already in place in yout 2hp idea? How about USB connectivity, SD and modular levels?

[tehn]

having a new thing show up is exciting— and i understand the impulse to share suggestions about feature changes/additions right away, which can be helpful feedback for the creator. @zrnsm has been very accommodating.

but i’m looking at this from a totally different angle it seems: this new thing is like an audio-specific arduino. it’s a dev board. the mindset of the designer is clearly focused on enabling hacking-inclined musicians to create their own thing… given they talk about extremely technical elements of the system.

of course part of the language is “plug and play” with regards to the axolotl core software, but in reality it’s a bare circuit board, with rows of solderable breakout pins. this is a DIY thing.

asking for a pre-built module seems to somewhat defeat the purpose of its open-endedness. particularly given that there are many platforms that basically do exactly what this would be.

we have enough open-ended computers mounted in eurorack or whatever.

we need more opinionated instruments that reflect the creativity of a wide range of designers. these need not serve the needs of every musician.

this new thing is a toolkit for enabling people to build other things. and granted, there are various other very similar toolkits, because toolkits can also be opinionated.