Sram overhead thorugh mod source code in subpatches?


#1

Since years I'm hitting the ram limits of axoloti. This made me for example completely avoid mod source because from my experience they are quite wasteful on ram. I'm still looking for new ways to limit ram and I was wondering if all this code that I practically don't need in subpatches is using up resources:

P.S. the same goes for presets, I don't really use them because I came with my own solution using tables.


#2

hey hooo!
...with the appropriate 1,5 meter of Berlin social distancing:
well RAM is my enemy as well, your screenshot is an embedded subpatcher,right?
it doesn't look so bad in terms of RAM,since it's all 'static constants'.
anyway, I'm not shure if embedding a subpatcher has a lot of benefits.

BUT, what I actually wanted to say:
BEWARE of using multiple factory 'table/save' or 'table/load' - objects,
these are using a lot of RAM, because each instance will load a lot of stuff into RAM individually.
I came up with this solution:

..they're already in the library, but ehem I'll have to document..and they are still a bit alpha.
basically,it's the 'SD/api' object that all the others are referring to. This is saving a lot of RAM:
When you have a lot of 'code-heavy' objects, it can make sense to move the 'heavy' part
to one object and just refer to the code from other objects.
I could elaborate via PM

cheers
R


#3

Haha :mask:

I always embed them so that I can move them around and share them and the subpatch is always there.

Not so bad ok, but every byte counts and I use lots of subpatches :wink:

Looks very interesting. Usually I try to squeeze everything on one table for that reason, but I have a patch that uses 3 table/load objects.


#4

nix mit PM freundchen,
please, this looks so promising, open a new public thread for documentation/developement of this?


#5

Angie said public threads with more than 2 persons are not alowed.


#6

digga!was geht?
...YEAH I will,
but there's already some posts releated to that issue, but they are rather
obscure for the non-coder I guess, and a bit spread out all over the forum...
but I will cook up something soon..

cheers R


#7

I putting the objects into practice, very nice.
But it only seemed to work with several tables if you do them one after the other, is that true rbrt?


#8

...seems to work here as expected,
patch attached


SDapi.axp (11.6 KB)

AAH!
..seems like you didn't put a suffix like '.txt' (or any other '.xyz'),
to specify the filetype...
possibly, 'fatfs' (the library in axo's firmware that handles SD-card IO) doesn't like this.
regarding my code,it doesn't make a difference