Running Axoloti on an Audiothingies P6

#1

I hope this is not considered subversive activity, but I've been spending a couple of nights getting the Axoloti firmware to run on an Audiothingies P6. While I have an Axoloti Core and will put it to good use as well, the P6 has the advantage of having a nice user interface and case ready made, so I feel it will be great for small synth or MIDI processor experiments.

The modified firmware can be found on my github page (it's on the p6 branch of a fork of the main Axoloti repository). (It's work-in-progress, so I'll be rebasing and modifying it from time to time). Since they use the same basic processor (STM32F4) the amount of porting is minimal, and mostly concernes the different peripherals used in the P6 compared to the Axoloti Core. (CPU-wise the Axoloti Core uses an STM32F427, but development was started on the STM32F407 used on the ST DISCOVERY board, and the P6 uses an STM32405).

So for it mostly works, but of course things that are related to Axoloti Core specific hardware don't work. (The P6 has no SDRAM or SD card slot, no audio input, and no USB host connector. The DAC is different, but luckily it was fairly easy to piece together a driver from the various DACs supported by various incarnations of the Axoloti firmware which are still in the repository.) Patches can be uploaded (and stored in flash), and run with no problems. Uploading firmware needs to be done by putting the STM32F4 in DFU mode, as the Axoloti normally uploads the binary to SDRAM first (which the P6 doesn't have) before flashing.

I'm working on a couple of Axoloti objects that will be enable the use of the LCD (a standard character based LCD), and the buttons, encoders and LEDs. The onboard I/O on the P6 is connected serially using a couple of 74HC595's (for inputs from the buttons and encoders) and a 74HC165 (for the LEDs). As can be seen in the picture, the LCD driver has reached some form of basic functionality. The P6 also has a small onboard serial EEPROM which can be used for patch storage which I have not yet gotten around to writing an object for.

p6-bk-running-axoloti.jpg1024x768 127 KB

Alternative hardware as target
Running Axoloti on a PreenFM2
Creating A Menu System
#2

awesome work great idea

#3

I'm always so impressed by you microcontroller hackers. I was actually thinking something similar last night as I was playing with my Midibox. The MB Core, being based on a Discovery+breakout board is very big for what it does and I was thinking MIOS32 on the Axoloti hardware would make a nice compact Midibox formfactor. Kinda the reverse of what you've done.

#4

