Next-gen and mini Axoloti hardware discussion

#42

Subscribing the fuck out of this newsletter. So excited for this project!

@urklang, you're talking about keeping the same GPIOs, right?

#43

@JoshuaACNewman The plan is to preserve as much IO as we can on the base board and move larger connectors (1/4th, MIDI DIN) to optional expansion boards. I'm using an MCU that is pin compatible. So for regular test points like for GPIO and standard peripherals we should be able to preserve most if not all of that on the base board; it's going to come down to exactly what the final dimensions are and how the final layout ends up working out.

#44

I’m down to try some beta boards or whatever! I know that doesn’t make me unique here, but if it helps bump up the volume on prototype board orders, I’d love to help!

#45

Quick update everyone: made some great progress on the layout this weekend. STM32H7 is go (clock rate bump etc). Sticking with a single unified 3.5mm headphone/line out on the base board as discussed above. I'm also bumping the SDRAM up to at least 32 megabytes (4x jump from the original core) possibly more if I can find a way to pull it off. Basically I want to absolutely max out the SDRAM for a reasonable price so this hardware can keep us going for a while. Pocket MPC please!

#46

Opened a discord server here: https://discord.gg/xeztjzh Jump in if you want to chat.

#47

Coming late to this thread and have read it all and thought I would jump in and suggest to keep the board dimensions to less than 4" in any direction so a compatible Eurorack module could be designed easier than it currently can for the Axo board. Another suggestion, if the I/O is going to 3.5mm, optional pads for dual TS jacks would be very helpful. They don't need to be laid out as PC mounted jacks, just headers available for use by a daughter board with other connectors too. The Eurorack market is a great target for this project and a unit that could just be a smaller board plugged onto a larger board with all the interface components for Eurorack use would be a big seller.

#48

@Ersatzplanet Glad to have you man. I'm in total agreement with these requirements.

When you say supporting dual TS jacks you just mean having the TRS pads exposed on a header right? As in being able to have a TS for L and a TS for R? That is supported in the current layout. The strategy with the test point IO is very standard and uniform right now: double rows of 2.54mm test points right at the edge between mounting holes, somewhat like a Raspberry Pi Zero. I'm trying to make the IO as accessible as possible and configured for stacking breakout boards; there isn't any attempt to position test points elsewhere on the board in any particular shape for components.

I'll be posting the layout before we send out for prototypes just to make sure that everyone has a chance to get comments in.

#49

Thinking about the possibility of supporting a Eurorack power header out of the box. I need someone with more Eurorack experience to chime in. Is 10-pin good enough? Would 16-pin make it more appealing to Eurorack users? Do people acutally use the CV and GATE signals on the 16-pin header? How? Was looking at this:

image.png3490x3494 461 KB

We easily could support either one as an optional power connector.

#50

Two separate mono jacks instead of the stereo TSR the current Axo uses. They of course should be headers because the idea would be to have a front panel PCB with all the pots, jacks, switches that the user would want to configure, in the positions they would want them to be in. The most flexibility possible. This would extremely simple module, or super complex ones. It would also allow a maker to sell front panels and front panel PCBs pre-configured for specific task and a "program and forget" main PCB used as the guts. Much like the Roland modules that are based on the same engine but have dedicated functions.

#51

