Axoloti release 2.0.0

#41

hmm... not on mine.... and its repeatable, if I clean the card ... then again write settings will fail.
anyone else on 2.0, can you also try...and report results.

@tele_player can you format your sdcard (or at least delete the settings folder) and try again
perhaps you already had a settings directory some how?!

Id ask what OS your on, but having looked in the java code, there is nothing there to deal with a dir hierarchy - so that means if it is handled, it'll be in the firmware which is not OS specific(!?)

note: it does create the midi-out/midi-in subdirectories correctly, its just the top level settings directory its not doing.

#42

Interesting. I'm certain that I deleted all files and directories on the card on my Mac before I tried it this morning, and had no trouble with Write Settings.

Now, I do the same thing, and it fails.

Ahhh, pre-alpha software.

EDIT:
So , after a few more tries, all ending with fail..
I unplug, replug the USB
Start Patcher
Load the screamer patch
Save patch to SD (NOT as startup)
MIDI 'Write Settings' - SUCCESS, no crash
Verified with Axoloti File Manager /settings and it's subdirectories.

#43

its a fairly simple bug to fix... Im just wanting to confirm with johannes how he wants it to fix.

generally, im finding most things are working fine, but there are a few things around the edges.

this is the kind of bug easy to miss in dev, since johannes will have a long time ago created the settings folder, and probably just didnt thing to format the sdcard again, and try from scratch - easy to do.

oh, utils/format object needs updating @johannes :wink:

#44

It looks like osc/brds/csaw isn't working either

#45

can you be specific.
(not compiling? or now sounding as expected?)

I've created a GitHub issue to track factory (only!) objects that need revision for 2.0.0

if you find an object that is not compiling, add a one line comment with object(s), and if its a compilation issue or something else.
keep it brief, its just an overview at this state... a kind of simple to do list

#46

Deeinstalling the old Axo1.0 solved the Problem.

#47

build.sh fails on Fedora 31. I hit the same issue building Axoloti-1.0.12-2 but the fixes didn't carry over to 2.0.

In file included from /home/ryanpg/src/axoloti-2.0.0/platform_linux/../ChibiOS_19.1.3/os/common/startup/ARMCMx/compilers/GCC/crt1.c:25:
/usr/lib/gcc/arm-none-eabi/9.2.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory
9 | # include_next
| ^~~~~~~~~~
compilation terminated.
make: *** [/home/ryanpg/src/axoloti-2.0.0/platform_linux/../ChibiOS_19.1.3/os/common/startup/ARMCMx/compilers/GCC/mk/rules.mk:178: build/obj/crt1.o] Error 1

#48

I don't plan to migrate personaly to 2.0.0 at the moment but I'd like the "community objects" i have shared to be available to 1.0.12 and 2.0.x users.

Amongst these evolutions, what is back compatible with 1.0.12 ?
What are the guidelines for the contributors ?
Should 2.0.0 compatible objects be tagged in a way ?

#49

In the real world, making code which operates under different API versions involves using precompiler tests for conditional compilation, based on manifest constants supplied by the build environment (in other words, #define's and #ifdef's).

It's tedious under the best of circumstances, with documented APIs.

#50

The community library is ‘forked’ with each release.
So you can commit versions changed for 2.0.0 without fear of breaking 1.0.12.
So I’d not bother with backwards compatibility generally.

With a small and dynamic community like axoloti , I think moving forwards is the best strategy rather than trying to spend undue effort supporting the past. (*)

(*) Of course 1.0.12 continues to work unchanged
, so we are not talking about breaking things - so those on 1.0.12 can stay there until they are happy 2.0.0 is stable enough for their needs.
Those who want to help move axoloti in can progress to 2, and help achieve that stability :slight_smile:

Technically,
objects that are saved with the 2.0.0 editor, are ‘upgraded’ to 2.0.0 and so are not loadable by older versions on axoloti.
So things like using #ifdef won’t help much :wink:
( Axoloti reserves the right to change the xml format , not sure if this happens in 2.0.0 or not, but it does update the object version tag to prevent loading in 1.x)

Note: many objects developed for 1.x will continue to work unchanged in 2.x

#51

Exp and Log functions don't work for me. Console says:

Patch failed to load : failed to load patch
Can't find address for symbol expt (1)

after compiling.
Using windows version.

#52

If you find factory objects not working add to this GitHub issue.

#53

Experiencing the same with expt and logt functions. For SINE2TINTERP I get the following error message:
/opt/Axoloti/app/api/axoloti_math.h:199:26: error: expected ')' before ';' token
199 | output = sin_q31(phase);

Can't see any missing bracket in axoloti_math.h though. Something to look at for the developers?

#54

Nice work and good news at beginning of the new decade.

Installation of 2.0.0 and arm crosscompiler went effortlessly on Kubuntu 19.10.

I'm very curious of the tiny soundfont player port. How can I test it?

#55

Hi, a bit late for the party, but I'll try and catch-up.

Install and upgrade went well on windows, and so did the first few patching sessions I've had time to do.

I was wondering, are there any example / demo project files that show how this "multiple patch running simultaneously" function is supposed to be used. I suppose you need the use the new patch/bus objects, but I can't seem to get my head around it yet.

Anyway, thanks for the hard work johannes, it sure seems like a nice path you're taking us on.

#56

I saw that the new release adds MIDI Sysex support to the Axoloti. Is there an object for this?

How would I go about implementing sysex messages in a patch?

Thanks.

#57

this is awsome many thanks :grinning:

#58

I have a few projects to finish before having time to delve seriously into 2.0.x to "transition" my objects.

I will switch to 2.0.x by june if some features are implemented by then (i.e. if 2.0.x is "moving forward", to me, usb hub support is kind of mandatory to move forward on the Axoloti platform).

#59

.deb packages of proper version of ARM toolchain for Ubuntu are available here
(if you don't like to add stuff to your system bypassing the package manager):

http://ppa.launchpad.net/team-gcc-arm-embedded/ppa/ubuntu/pool/main/g/gcc-arm-none-eabi/

edit: just installed two packages, gcc-arm-embedded from the link above, and axoloti-linux — and everything works like a charm.

#60

two questions about MIDI routing.

1) are PA2 and PA3 pins still usable for MIDI connectivity with 2.0 ?

2) so, 8 virtual MIDI ports, and this is hardcoded, so no easy way to change the number of them — do i understand it right?

seems like in 2.0 i'm missing some low level capabilities for handling such devices as e.g. Miditech Midiface 8x8.