Oh no! Does this mean my patch is too big?

[studiokpg]

I just added two of my sub patches to a patch I've been working on, and I get this compilation error message:

Generate code complete
Start creating directory on sdcard : /Weasel Station 1
creating dir: /Weasel Station 1
Done creating directory
Changing working directory on sdcard : /Weasel Station 1
Change working directory: /Weasel Station 1
Done changing working directory
Start compiling patch
Compiling patch... with /Applications/Axoloti.app/Contents/Java/firmware
BDIR = /Users/karl/Documents/axoloti/build
FIRMWARE = .
RM
rm -f /Users/karl/Documents/axoloti/build/xpatch.o /Users/karl/Documents/axoloti/build/xpatch.elf /Users/karl/Documents/axoloti/build/xpatch.bin /Users/karl/Documents/axoloti/build/xpatch.d /Users/karl/Documents/axoloti/build/xpatch.map /Users/karl/Documents/axoloti/build/xpatch.lst
APP
arm-none-eabi-g++ -nostdlib -fno-exceptions -fno-rtti -mcpu=cortex-m4 -O3 -fomit-frame-pointer -falign-functions=16 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -Wunused-parameter -DCORTEX_USE_FPU=TRUE -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -mthumb -DTHUMB -std=c++11 -DARM_MATH_CM4 -D__FPU_PRESENT -fno-math-errno -fno-threadsafe-statics -H -I/Applications/Axoloti.app/Contents/Java/CMSIS/Include -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/common/ARMCMx/CMSIS/include -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/common/ARMCMx -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/GCC/ARMCMx -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/GCC/ARMCMx/STM32F4xx -I/Applications/Axoloti.app/Contents/Java/chibios/os/kernel/include -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/include -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32F4xx -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/GPIOv2 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/I2Cv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/OTGv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/RTCv2 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/SPIv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/TIMv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/USARTv1 -I/Applications/Axoloti.app/Contents/Java/chibios/boards/ST_STM32F4_DISCOVERY -I/Applications/Axoloti.app/Contents/Java/chibios/ext/fatfs/src -I. -I/Applications/Axoloti.app/Contents/Java/chibios -Winvalid-pch -MD -MP --include /Users/karl/Documents/axoloti/build/xpatch.h -c /Users/karl/Documents/axoloti/build/xpatch.cpp -o /Users/karl/Documents/axoloti/build/xpatch.o
! /Users/karl/Documents/axoloti/build/xpatch.h.gch
. /Applications/Axoloti.app/Contents/Java/firmware/../chibios/ext/fatfs/src/ff.h
LINK
arm-none-eabi-gcc -nostartfiles -Tramlink.ld -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mthumb -mno-thumb-interwork /Users/karl/Documents/axoloti/build/xpatch.o -Wl,-Map=/Users/karl/Documents/axoloti/build/xpatch.map,--cref,--just-symbols=./build/axoloti.elf -o /Users/karl/Documents/axoloti/build/xpatch.elf
/Applications/axoloti_runtime/platform_osx/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: /Users/karl/Documents/axoloti/build/xpatch.elf section .text._ZN5rootc3dspEv' will not fit in regionSRAM'
/Applications/axoloti_runtime/platform_osx/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: /Users/karl/Documents/axoloti/build/xpatch.elf section .sdram' will not fit in regionsdram'
/Applications/axoloti_runtime/platform_osx/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: region SRAM' overflowed by 16108 bytes
/Applications/axoloti_runtime/platform_osx/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: regionsdram' overflowed by 786432 bytes
collect2: error: ld returned 1 exit status
make: *** [/Users/karl/Documents/axoloti/build/xpatch.bin] Error 1
shell task failed, exit value: 2
Compiling patch failed ( /Users/karl/Music/axoloti files/Weasel Station 1.axp )

I assume this means my patch is too big . If so, are there any common suggestions about how to get rid of excess bloat in a patch? Is there a way to tell what parts are using the most memory space?
Thanks!
Karl

[thetechnobear]

have you checked out:

Using precious resources