There were two main issues with porting Axoloti to the P6. The first is the actual MCU configuration, but as the Axoloti once started out running on a Discovery board whose MCU is very similar to the P6, a lot of the code was already geared toward the Discovery, the only thing that really needed to be done in that respect was adjust the crystal frequency (in the P6 it's 12 MHz, on the Axoloti it's 8, but thanks to the Chibios OS that Axoloti uses, it was just a question of changing 8 to 12 in a couple of places. There were a couple of hickups with this, as there seemed to be a default 8 MHz setting somewhere which meant I needed to include a couple of extra files in some places to bring in the correct definition.

The second issue is that the peripherals are on different I/O pins in the two systems. The STM32 is rather modular in this respect, so it's very simple to change a serial port assignement for instance. The STM32F427 used in Axoloti has more I/O pins than the STM32F407 used on the Discovery, so I would think it wouldn't be too difficult configure MIOS32 I/Os for Axoloti hardware as all the pins available on the Discovery should be available on the Axoloti. The real problems are with pins that clash, for instance, the Axoloti has a serial debug port, but on the P6, none of the free pins can be assigned to a serial port, so I can't have any serial debugging on that platform.

#5

I don't consider it subversive, I just hope people using this fork will have the right expectations: no sdram, no sdcard, no audio in, and a different processor. Also the control interface in development uses a 128x64 graphical display, that can't be emulated on a 16x2 character display.

#6

Thanks Johannes, yes, it's important to underline what will not be possible with the P6 due to the lack of peripherals on that platform. I'm not sure if the different processor will actually make any difference though. The STM32F427 on the Axoloti seems to have more RAM than the P6's STM32F405 (256k vs 192k), but it doesn't look like it is actually used, looking a the .ld file.

What support is there currently for a 128x64 display? I thought that came with the Axoloti Control which is not yet available. Or is there support in the Axoloti Core firmware for directly controlling that type of display?

#7

most of the ram is used, there are a few segments not being used yet, but thats just a matter of changing the ld file. (we may want to reserve some for data held between patch switching !?)

i think the sdram/sdcard usage is down to users/use-cases, its pretty important if your into samples/wavetables for example... similarly the sdcard is very useful so you can switch between patches.
but as always, it depends what you want to use it for...

the lcd display support, if you look in the firmware, you will see it builds the display there, and then sends it to axoloti remote (currently hosted on the computer). so I guess thats the plan for the hardware.
BUT, i would say you don't need to do this, and in fact, on the push , i turn this off... as instead I just access the parameters directly and have my own display code in the push object... this is the model you can follow for the P6.
Interestingly for the push 2, I'm have to make a bit of a decision in this area...
the Push 2 has to be hosted elsewhere (Pi2/BBB), so I can either just send the raw data over usb to the BBB, and construct the display there, or do the axoloti remote approach. in practice, I will probably do the former, since the display is large on the push 2, so would take too much memory/time to construct on the core. (imho)

... of course one thing this does raise, is graphics support. Push 2 over Push 1, has really proven its nice to have things like mixer/waveform displays. so Id love to have that on Axoloti, which will be possible with a 128x64 display, imagine a nice little scope object on it :wink:

oooh, sorry forgot to say , great work doing this... we have seen axoloti hardware used alongside other hardware, but a first for running axoloti software on other hardware - very cool piece of work!

one though, I wonder how difficult it would be to go the other way... use the P6 controls/lcd, but use the axoloti core as the main processing/codec etc... i guess the main difficulty is lcd driver. and of course, your destroying a P6, which is not cheap.

btw: is the P6 firmware open source?

#8

I haven't looked in much detail, but In STM32F407xG.ld it appears there's about 44k (ram) + 8k (SRAM2, for DMA) + 10k (CCMRAM) assigned, which is less than 64k, whereas the STM32F427 used has a total of 256 kbyte of RAM. But perhaps some of the RAM (e.g. the RAM used for patch storage) is not specified in the .ld file?

Ok, I hadn't understood that. I'll have to look closer.

Yes, that makes a lot of sense, especially since the P6 has a similar character display and knob interface (albeit smaller) concept as the Push 1 in that respect.

Yes that would be nice. Especially since there already is a scope in the Patcher, a lot of the infrastructure must already be in place. And synths like the Korg Minilogue have shown how useful such a feature can be in the actual hardware.

Thanks.

Do you mean using the P6 as a remote UI (via USB for instance), or actually integrating the Axoloti Core into the P6, removing the P6 CPU and connecting the Axoloti to the P6 UI? I haven't thought about that, but it would actually be doable. The Axoloti board fits inside the P6 enclosure, and if the CPU, DAC and voltage regulators were removed from the P6, and the rear panel reworked, it would make a nice little package. The P6 is sold as a kit, so it would probably be better to purchase just the P6 PCB, mount the necessary components for the UI (most of which are on the top of the board so the Axoloti would fit underneath), and connect the P6 CPU socket to the appropriate Axoloti I/O's via wires. Definitely worth thinking about.

No, unfortunately not, which is one of the reasons I've been keen to getting the Axoloti running on it. I really like the user interface concept on the P6, and would like to experiment with synth design in that format. The whole concept of being able to implement a complete polyphonic synth on a microcontroller like the STM32F4 is very exciting, especially looking back and realizing that back in 1995 a synth such as the first Nordlead needed a DSP for that type of a job, and still only mustered 4 voices.

#9

@thetechnobear I've had 2 email conversations about this with the guy behind audiothingies about a year apart and in that time his mind has shifted from 'maybe' to 'not going to happen', he wouldn't tell me why. That's a real shame as I have an open-source-only policy in place for my tech (and especially music making gear) and the P6 is a REALLY nice synth...

the lcd display support, if you look in the firmware, you will see it
builds the display there, and then sends it to axoloti remote

The Control is supposed have its own STM32 micro, right? Wouldn't it be more efficient to only send it data and let it do the rendering on its own?

#10

yeah, the open source side is a complex issue, if you have products like this.
as it means people can completely bypass your products... and the reality is very few people who use open source products actually contribute to them ... so many developers feel like they are giving away alot, and getting little in return.

these days, I understand both sides.... and in fairness, we have to remember open sourcing your code is a huge gift to the community, and not a right (as some seemed to believe)

(I know I'm hugely grateful that @johannes was kind enough to open source such a huge amount of work!)

Im not sure if @johannes has said what his plans are.... Id have thought its more efficient to send data if it has a processor, but perhaps its going to be much simpler. I think Johannes has said, he wants to keep the cost of the control down, so perhaps something to help on the costs side.
anyway, Johannes is the one to answer that.

#11

We could get philosophical on the OS debate-

  • I like it mainly because you truly OWN your devices (meaning you can repair and modify them to your liking, without having to reverse engineer anything, or, as in case of the USofA, you don't need to fear the legal inferno for infringing the poor babies' software copyrights)

  • you don't need to TRUST a profit-oriented vendor

  • software crippling is nonexistent

  • so is planned obsolence

  • the code is of higher quality due to community scrutiny

  • communities are AMAZING at making stuff better

  • there are good ways to monetize OS ware, e.g. paid vendor support, sale of HW, sale of precompiled binaries (like Ardour does), etc.

As for the giving away- most OS project start off as either research or scratch-your-own-itch kind of thing and most OS developers would feel that once the work is done, it's better to share it with the world and perhaps make a few pennies in donations (and have the community improve your work at the same time) than hoard it for themselves and try to sell it (and probably fail).

Whew. With that out of my system, when a DSP device is involved, it's IMHO best to offload as much dirty work as possible from it into periferals, so the processing power isn't wasted on lower priority stuff. Do you by any chance know how's the Control coming along? There are no hardware files on Github or I've missed them.

#12

sure, thats one viewpoint...

sorry, I don't know how far @johannes has got with Control... Im sure he will announce something once its more concrete, or has a timeline in mind.

#13

I'd love to discuss this more, PM me?

#14

The Control will indeed have it own (low end) STM32 micro. That micro could handle character rendering, but in some cases you want more possibilities than 6x8 pixel characters, say, displaying a waveform. Rendering aligned text with a 6x8 bitmap font comes down to only copying 6 consecutive bytes in memory. I think it is much easier to manage the framebuffer on Axoloti Core, data transfer has really low overhead when using DMA. Even with framebuffer rendering on Axoloti Core, there are reasons to put a microcontroller on Axoloti Control: offloading led/switch matrixing, modularity, integration.

I'm redesigning the Axoloti Control hardware, will have a more compact layout than the old prototype. Similar to Axoloti Core it will be mostly surface mount components. I don't have a production timeline yet.

#15

sneak preview sketch

Pasted image946x321 22.4 KB

16 cm wide
yes, led collars around two encoders
128x64 b&w lcd in center
3 soft menu buttons left of the lcd
another 3 soft menu buttons right of the lcd
shift button
a single row of 16 buttons with indicator leds at the bottom

#16

I have an example where open source really helped - I have a Bitstream 3x, and some functions don't work as they are described in the manual. Since the source is available, I could see what actually happened to my downloaded configuration, why it didn't work, and what I needed to do instead, which fairly quickly put me back on track. With the Bitstream no longer being in production or development, it would most likely not have been possible to work it out otherwise.

Thanks @johannes for the sketch of the new Axoloti Control! I've been browsing the code in ui.c trying to understand how it works (as well as studying @thetechnobear's Push object). It seems that there is a fairly complete menu system set up in ui.c, complete with calls to LCD and user input functions, the only thing misssing is the actual remote device. Does the code as it looks now actually work as intended, or has it been used mostly for experimentation and as proof-of-concept?

The thing with the P6 is that its user interface almost ideal. When you press the Filter button for instance, the display shows the 6 parameters that the filter has, with the parameter names on the top line of the LCD and the values below. Mentally this just like focusing your eyes on the Filter section of a large front panel - think a Prophet-5 for instance - where all the filter knobs are. Thus the 'mental distance' from a "classic" front panel to the P6 UI is rather small. A UI which is more menu based does not have the same directness. Although this might seem like a small point compared to the capabilities of a fully patchable and editable system like the Axoloti, to me it is extremely important. To be able to quickly and intuitively modify parameters of the sound is what makes a synth come alive for me.

Of course, a synth is really primarily about sound, and I really like the sound of the P6, but having quickly patched up a simple to oscillator synth on the Axoloti I was equally if not more impressed by the resulting sound, as well as the DSP performance (with two oscs, a filter, a VCA and two envelopes I could tally up 14 voices before hitting the roof).

If the P6 had been open source I would have dived in on that platform, but as noted above it isn't, I too have questioned Samuel (the guy behind the P6) on this issue with the same result as @callipso above. On the other hand I find the Axoloti is an absolutely brilliant platform to develop on, not just in terms of patching, but also in terms of writing objects, so that itself is much more preferable to the probably completely source code based environment of the P6. I haven't spent that many evenings with the Axoloti so far, but the system itself seems very stable (modulo a quirk or two), and I have not yet crsahed it with the code in my objects - I'm not trying to say that I never make mistakes when coding, quite the contrary, although I haven't crashed the Axoloti per se, I've spent a lot of time debugging the code in my modules before they worked properly - rather that the infrastructure as such promotes code where any bugs introduced will only cause the object to misbehave, not bring down the whole system. Like I said, absolutely brilliant!

Getting back to the Axoloti, what I'm trying to accomplish is some form of similar UI which is not menu based, but where you somehow can configure a number of 'pages', each with up to 6 parameters (in the P6 case), where you can reach the pages using the buttons.

Thus what I need is some form of UI "engine", inspired by ui.c and the Push object. Somehow the parameter pages need to be specified in terms of:
- Which parameter does on which page and where it goes on the page.
- A short name for the parameter in question (e.g. RES for resonance).
One way would be to extend the existing parameter assignment to include some form of reference to page and location on a page in the UI, but that would require a few changes to the Patcher itself which I'm not prepare to dive into at this time. Instead my plan is that the object has as an attribute a table, which specifies the above things. Something along the line of a table of rows with the following contents:
Axoloti parameter ID, short parameter name, page number, parameter number on page
Instead of a string with the parameter ID, one way would be to go via CC numbers, so that the object finds out which CC numbers are assigned to the parameters, and uses those numbers as an ID to the parameter. The good thing about that is if one for instance swaps a module for another, the table doesn't have to be updated wih the new Parameter ID, istead, one assignes the CC number for a given parameter in the replaced module with to the corresponding parameter in the new module.

#17

Axoloti Control - I Like ... similar to axoloti core in dimension.
a few throw away ideas...
Id actually like a few more encoders (4 in total would be nice) , and I also actually really likes toms design using a joystick.... perhaps that could be used to navigate around the screen? not sure of its resolution, but might also be good as pitchbend/mod combined.
also the buttons, might be an idea to colour so a piano keyboard is indicted.. they are (I assume) not good for playing (?) , but still useful to have layout clear, if you are using to enter notes in say a step sequencer.
... but as I say random thoughts only.

I think the parameter tables still needs some work.... and the 'menu' system and parameters system are a bit dis-jointed at the moment. So Id expect they will need some tweaking for Axoloti Control.

the things I've raised so far are:
- hierarchy, the params to do not form a proper hierarchy (e.g. think submodules and params on them)
- units, the param table needs meta data about the units, so controllers can display sensible values.
- some params (particular sel tables) are not correctly assigned to param table.

... oh and Id like semi-real time data streams, e.g. so I can have scope externally... and perhaps even waveform displays.

basically, I think some of the 'info' thats in the patch, probably needs be in the param tables.
(that or I'm going to start parsing the patch on the BBB/RaspPI so I can then link it to parameter data)

there is another interesting side, which Ive personally not quite found the balance on yet, ... how much to rely on generic objects and patches, and how much to write custom objects

you could write a sequencer as a patch using the generic factory objects (sel etc), and then theoretically this could then be rendered by various controllers. but in practice, I think to create a really satisfying experience you are going to need to really tailor objects to the controller.
e.g. your not going to make a nice sequencer controller by a controller if you have to treat the various step controls as different parameters, you will need an object which binds step 1 controls together (e.g. gate/pitch/duration) , similar you will probably need to have conventions or dedicated objects, so that you have easy access to thing like global tempo/mix levels/sends etc.

my aim really, is I want to keep the patching very generic, yet have some common elements easily accessible.

anyway, busy with other stuff at the moment, but Im sure once Axoloti Control becomes closer, my interest and johannes will converge, as we start to need similar things :smile:

#18

Bitstream 3X has open FW?? Me needs it!

@thetechnobear Have you seen the Believotron concept?

EDIT: Oh sorry, now I see you've already posted there...

#19

It's on github:
https://github.com/waveidea/bs3x

#20

@johannes that looks bloody amazing! A control fitting over the Axoloti itself would make up for a fine compact box with everything! More encoders would be nice, but we can add as many pots as needed to GPIOs, so this is the best way to do this!