Axoloti release 2.0.0

johannes · 2019-12-19 01:03:23 UTC

It's been a long and deep process, finally I've reached the point where all changes converged into a new release. It hasn't been tested extensively yet, showstopper bugs may still exist.
The first one I noticed is that the software quits unexpectedly on Windows, immediately after initiating firmware flashing. The firmware flashing does work, but you need to re-launch the software.

USB hub support did not make it, I had it working (using the Chibios Community USB Host framework code) but noticed data drops on certain MIDI controllers. So that's rolled back to the implementation in 1.0.12.

My first priority is addressing showstopper bugs in this release, and migration from the 1.0.12 release.

Download link

From the release notes:

New in Axoloti release 2.0.0

Multiple patches can now run simultaneously
MIDI routing

Patches do not refer any more to specific MIDI devices and ports, but to virtual MIDI ports.
Physical MIDI in- and outputs are now routed to virtual ports via the "Midi Routing" dialog in the
board menu.
Midi routing settings can be stored on sdcard.

MIDI input monitor

Shows the content of the MIDI input buffer.

MIDI Sysex support
New objects patch/bus_mix and patch/bus_rcv

allow to route audio across running patches

Improved undo/redo
Introducing modules

Modules are dynamically loaded libraries, loaded only once when used in multiple patches.
They require an sdcard, and are located in /lib/libraryname.elf
Compiling and uploading libraries happens automagically when running a patch.

Audio input/output level meters
Improved USB protocol handling

Axoloti Core boards upgraded to v2.0 firmware can't connect to Axoloti v1.x software.
If you need to go back to 1.x after upgrading you need to downgrade to 1.0.12 firmware via the
board menu in 2.x, or do a "rescue flash".

Changes in general behaviour:

Compiled patches now carry an .elf extension (instead of .bin)
"controller object" configuration is gone

Since multiple patches can run, one "master" patch can be used to load other patches, for example in
response to program changes. It can also contain your effects section, midi indirections, or other
"utilities" you want to keep running.

Old compiled patches do not run anymore, sorry
MIDI i/o on gpio does not work anymore
When dsp load exceeds 98%, patches are muted
No more dsp load indicator in patch window

There is a global dsp load indicator in the main window instead.

Menubars are inside windows on Mac OSX, no useful menubar on top of the screen.

The trick that puts the menubar on top of the screen unfortunately causes some menus to stop functioning correctly.

Patches used to run in with a directory carriying the patch' name as working directory

This is no longer the case, it conflicts with the concept of multiple running patches.

Axoloti Runtime is no longer used, but installing gcc-arm-none-eabi manually is required.

An error message with download/installation instructions is shown at startup when missing.

Space characters in the installation path are not allowed on Mac OSX and Linux

An error message is shown...

Yet incomplete:

Several MI clone objects do not work anymore:
fx/lmnts/lmnts
fx/lmnts/string
fx/lmnts/tube
fx/clds/clds
fx/clds/pitchshifter
fx/rngs/chorus
fx/rngs/ensemble
fx/rngs/reverb
fx/strms/strms
fx/wrps/wrps

Those need to be adapted to use modules...

A preliminary port of tinysoundfont library to play soundfonts need further work

Object code transitions:

Static memory allocations to use sdram are discouraged.

Use dynamic memory allocation instead, cfr. ax_malloc in api/axoloti_memory.h

Object init code now has an integer return value (error code).

Return value 0 means "everything OK". Predefined error codes are defined in api/error_codes.h
Other return values will cause the patch to abort and report the error code.

Return statements without an argument will cause a compiler error.

MidiSend1(), MidiSend2(), MidiSend3() API migration

MidiSend1(dev,port,b0), MidiSend2(dev,port,b0,b1), MidiSend3(dev,port,b0,b1,b2) had a separate device
and port argument, now we only have a virtual port number.
Those calls need to be migrated to midiSend1(vport, b0), midiSend2(vport,b0,b1),
midiSend3(vport,b0,b1,b2).
Notice the lowercase m!

