Ambika firmware with avr-g++ 9.1

[stefanovic]

[EDIT]
Well actually, there is not much thing to do to compile with latest avr-g++, I do not know why I spent the whole morning on it ?! Reparsing the forum and the github commits does not give much clue that it has been done already. As I suspected in my original post, I definitively missed something, sorry for the noise.

Anyway it seems that the sequence of instructions in the README.md file is sufficient:

git clone https://github.com/pichenettes/ambika
cd ambika
#  in avrlib/makefile.mk edit avr-gcc path
git submodule update --init --recursive
make -f controller/makefile bin
make -f controller/makefile size
________________________________ 
/  ____  _  _    __  ____   __    \
| | ___|| || |  / /_|___ \ / /_   |
| |___ \| || |_| '_ \ __) | '_ \  |
|  ___) |__   _| (_) / __/| (_) | |
| |____/   |_|  \___/_____|\___/  |
\                                 /
 --------------------------------- 
  \
   \   \_\_    _/_/
    \      \__/
           (oo)\_______
           (__)\       )\/\
               ||----w |
               ||     ||

Original post:

Hi,

following the work done by @machfour on avril for Midipal, I tested his modified avril with the Ambika firmware. I succeeded in compiling it with avr-g++ 9.1 (fresh from brew), and it seems to be working. I did very basic tests though, and @machfour did warn about potential remaining problems.

The nice thing about it is the size of the resulting binary:

Program:   52524 bytes (80.1% Full)
(.text + .data + .bootloader)

Data:       3796 bytes (92.7% Full)
(.data + .bss + .noinit)

text	   data	    bss	    dec	    hex	filename
52474	     50	   3746	  56270	   dbce	build/ambika_controller/ambika_controller.elf

This is smaller than with avr-gcc 4.x (by more than 9kb). And it’s including the BCR-2000 DataRequest feature. Plenty of remaining space to cram more stuff, then… Still, since this outcome is somewhat surprising, I may have missed or overlooked something (?)

I need to clean up the sources before making them available on github. Meanwhile, if someone wants to test it, I attached the firmware to this message…

cheers,

stéphane

PS: I changed the name ‘parameter’ for ‘morph’ in the osc section, as I was always confused with ‘parameter’ when seeing it (after all, a lot of things are parameters in sound synthesis, I was always thinking about something more ‘meta’ though it’s often related to the osc waveform with the Ambika)

AmBiCR.bin.zip (34.2 KB)

[machfour]

Yay, nice work!!!

I have been wanting to build an Ambika for a while… (I have the PCBs but haven’t ordered parts yet) so I’m really happy that you got it working! Bonus about the code size too.

[stefanovic]

thank you! and thank you for your work too! and pichenettes’ I guess since there are no more warning when compiling the Ambika firmware.

I have a Solaris and an Ambika. Since the solaris is not multipart, I still use the Ambika for bass and pad sounds… and its sound still amazes me each time I’m using it… The fact that the code is open-source feeds my GST (Gear Tinkering Syndrom) from time to time…

[Bjarne]

This makes me curious of how much work (if any) it would take to compile YAM with these gcc and avrlib versions. Even though all CPU cycles are exhausted it is always welcome with a little bit of space.
Cheers

[stefanovic]

@Bjarne I did it, but could not remember if it ever required any modification, maybe I forced the init phase of the submodule to grab the latest version of avrlib… I attach the resulting binary.

ambika_controller.bin.zip (32.9 KB)

cat ambika_controller.size | awk '{ print $1+$2 }' | tail -n1 | figlet | cowsay -n -f moose
     _______________________________ 
    /  ____ ____ _____ ___  _  _    \
    | | ___|___ \___  / _ \| || |   |
    | |___ \ __) | / / (_) | || |_  |
    |  ___) / __/ / / \__, |__   _| |
    | |____/_____/_/    /_/   |_|   |
    \                               /
     ------------------------------- 
      \
       \   \_\_    _/_/
        \      \__/
               (oo)\_______
               (__)\       )\/\
                   ||----w |
                   ||     ||

[stefanovic]

after a few tests, there are some things that do not work anymore:

• my SVF sound card does not produce any sound when uploaded with an avr-g++ 9.1 compiled firmware
• on the controller, while in the firmware update page, turning the encoder to browse through all cards/devices makes it hang: it’s because of the use of an int16_t version of clip instead of an int8_t. I may propose a patch to @pichenettes for this one

so there is still some hard corners on the controller, but they may be ironed out if properly diagnosed. For the soundcard it might be more tricky.