There are not many people using the CV/Gate busses but they are available in all power systems in all the cabinets I know of. There are limitations - only one device on the buss can SEND to the buss, but as many as you want can RECEIVE from it. I would suggest the way around it on your system would be provide the pins to make the connection and the user would decide if they wanted to use the 16-pin header or just a 10-pin header. On all the modules I make that use the busses (Synthwerks FSR series, MG manual gate series) we provide a jumper that connect oe not to the bus. This allows prevention of more than on sending device sharing the same bus.
Another consideration would be to not deal with the Euro power headers at all, provide the connections as you would any other I/O and let the designer of the front panel PCB put the connector there and choose what they want to attach to.
I have a module made by Tesseract called the Nutella, that is based on a PCB produced by Robertronics through SparkFun (the Tsunami wave player). The Nutella is just what we are describing, a from panel and PCB with level matching circuitry and jacks and connections to interface the Tsunami (which runs with totally different Gate levels etc) and the Nutella PCB provides the Eurorack power connector and with an onboard switch to choose running it from the cabinets +12V supply or the +5V supply if the cabinet can do so (many Eurorack cabinets don't have a +5V or have a very low current one available). I would let this all be up to the maker of the front panel PCB. Keep your design as flexible as possible by just bringing as many things as possible out to headers and let the users connect to what they want. Make it as small as possible and you will get people making dedicated pedals with it too.

#52

Cool. I think we're in agreement here. I was hoping that it would be reasonable to just provide flexible IO as you describe instead of the entire header. The approach I'm taking at the moment for power is to allow both USB bus power and power from a Vin test point somewhat like how the original core works except that there won't actually be a barrel jack. In a Eurorack context, someone rolling a module could use header +12V or +5V and still use USB for programming etc. Or as you mentioned do a kind of one time programmable thing that's then packaged behind a panel as a module.

#53

Jumping late too in the discussion. I few remarks from my side:
* I plan to use axoloti (or whatever) as an addon to my Nord Stage 3. So I need MIDI In/Out & 6,35 Jacks in and out.
* A fcolleague of me see interests (read potential clients) in making guitar pedals with digital effects. Axoloti is a good platform for that.

Hardware wise, there is the interesting Bela project. It is based on a OSD335x (TI Sitara A9 600MHz +RAM/FLASH...) It has a 1ms delay for music generation. Based On Linux, 1 audio in/out, USB MIDI... They make also Eurorack module for it.

It is not advertisement, Just information about a nice product that doesn't fit exactly the same needs.
They made a crowdfunding campaign and I think It is a good idea. Personnally I like crowdsupply.com

#54

While the Linux/OS part throws me off completely, i think Bela seems to have gotten a lot of things right in their shield game: multi channel audio expansions, convenient multiplexers and pinheader-pluckable eurorack PCBs.

#55

What bothers you about Linux?

#56

the great thing about bela is, that you can compile pd patches into c code via the now opensourced heavy compiler. i made a huge granular realtime fx within puredata and compiled it for bela and it runs very smooth!!

#57

I'm with @weasel79 on skepticism with having the full Linux stack. There are a couple of problems I see with it. Latency and performance is probably number one. They claim to have solved that with some Linux kernel hacks, etc:

"Bela runs a 4.4 Linux kernel with the Xenomai real-time extensions to provide ultra-low-latency performance. Xenomai Cobalt is a co-kernel for Linux that allows [running] selected threads at hard real-time priority, bypassing the Linux kernel to achieve performance comparable to running bare metal without an operating system. We are using an onboard 200MHz microcontroller (Programmable Realtime Unit) available on the Texas Instrument AM3358 system-on-chip (SoC) to act as a sophisticated DMA [direct memory access] controller, performing the low-level input/output operations for the audio channels (over I2S), analog channels (over SPI), and digital channels (the SoC's GPIOs)."

I haven't worked with it at all so I don't know if their claim of sub 1ms latency is legit. I know from first hand experience as a daily Linux user how painful its audio stack can be. I'm guessing that this depends on exactly what you're doing. The apps you're running on Bela might not actually respect that deadline because they're used to running on a normal Linux desktop with the entire audio stack (aside: it sounds like some of them are patched or have various Bela-compatibility layers available). This leads to the second point:

Because you just have a regular Linux box with a bunch of compatible apps, it's not as focused as it could be. It's hard to know what interactions might arise between the various apps and the Linux audio stack and kernel hacks unique to Bela. You're introducing many layers of complexity that might get in the way of just computing samples efficiently and driving a DAC.

On the other hand, we may get to a point where running full Linux might just be fast and stable enough for realtime audio that no one will ever notice. Having a full Linux box is really nice for more advanced stuff like networking, bluetooth, usb, etc. But again is that stuff really needed for something that is just trying to do audio dsp as efficiently as possible on a small piece of hardware?

#58

Yeah this. I am totally ignorant and incapable of actual technical knowledge so my judgement is based in hearsay but i found the idea of a MCU running one specific program without all the OS memory management and everything else that comes with it very tempting. I also read what urklang described, that only some very recent hacked linux distributions were able to work with realistic audio latencies. Iirc basically bela only? Even boot times alone seemed to always be 5-10x longer on organelle etc.

It also is an emotional opinion for me i think, a linux system would kinda be a countermovement to my wish of getting away from computers.

#59

latency wise bela beats everything i have seen. they run xenomai, which basically takes over the whole cpu for just the running program. the approach to use linux is great on bela because you can easily integrate addons (sensors, mice, keyboards, etc.) if there is a linux driver.

they also support a myriad of programming languages:

supercollider
c++
pd via libpd (at somewhat increased latency i think)
pd thru heavy (VERY efficient speed wise)
faust (also c)
etc...

#60

NI see what you are saying but the idea of a mouse and a keyboard is what i personally don’t want...

I want knobs and buttons only. Maybe a tiny oled to display 1-2 values.

I am aware other people might have other visions. But tbh if you go linux with a mouse and keyboard, why not just use a mini pc w linux/pd right away? I think thats one of the things that sets a platform like axoloti apart. There are plenty of platforms already that do what you describe right? Why make axoloti another one instead of something unique?

To be a dick about it, just use bela if thats what you want :rofl: sorry

#61

mouse and keyboard was a stupid example. make that OLED and accelerometer. as long as somebody has used it on linux, it will probably work