joaogatao · 2019-12-19 03:45:31 UTC

Wow, that's exciting. Thanks for the great work, Johannes!

I installed the new software (Ubuntu) and let it update the firmware. It's necessary to restart the program to also recognise the objects in the home folder. Then I got this error for every patch that I try to load:

Generate code complete
compiling /home/j/axoloti-2.0.0/build/xpatch.cpp
/opt/Axoloti/app/env/patch.mk:110: recipe for target '/home/j/axoloti-2.0.0/build/xpatch.o' failed
/bin/sh: 1: arm-none-eabi-g++: not found
make: *** [/home/j/axoloti-2.0.0/build/xpatch.o] Error 127
Compiling patch failed

And this on startup:

error: compiler arm-none-eabi-g++ not found in path=/opt/Axoloti/app/platform_linux/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin, not installed?

Something I forgot in installation maybe? How to solve this?

hellcore · 2019-12-19 05:03:03 UTC

Not sure about the Linux version but on windows, in the console, there is a URL to grab the toolchain needed. I'll guess you can grab it with apt.

joaogatao · 2019-12-19 06:28:30 UTC

Ah. I missed this in the release notes:

There is a package that can be installed with apt, but it's an older version. I found the latest version (gcc-arm-none-eabi-9-2019-q4-major) as a tarball, but now I don't know where to unpack so Axoloti can find it. Help?

EDIT: got it working in the following way:
$ tar jxf gcc-arm-none-eabi-9-2019-q4-major-x86_64-linux.tar.bz2 $ sudo cp -r gcc-arm-none-eabi-9-2019-q4-major/ /opt/Axoloti/app/ $ sudo mv /opt/Axoloti/app/gcc-arm-none-eabi-9-2019-q4-major/ /opt/Axoloti/app/platform_linux/

jaffasplaffa · 2019-12-19 07:32:27 UTC

Just want to make sure that I understand it correctly:

Does that mean that Axoloti 2.0 is not backwards compatible and no patches what we made in 10.0.12 will work in version 2.0?

janvantomme · 2019-12-19 08:49:26 UTC

Most patches should still work, but you'll have to recompile them. Patches using these objects won't work for now.

Guess I'll upgrade one of my boards for testing and leave the other ones on the previous version for now since I use some of those objects.

jaffasplaffa · 2019-12-19 09:40:37 UTC

What do you mean by recompile a patch?

lokki · 2019-12-19 09:49:26 UTC

just open it in the new editor and run

jaffasplaffa · 2019-12-19 09:51:28 UTC

Ah Okay. I guess that is given then. Thought they ment something else, that I was not aware of.

thetechnobear · 2019-12-19 12:05:48 UTC

excellent @johannes, I'll see if I can give it a test, and if I have issues I'll looking into either reporting or fixing

In particular I'll take a look at the module stuff, and look into resolving the MI stuff.

installation

ok, Im not quite sure what @johannes's plan is on how users are going to install gcc-arm-none-eabi
(or if we are going to recommend a version, since using the latest, might cause some oddities between users!)

once confirmed, I'll looking into updating the installation instructions where necessary.

EDIT : see post below this one- for simple install

if you use gcc-arm-none-eabi-7-2018-q2-update, and place in /Applications, then it will work 'out of the box'

following is useful if you want to use a different version of gcc-arm, or change where it is installed.

for now... here is what I did (macOS)
a) download gcc-arm-none-eabi
from https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

current is, gcc-arm-none-eabi-9-2019-q4-major, which I'll use for this example.

b) untar/zip it...
this can be done with apples archive utility, so pretty much should be just double click on it

creates a folder called something like gcc-arm-none-eabi-9-2019-q4-major

c) move to a suitable location
I personally would recommend (and use in this example) /usr/local
so we end up with

