Reaching SRAM limit

#1

Hi folks,

I'm building a sequencer with the Akai Fire but I'm reaching the SRAM limit.
I've attached the patch here:Y-AkaiFire-Axo-1.4.1.axp (477.0 KB)
This version of the patch is still ok but if I had few objects, I reach the limit quickly.

Is there something I'm doing wrong? Maybe I could do things differently that hopefully could save me some more SDRAM?

Thanks for your help

#2

There are some objects missing. You probably have them in your local folder, which means that we can not access them.

That a side, are you sure you don't mean SRAM instead of SDRAM?

From looking at the patch, for SRAM savings:
You have a ton of subpatches, where you can change the amount of presets to 0 along with how many params can be included in a preset. Doing so, will lower SRAM use a bunch. To do this:

  1. Open a subpatch by pushing "edit" button on the subpatch.
  2. Go to the "view" drop down menu and choose "settings".
  3. Make these settings from the image:

If you do that to all the subpatches, you will save a lot of SRAM :slight_smile:

But for SDRAM, I am not sure, I don't see anything using a lot of SDRAM.

#3

You are absolutely right. I was referring to SRAM (not SDRAM).

... and THANKS A LOT for your answer. I totally forgot there's settings for each sub patches.

:yum:

#4

Topic title edited from
Reaching SDRAM limit
to
Reaching SRAM limit

#5

So I ended up doing that for all sub patches and it didn't really change anything ... :thinking:
Here's the updated version:
Y-AkaiFire-Axo-1.4.2.axp (496.8 KB)

#6

That was my best suggestion, by looking at it shortly.

I can't go to much in depth when I can't make the patch live and don't have the right midi controller.

But I am sure there are things you can do. It does seem a bit heavy when I load the patch on my Mac. It takes around 10 seconds to load into the editor. Never tried something that slow before.

But yeah, not sure what to suggest next.

#7

Yeah. Maybe this is a bit ambitious. I'll wait for the Akso to push it a little bit.
Thanks for the help anyway.

#8

I am sure you can optimise it. Everything can be optimised :wink:

I would suggest looking into making something using tables, using SDRAM for the tables. That way you can offload the SRAM a bit.

Like for example you can make something for the akai midi controller, where all the parameters are send through a table and store the values there, before sending the values to it's destinations. You are using many midi inputs. Maybe you can actually do with just a single midi input, and write the data to a table, based on which cc is selected. CC1 write to index1 of the table, cc2 writes to index 2 of the table and so on. And then use table read to read out those specific value for the specific indexes. I think you can save a bunch that way too.

Anyway, its not uncommon to rebuild something, in a smarter way, once you have learned more. I have a sequencer for Pure Data that I have been working on for 4 years, build/rebuild numerous times. In the start it was functional but very badly written. So I rewrite it over and over until it worked very well :slight_smile:

#9

This probably does not apply here, but when using classes and functions, you can avoid inlining to save memory:
void __attribute__ ((noinline)) myfunction()
That saved me about 10kb once.
My thinking is that it is OK to do this for anything that is not called in a tight loop / high frequency.

The worst offender using lots of SRAM from my experience are nested patch-objects.

#10

I ended up testing the difference with and without nested patch-objects and as @ivofx said, using nested is a lot SRAM consuming.

I usually use patch/patcher mostly for a better reading of my patch and to avoid having a huge messy patch.
As a Max/MSP user, [patcher] object is super useful in this way.

Now I want more SRAM so I have to compromise. I'll probably rebuild the whole thing but I'm struggling on how I should get my patch organized.

What should I do? How do you manage big patches?

Thanks for the help