[Bjarne]

Thanks for the update
Cheers

[stefanovic]

actually no voice card works, regardless of their types. So far, I fixed two problems. I’m still investigating but here are the fixes for the record:

1. I added a Clip8 version of Clip in avrlib/op.h:

static inline int8_t Clip8(int8_t value, int8_t min, int8_t max) {
return value < min ? min : (value > max ? max : value);
}

to be used by the controller os_info_page:

uint8_t OsInfoPage::OnIncrement(int8_t increment) {
active_control_ = Clip8(active_control_ + increment, 0, kNumVoices);
FindFirmwareFiles();
return 1;
}

2. I changed the overlapping data-structure and bytes buffer in voicecard voice.cc

//uint8_t Voice::patch_data_[1];
Patch Voice::patch_;
uint8_t Voice::patch_data_ = reinterpret_cast<uint8_t> (&Voice::patch_)-1;
//uint8_t Voice::part_data_[1];
Part Voice::part_;
uint8_t Voice::part_data_ = reinterpret_cast<uint8_t> (&Voice::part_)-1;

There is still a problem though, when executing this line in Voice::Trigger:

modulation_sources_[MOD_SRC_VELOCITY] = velocity;

When compiled with avr-gcc 4.3, it works. When compiled with 9.1, the sound is muffled as if the velocity was 0… In fact, any of the following methods have problems when compiled with 9.1:

Voice::LoadSources()
Voice::ProcessModulationMatrix()
Voice::UpdateDestinations()
Voice::RenderOscillators()

Incidentally, they all use the modulation_sources_ static field of Voice… The thing is that it’s very difficult to debug, I painfully comment out line by line and try the firmware on the Ambika. I made a debug page on the controller to display various values, but it’s not accessible to voice cards…

[machfour]

One thing you should definitely check… make sure GCC warnings aren’t disabled in the makefile!

Check the GCC command in the makefiles, and if there is any -w flag used, you should delete it. Debugging was a great deal harder for me before I thought to check this. You might also like to add -pedantic and -std=c++14 flags, if you haven’t already.

If warnings aren’t disabled, what kinds of warnings are you getting, if any?

[stefanovic]

here is a excerpt of the compile commands:
/usr/local/CrossPack-AVR/bin/avr-g++ -c -mmcu=atmega328p -I. -g -Os -w -Wall -DF_CPU=20000000 -D__PROG_TYPES_COMPAT__ -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -DDISABLE_DEFAULT_UART_RX_ISR -DDISABLE_WAVETABLE_LFOS -DATMEGA328P -DSERIAL_RX_0 -mcall-prologues -fno-exceptions voicecard/leds.cc -o build/ambika_voicecard/leds.o

so you were right, I overlooked the -w option that inhibits all warnings :sigh:
ok, I’ll have another look when I have more time, maybe this week-end or next week…

Thank you for the advices!

[stefanovic]

so…

I tried with -Wall, fixed a few warnings, the most problematic ones being in oscillator.cc where the upper bound of a loop for formant was 4 instead of 3. No more warnings now.

still no luck with the final result though… The sound is “dirty”… The thing is, if I disable the mixing with the noise in voice.cc, the sound is ok. I still cannot find out why noise adds garbage, though my Ambika patch has a 0-level noise…
There is something funky somewhere… Maybe it comes from the operators in op.h. And maybe I should unit-test each operator… I tried to understand the assembler code, but could not find any obvious problem. Hopefully r0 and r1 are still tmp_reg and zero_reg…

I provide patches to this message, to be applied with patch -p1 < patch.diff.

avrlib.patch.zip (3.3 KB) ambika.patch.zip (2.2 KB)

[stefanovic]

for the record:
tried with avr-g++ 9.2.0 from https://github.com/osx-cross/homebrew-avr => does not work
tried with avr-g++ 4.9.4 from https://github.com/osx-cross/homebrew-avr => does not work
tried with avr-g++ 4.3.3 from https://www.obdev.at/products/crosspack/index.html => WORKS
tried with avr-g++ 5.4.0 from https://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-c-compilers => WORKS

I’m stuck now. I do not know how to debug this, I’m giving up for a while.

A hint maybe: I still do not understand why I needed to implement an S8ClipS8 for the controller, when browsing through voicecards in the OS info page. This may be a hint that the compilers have a different way to handle conversions between types, which may result in this strange behaviour when those conversions happen in the dsp code.

[stefanovic]

got it working!