/usr/local/gcc-arm-none-eabi-9-2019-q4-major

d) add bin dir to path in axoloti preferences

additional path : /usr/local/gcc-arm-none-eabi-9-2019-q4-major

(following is uninteresting, unless you are planning on helping with axoloti development )

dev installation

(again macOS, possibly similar on windows?)
as before we use build.sh to build axoloti, but some additional notes

a) newer Chibios
if you have previously built axoloti, you will need to delete this to get it to redownload,
though frankly, assuming you dont have local changes, its easier to reclone the axoloti repo

b) arm-none-eabi-gcc
as for running axoloti, we now need to supply arm-none-eabi-gcc,
but command line doesn't use preferences,instead platform_osx/paths.sh contains the path expect to find arm-none-eabi-gcc,

it defaults to /Applications/gcc-arm-none-eabi-7-2018-q2-update/bin

ok, Id never put the compiler in /Applications, and ive a newer version , so I changed it to

#export PATH=/Applications/gcc-arm-none-eabi-7-2018-q2-update/bin:${axoloti_runtime}/platform_osx/bin:$PATH
export PATH=/usr/local/gcc-arm-none-eabi-9-2019-q4-major/bin:${axoloti_runtime}/platform_osx/bin:$PATH

@johannes we probably need to change this, otherwise, you'll get updates/PR with this line constantly changing as people reflect their own environment.

probably we should decide on a location (/usr/local seems natural on macOS these days),
then either
a specific version to support
or (and i think better) a symbolic link
e.g.
/usr/local/bin/axoloti-gcc-arm-none-eabi -> /usr/local/gcc-arm-none-eabi-9-2019-q4-major

this way, devs can keep diff versions of gcc-arm-none-eabi, and select one to use for axoloti (dev)

(this is similar to the way linux has a way to select default gcc etc)

(i'll raise an git issue, so we can device what to do )

thetechnobear · 2019-12-19 13:12:34 UTC

update to above

ok, so the latest version of is working fine for me

however, I notice a warning in axoloti, which implies that the expected version to be used is :

7-2018-q2-update

so... if you dont want to mess with anything then you can do the following

a) download 7-2018-q2-update from
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads1

so for the mac this is:
https://developer.arm.com/-/media/Files/downloads/gnu-rm/7-2018q2/gcc-arm-none-eabi-7-2018-q2-update-mac.tar.bz2?revision=982ef8a4-1815-4651-9c44-6144c9d8b34b?product=GNU%20Arm%20Embedded%20Toolchain,64-bit,,Mac%20OS%20X,7-2018-q2-update

b) unzip/tar

c) move this resultant folder to /Applications

thats it...
you do not need to change the path or anything in preferences as it is assuming
Applications/gcc-arm-none-eabi-7-2018-q2-update/bin

Id suspect something similar is true for windows.

Linux, im not sure of

dev... similarly as mentioned in above posts if you use Applications/gcc-arm-none-eabi-7-2018-q2-update, it will also work 'out of the box'

johannes · 2019-12-19 13:20:28 UTC

gcc-arm-none-eabi-9-2019-q4-major requires Mac OSX 10.13 at minimum, so I selected to standardize on gcc-arm-none-eabi-7-2018-q2-update, requiring only Mac OSX 10.7 at minimum.
I also ran into several issues with gcc-arm-none-eabi-8-2018q4. I have not tested gcc-arm-none-eabi-9-2019-q4-major.

Using gcc-arm-none-eabi-9-2019-q4-major should give a warning:
Unexpected compiler version: .... , expected 7-2018-q2

(On OSX) Why not? It's where users install applications. Axoloti-runtime used to live there too. /usr/local/bin is almost hidden from finder.

Direct download links are reported (via env/test-env.mk) when the compiler is missing.

thetechnobear · 2019-12-19 13:26:22 UTC

yeah, I only noticed this after completing the above post

because compilers are tools not end user applications, which is what I prefer keeping in /Applications

