Error when going live, Fixed by deleting object with Audio Outs. How to Correct?

[Stoss]

Hi.

I've got a recurring problem with trying to make my patch "live". I get a couple of error messages:

collect2: error: ld returned 1 exit status
shell task failed, exit value: 2

I was able to reproduce the problem with a super simple patch. It looked like this:

When I delete the 3rd reverb, it goes "live" with no problem. If I leave it in, I get the above errors.

I have been creating a much more complex FX patch with mixers, delays, etc... I have run into this problem where it seems to get to a maximum number of objects that contain audio ins and outs on them. My FX patch actually has more objects than this before it fails to go "live".

What could this be related to? Is it a limit on ins and outs or is there a problem with using multiple objects that are similar or come from a similar starting point?

Would love some help with this.

I have an Axoloti hooked up to my Apple iMac through USB.
Axoloti Firmware: 1.0.0.1
Axoloti Software: 1.0.6
Mac OSX 10.10.5

Thanks for the help.

[thetechnobear]

Compilation failures

Overview Errors that might occur when you take a patch live, you will see a RED error message at the bottom: Compiling patch failed (~Documents/axoloti/mypatches/test.axp ) If you then look a few lines up, will see the cause of the error, listed before are the common ones and how to resolve. Errors CCMSRAM overflowed by 85792 bytes The Axoloti board has a finite amount of memory (like us all) called SRAM. If you compile a patch that uses too much, it will give the above error (number wil…

the issue is stomps/reverb uses CCRAM, and theres not enough for 3 of them

copy the reverb axs file to a new name, and change it do use "delay write sdram " and you should be ok

[Stoss]

Couple of questions.

Is the CCRAM or SRAM (I assume they are the same here) the onboard storage space that all components of the patch are written to? I ran into the same problem and it was relieved when I deleted an object that had no delay writing involved, but contained plenty of other little objects within it.

Is the SDRAM also internal, or does that refer to using an inserted SD card for read/write tasks? I do not have a card installed yet I have some objects using that SDRAM.

Sorry for the questions that must seem quite rudimentary to some. I am a musician first and a technical dabbler second. Being persistent and stubborn though in hopes to make something useful of my Axoloti.

Thanks

[anon5189335]

When you have loaded a patch try go to View>settings and change all settings to zero, especially number of presets. Reducing these gives a little extra "headroom" on especially SRAM. It is also documented in here somewhere.

Like technobear mention there is also some things to have in mind. Like if you use delay, use the sdram version of the delay objects.

Is the SDRAM also internal, or does that refer to using an inserted SD card for read/write tasks? I do not have a card installed yet I have some objects using that SDRAM.

No, as far as I know it is not related to SD-card. I also though that to start with, cause of the names It is internal, but not using sd-card.

[thetechnobear]

yeah, sorry the terminology can be a bit tricky, as there are multiple regions of memory on the axoloti board.

SRAM, SRAM2, CCMSRAM - are all onboard and are pretty limited in size.
without going into to too many (boring) complications, these are used by things like the firmware local variables, static variables (by default)

SDRAM - is an 'extra' (yes unrelated to SDCard) , and we have a 'fair amount' of, in comparison to the onboard, hence why we recommend using it.

most of this only matters for things like tables, and delay lines which can get quite large,
so the general advice is to use SDRAM for these, and thus keep the onboard memory available for stack variables/firmware etc.

(of course if you allocate lots of large tables/delay lines as reverbs could, then you will run into a wall at some point!)

I think we should really probably move things like delay lines in the factory objects to SDRAM.
the reason this hasn't been done was to maintain compatibility with the discovery boards,
I don't think really this is a good reason now...
@johannes what do you think, change things like stomp/reverb to use sdram?

[thetechnobear]

yeah, sorry the terminology can be a bit tricky, as there are multiple regions of memory on the axoloti board.

SRAM, SRAM2, CCMSRAM - are all onboard and are pretty limited in size.
without going into to too many (boring) complications, these are used by things like the firmware local variables, static variables (by default)

SDRAM - is an 'extra' (yes unrelated to SDCard) , and we have a 'fair amount' of, in comparison to the onboard, hence why we recommend using it.

most of this only matters for things like tables, and delay lines which can get quite large,
so the general advice is to use SDRAM for these, and thus keep the onboard memory available for stack variables/firmware etc.

(of course if you allocate lots of large tables/delay lines as reverbs could, then you will run into a wall at some point!)

I think we should really probably move things like delay lines in the factory objects to SDRAM.
the reason this hasn't been done was to maintain compatibility with the discovery boards,
I don't think really this is a good reason now...
@johannes what do you think, change things like stomp/reverb to use sdram?

[Stoss]

When you have loaded a patch try go to View>settings and change all settings to zero, especially number of presets. Reducing these gives a little extra "headroom" on especially SRAM. It is also documented in here somewhere.

Is this something that only has to be done in the main patch or should it also be done within all embedded subpatches as well?

[anon5189335]

You should do it ESPECIALLY to the subpatches. If you have 10 subpatches and they all have these settings activated it will overload the SRAM pretty quickly. Using presets on the main patch is ok. I do that all the time. But keep the subpatches at zero. Unless you need them of course

[Stoss]

Ok... Thanks. That's going to help a lot. I've just been experimenting and building and building... Getting to some real great places! Now it's time to go back and do some clean up work.

[anon5189335]

Yeah. I faced those limits a lot in the beginning when I wasnt aware of it. if you want to check the documentation on it, look in "precious resources" under "presets/Entries":

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…

Yeah Axoloti is a small wonder It takes some time to get to know it well, but worth the effort. Had mine for a while now and still learning new stuff every day.