turned out that the garbled sound was due to insufficient optimisation… -O2 is helping, at the expense of code size though. It seems that the latest versions of gcc change the optimisation trade off… That’s the reason why the controller firmware was so small with the latest gcc. But I guess the controller firmware does not need as much optimisation as the voicecard firmware…

In summary, we only need to:

• add -O2 to voicecard CPPFLAGS
• change the overlapping data-structure and bytes buffer in voicecard voice.cc
• do nothing about the “clip” thing, it was entirely my fault

while we are it, maybe fix what -Wall raised up:

• the interpolation of formant amplitude:

for (uint8_t i = 0; i < 4; ++i) {

should be:

for (uint8_t i = 0; i < 3; ++i) {

• in sub_oscillator.h, replace

*buffer++ = U8Mix(*buffer, v, mix_gain, sub_gain);

with

*buffer = U8Mix(*buffer, v, mix_gain, sub_gain);
++buffer;

• in transient_generator.h, replace

*buffer++ = U8Mix(*buffer, value, amplitude);

with

*buffer = U8Mix(*buffer, value, amplitude);
++buffer;

and that’s all. I will set up some github pull requests to Emilie.

Now on to the bootloader… Unfortunately, the resulting code size is 530 bytes, more than the original 506, I guess that’s the reason why avrdude complains.

[Bjarne]

Good work!

Note that when crackling due to insufficient optimization occurs, it does so depending on how computationally tough the patch is. Make sure you run tests with a “maxed out” patch. (For YAM this is probably using dual qpwm oscillator + sub oscillator + ring modulation.)

Cheers

[stefanovic]

You were right, some patches do not sound correctly… This is the case for 017 Flateric…

Don’t know what to do at this point, I guess this requires some disassembly abilities, which is a bit out of reach for me a this time without a substantial amount of effort…

[machfour]

Nice work. I intend to build an Ambika probably early next year once I am done with uni, so I will keep watching this thread for developments, and of course will definitely be getting my hands dirty with the firmware at that time

[TijuanaKez]

Yes nice work! I’m going to chime in here aswell and see if anyone noticed the notes in the Ambika ‘Live’ release. When I was doing the mods I needed to find a way to squeeze more in and noticed that while 4.3.3 seemed to be the only thing that would compile the voice cards, 4.5.1 seemed to compile the controller fine and save a heap of bytes in the process, and I never noticed and bugs with it.

Notes on building the source:

	- For the voicecard build to succeed, avr-gcc 4.3.3 must be used. Any later versions will build, but result in a silent voice card.
	- For the controller, avr-gcc 4.3.3 build will break our file size limit (61440 bytes)
	- But 4.5.1 will successfully build the controller and save us about 2700 bytes!!!

[machfour]

Hey all, I’m currently back and working on getting the firmware to work with GCC 9. I’ve done quite a bit of refactoring etc, but still am experiencing the same problems with getting the voicecard to sound nice.

The sound is quite distorted - but less so when I compile with -O2 rather than -Os, and some notes don’t play at all. It’s really weird because changing the filter frequency by one step at a time ‘mutes’ and ‘unmutes’ the sound. I think it’s something like: when the MIDI note value and filter cutoff value are both even or odd, there is no sound, otherwise there is sound … so weird!

My current hypothesis is that the processing can’t keep up with real time, but that doesn’t really explain the specific behaviour above.

I would like to do some debugging with a working firmware binary, but I need an ELF file with debugging symbols. Could one of you @stefanovic @Bjarne @TijuanaKez (or @pichenettes, if you can be bothered) possibly upload an .elf binary of a tested working voicecard firmware and compiled with GCC 4.3 with debugging symbols (-g) enabled? Many thanks in advance

[stefanovic]

Hi machfour,

lockdown;-) ?

sure, hopefully joined to this message, compiled with:

/usr/local/CrossPack-AVR/bin/avr-g++ -v

Using built-in specs.

Target: avr

Configured with: …/configure --prefix=/usr/local/CrossPack-AVR-20100115 --disable-dependency-tracking --disable-nls --disable-werror --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2

Thread model: single

gcc version 4.3.3 (GCC)

My last hypothesis was that ‘some’ optimization, which was included in gcc 4 with -Os, is not included anymore with latest gcc -Os.

I tried to review and compare the optimization list for each compiler (there is a switch that I do not find in my notes right now), to no avail, but I did not spend much time on that.

Good luck,

Stéphane

(Attachment ambika_voicecard.elf is missing)

[pichenettes]

ambika_voicecard.elf.zip (81.3 KB) ambika_controller.elf.zip (353.5 KB)