(it was a kludge that i put axoloti_runtime in /Applications )

anyway, as above, Ive put the whole gcc-arm-none-eabi-9-2019-q4-major in /usr/local

anyway, all cool...

I only noticed afterwards that you have assumed gcc-arm-none-eabi-7-2018-q2-update and its placed in /Applications ... thats ok, for most end-users! (and I can override so im happy)

p.s. I dont think you get the warning about the version until you have some form of gcc-arm-none-eabi installed... hence why I wasnt sure what the process was.
(is it generated by make which is not available till installed ? ... or perhaps i missed the error?)

thetechnobear · 2019-12-19 14:47:15 UTC

i think the key here, is remembering about startup patches, and also ones loaded by patch banks
(as ones you loading in via the editor will be recompiled anyway )

e.g. i noticed i was getting the following warning
unidentified header : 0x726F7841

I believe this was caused by an old startup patch on the board.

jaffasplaffa · 2019-12-19 15:02:26 UTC

Ah yeah, I see. I don't have any start up patch, as far as I remember, so that should not be an issue here.

Can I somehow reset a start up patch, so I can make sure there isn't any start up patch at all?

thetechnobear · 2019-12-19 15:15:20 UTC

Yeah there’s an erase startup patch option on menu. ( new in 2.0?)

jaffasplaffa · 2019-12-19 15:21:09 UTC

Yeah I think it must be a new feature in 2.0. I just looked for it in 1.0.12 and I don't see it there.

So I should probably try the new 2.0 out on one of my boards anyway

tele_player · 2019-12-19 17:10:09 UTC

Installed Axoloti 2.0 on my Macbook Pro (10.14.6)
Renamed it to /Appllications/Axoloti_2

Installed toolchain in /Appllications/gcc-arm-none-eabi-7-2018-q2-update/

Started new Axoloti app, flashed new firmware on my spare Axoloti.
Ran Library/factory/demos/synth/screamer
Success - yes it screams.

Tried to use format object to clean old Raspbian files off the SD card:

Done compiling patch
Generate code complete
compiling /Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp: In member function 'msg_t rootc::instanceformat__1::ThreadX2()':
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp:137:28: error: too few arguments to function 'FRESULT f_mkfs(const TCHAR*, BYTE, DWORD, void*, UINT)'
fs_error = f_mkfs(0, 0, 0);
^
In file included from /Applications/Axoloti_2.app/Contents/Java/api/xpatch.h:30:0,
from :0:
/Applications/Axoloti_2.app/Contents/Java/api/fatfs/ff.h:269:9: note: declared here
FRESULT f_mkfs (const TCHAR* path, BYTE opt, DWORD au, void* work, UINT len); /* Create a FAT volume */
^~~~~~
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp:139:3: error: 'sdcard_unmount' was not declared in this scope
sdcard_unmount();
^~~~~~~~~~~~~~
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp:139:3: note: suggested alternative: 'f_unmount'
sdcard_unmount();
^~~~~~~~~~~~~~
f_unmount
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp:140:3: error: 'sdcard_attemptMountIfUnmounted' was not declared in this scope
sdcard_attemptMountIfUnmounted();
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp: In member function 'void rootc::instanceformat__1::dsp(rootc*, int, int, int32_t&, int32_t&, int32_t&)':
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp:176:33: error: 'ThreadX' was not declared in this scope
NORMALPRIO, ThreadX, (void *)this);
^~~~~~~
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp:176:33: note: suggested alternative: 'ThreadX2'
NORMALPRIO, ThreadX, (void *)this);
^~~~~~~
ThreadX2
make: *** [/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.o] Error 1
Compiling patch failed

philoop · 2019-12-19 17:10:13 UTC

I tried win10 gcc-arm-none-eabi-7-2018-q2-update installed getting this error

korb · 2019-12-19 17:44:58 UTC

Same issue like @philoop

axoloti-win-2.0.0.msi