Overview The axoloti board is a powerful board, but like everything it has only a finite amount of memory and processing power. The good news is axoloti is also very flexible, so there are lots of ways to get to similar results! Here are some tips about how to best make use of the resources it has. Memory SRAM is very precious on the Axoloti (used by table/write delay/write) , there is much more SDRAM available, use SDRAM alternatives of objects where possible (usually have sdram in the…

if you PM me your patch, I can take a look - see if there is anything obvious.

one thing thats notable is you are running out of both sram and sdram , the later is most likely tables/delays etc... so might be you need to think about reducing these.

of course, if your combining FX and synth generation, you could get another axoloti board, and chain them

[DazzlingDuke]

Don't fret!

I've had patches go over from adding one or two specific things, but will take many, many more objects. It all depends on how the patches compile and how the objects couple together.

It may be frustrating, but starting with one patch and then adding / removing things one at a time to figure out what is setting the patch over the edge has given me really complex patches. You may be something very small away from getting what you want. Often I just have to solve the problem in a different way.

Looking forward to hearing what you make!

[studiokpg]

Well, I've learned there are no easy answers! I took all the presets and mod sources down to 0 (after figuring out what that actually meant), halved the size of my loop table, and simplified some logic. My patch is based on rbrt's 4 slot loop station. The biggest culprit was the code to do button color feedback on my Launch Control. Each button required several flip flops, toggles, pulse delays, etc. depending on what I wanted it to do. I've decided to eliminate all that. It was very pretty and cool once I got it to work, but if the patch can't do what I want, well what's the point. So, with that out of the way, and having learned some lessons about simplifying, I think I can get it all happening. I'll post something once it is working.
Thanks!
Karl

[thetechnobear]

The biggest culprit was the code to do button color feedback on my Launch Control. Each button required several flip flops, toggles, pulse delays, etc. depending on what I wanted it to do. I've decided to eliminate all that. It was very pretty and cool once I got it to work, but if the patch can't do what I want, well what's the point.

one small tip on this... if your up to creating custom objects.

if you take this part of the patch, and place it into an embedded sub-patch, you can then convert this into an object.
the code produced is not 'pretty', but sometimes is a good starting place for refactoring and generally rewriting with the optimisation required.

important note: just converting to an object will not bring any gains, the gains come from the C coding you then do to optimise the generated code. I dont want to start a rumour that subpatches should be converted to objects for improvements - it wont, and makes your patch much harder to edit later
(general coding tip: optimisations like this are always best done once the patch is 'stable' and unlikely to change)

a second, advanced tip, related to custom objects and code bloat, which in some case can bring a big reduction in code size.

axoloti inlines as much as possible, since it is after speed optimisation over 'space optimisation'. this is normally what you want for DSP, as its time critical. BUT if you have non time critical code, you can avoid this optimisation in 2 steps
a) put your function in header file
b) where you declare your function add 'attribute((noinline)) ' to the end

I consider this an 'advanced tip', so not going to say more, except you can see i do this on my Push object, so use that as an example.
just remember this is for non time critical code, e.g. initialisation, midi handlers, or other things outside the audio thread... if you dont respect this, you might get audio dropouts

[Blindsmyth]

Hey I'm struggling with the same problem, also on a rbrt based looper patch.
Technobears tips on saving resources are great. I was lucky to have Johannes show me some at musichackday.
Execution order is really really important. A red upwards connection can cost you 64bytes of sram.

Two more things that I discovered when trying to make things more efficient:

All kind of scopes and disp will eat up sram. So once you're sure everthing works delete them.

When using midi controllers, using the midi/in/cc instead of a dial assigned to a cc eats up less sram. This might have to do something with first thepoint. Everything that gives kind of feedback back to the computer seems to take sram.

[thetechnobear]

if anyone has other tips for saving resources that are not obvious to others, please feel free to add them to the "Using precious resources' page (its a wiki page, so is editable, or you can post a follow up)

Note:'ve tried to keep it reasonably concise, as Ive few people read things that have alot of details/things they already know. feel free to edit/clarify if things are not clear.

[studiokpg]

I'm getting down to the nitty gritty. I got my patch down enough, and I'm trying to add back some things. I'm over by 2552 bytes!
One question - is there a better way to do a wait function? Here's what I'm doing...Wait3.5.axp (1.4 KB)

Thanks!

[studiokpg]

Ok, I think the patch is "done". I have learned a lot about optimizing resources! 2 things I would share are "never use a blue when a green will do," and "avoid running wires backward - especially reds." I think those two things saved me the most SRAM (besides the other things mentioned in theTechnoBear's great post.)
I have a 4 track looper (rbrt's) that I modified to sync to a master clock. It can have secondary loops the same length as the first loop, or shorter (but still quantized to the clock.) The master clock also drives rhythms on my Music Easel, so everything syncs up. I also have two effects, a delay/panner, and another panner driven by the Easel's sequencer voltages. The whole thing is controlled by a Launch Control XL with some button color feedback.
I'm going to post more about my setup in the "Your Projects" forum.
Thanks to everyone for your help!
Karl