Need help with SRAM usage and custom objects

[mrtata]

Hi all axoloti lovers,

I'm currently facing some problems regarding the use of SRAM. I'll explain my problem in this first paragraph, and then I'll detail my objects afterwards if you're interested.

I am setting up a workflow with 3 parts:

• the Axoloti, with a display, four potentiometers and two extra buttons to change presets.
• a Faderfox EC4 midi controller that I use to control the necessary parameters
• Bitwig running on a Surface Pro that allows me to send modulations to the axoloti (and generate sound/fx, but not important here).

To achieve this, I had to make some custom objects, mainly subpatches, or sometimes by coding/modifying objects directly, but my coding skills are relatively limited.

All these objects consume a lot of ram and leave very little room for the rest. I hadn't anticipated this, unfortunately.
So I was wondering: Does coding "native" objects use a lot less resources than subpatch objects?

For those who are interested, here are the custom objects. I also put the result of this workflow at the end with an example of a patch using the DX7 object made by sss:

subpatch 1: axoloti physical interface

Role:
- send information to the screen (scope + name of the current patch and preset number)
- retrieve the values of the analog buttons
- retrieve the values of the buttons preset and patch changes

subpatch 2: midi cc interface (sd or hd version for 14 bits nrpn)

An instance of this object has to be created for each parameter I want to control. I can choose between an "SD" version for standard 7bits midi cc or an "HD" one for 14 bits midi.

Role:
- retrieve midi values (sd or hd)
- retrieve the modulation value
- retrieve the preset value
- if the preset value changes, send this value back to the Faderfox EC4
- smooth these values

subpatch 3: Getting modulations values from Bitwig

I use Bitwig to modulate the parameters that are accessible from the Faderfox. So I need this object for each pages of the Faderfox.

Role:
- retrieve modulation values via specific CCs
- smooth these values
- centralise all the modulations in a single object

Result:

Full setup:

FM Patch

(here I cannot add the second "modulation" object for the second voice due to the lack of ram)

Faderfox EC4 page for the first voice

Modulations in Bitwig for the forst voice

The number in white below the CCs corresponds to the button number on the Faderfox EC4 (from 1 to 16)

Thanks if you have read this far, and sorry for the long message!

[jaffasplaffa]

I think your problem is the SRAM not the SDRAM. SRAM is used for loading objects, sort of. And the SDRAM is for tables, delays, etc.

You can check this thread for some optimisation tips for the SRAM:

Saving sram tips

There's all sorts of alternatives or things to change to save sram in a patch. I just saved 700 bytes by editing all my mix objects. I left out all the bus inputs and all the gain controlls. Using tables (like with jaffa's table2) instead of wave/play is also a real sram saver. Using midi/in/cc instead of midi/in/keyb note for my buttons saved me some more sram. Also putting objects in subpatches uses up sram too. Anybody else got some tricks to save sram? P.S: I am making a list of ho…

And this too, which is about order of execution and object placement:

The position of an object effects the amount of SRAM it uses?

I have a patch that I've been optimizing for a few days now. It compiles/loads fine currently, but it is right on the edge of using all of the available SRAM as I remove knobs, etc. in an attempt to eke out as much functionality as possible. So I move a CONST/i up to a different position in my patch and suddenly I'm over the SRAM limit by 32 bytes. I move it back and the patch compiles fine. Can someone explain this to me as well as best practices to mitigate SRAM usage as it relates to the …

For the object placement, I am seeing a lot of cables going upwards:
Cables going downwards or to the right = good
Cables going upwards or to the left = bad

Especially red(audio) cables going upwards or left is a no go, as it uses extra resources. I see many cables going upwards in your patch, so fixing that, might give you a little extra ressources

[mrtata]

Yes indeed it is all about SRAM, I changed the title.

I wasn't aware for the position of the objects having an influence on the amount of SRAM, this is a good tip!

And thanks for this ressource, I will try to optimise my patch/subpatches as much as I can. But I'm affraid I will have to remove some features.

Thanks!

[jaffasplaffa]

If you know some coding, I am sure you can optimise it further.

For example building several objects into one single object. That way you use less cables, which also uses ram.

Like for example these ones, those could me made into a single object and it would not be too hard:

That's just an example. If you can't do the code, then at least make the right order of execution for them, put all three objects at the same horisontal level in the right order, from left to right.

You can probably, if you make it in a bit smarter way, even drop all the cc in objects, by using a single common cc in object that does not need a specific cc nr, but uses a general midi in object and then out to an output in some way.
.
I'd say there are many things you can try, before removing anything, so don't give up yet

[mrtata]

Thanks a lot!
this looks like something I can do, I will review everything as I think there is room for substantial optimisations.

[jaffasplaffa]

My experience is that since I started coding many objects into a single objects, I can push it a lot more before reaching the sram limits.

I think it's worth a shot

A good habit for making subpatches is always keeping inlets at the top of the subpatch and outlets at the bottom, like this:

[mrtata]

Thank you very much @jaffasplaffa for your help.
Now my patch is working without removing any features. I also learnt a lot about how to optimise the ram usage.

It is surprising how much the position of the blocks have an impact on this point. I also merged some objects as you suggested as well as removed all the unnecessary presets/mod source and target ect. from the subpatches.

Thanks again for your help!

[hitachii]

Something that I can't emphasize enough which will surely save you a lot of SRAM right off the bat is, as Jaffa mentioned, the execution order.

The patch is turned into code in order of the alignment of objects from left to right, top to bottom, imagine the shape of the letter Z. You want all of the gray bars that say the object name to line up if they're in the same row.

Any time that a cable is going up or backward, the value is held in the code until it does a full loop back to the destination object. Even if the object is one notch higher than the object before it, the Axoloti will interpret the object as being 'before' it. Big patches are much less pretty this way, but they save a ton of ram. Especially with red wires.