Why does my demuxer eat so much SRAM?

[Captain_Burek]

I have eight hardware controllers (pots) that I want to demux so that, say, on setting 1 they controll two ADSRs, on setting 2 they control the effects, on setting 3 they control all things filter etc. For that I wrote the attached subpatch (which I though was pretty nifty ), which works fine. But obviously I need eight of those in my main patch, yet, once I put several of them in (how many depends on the main patch), I get "region `SRAM' overflowed".
Not being a programmer, I wonder what in that patch could be so taxing, and, naturally, how I can do what I want, instead.

control.demux8.axs (5.5 KB)
and two slightly modified objects used in that patch
demux 9.axo (4.5 KB)
mux 9.axo (1.5 KB)

Oh, and just for completeness a quick main patch to test this in:
demuxembedder.axp (2.3 KB)

[jaffasplaffa]

Hey @Captain_Burek

Just looked at the patch. I think it can be simpler. But need to make sure I get in correctly:

You simply just want a demuxer, where you can select which output the input is routed to?

Do you have a 9th parameter to use for "page" changing? If so, is that a knob too?

What is the purpose of the second muxer on the right side?

Also wondering why the cables in the demuxer is routed back into itself?

(This is not to critique anything, just making sure I understand what you want to do)

[thetechnobear]

I can create loads of them without errors
(btw: if you adding dials and ui, those do have an overhead)

PS. when posting on the forums its a better idea to embedded objects and subpatches,
its a right pain having to copy people objects into the objects folders = less people will try it

also id recommend you post an example where the error already occurs.

[Captain_Burek]

Hi jaffasplaffa & thetechnobear

thanks for the quick reply. So below is (my slight adaption of) TSG's Buzz Synth, with the demuxed copied in. Note it's set to 1 voice polyphony, so without the demuxer its runs at 51%. The sixth copy of the demuxer pushes it over the edge for me. Is this what you mean about embedding, technobear?

@jaffa: the extra stuff is there so that i) the outlets keep their values when not selected, and ii) the outlets don't jump when selected, but only latch on when the pots cross the outlet's current value; so if you can simplify it while keeping those features, i'd be real curious & grateful (as I said, i'm a newb)Buzz - MPE Synth.axp (106.8 KB)
.

[Captain_Burek]

@jaffa: The ninth output (i.e. o0) is just a dead end. When you switch to, say, 5 (ie.6) , the demuxer goes temporarily to o0 until the input actually hits the previous value of outlet_5 (thats what the second muxer is for, so you get to compare the newly selected outlet to the current input; that one switches immediately on inlet i's change), then switches the input muxer to 5. Does that make sense?

[thetechnobear]

Is this what you mean about embedding, technobear?

no , you are able to embed both subpatches and objects into a single patch.
click on the object/patch and the right click, and you will see an embed option.

what do you mean by runs @ 51% , cpu usage has no bearing on memory usage (e.g. sram)

i need to see a simple example where you can demonstrate this subpatch/objects are using a lot of sram, so far, it doesn't look like it to me...but hard to say without at example.

[Captain_Burek]

no , you are able to embed both subpatches and objects into a single patch.
click on the object/patch and the right click, and you will see an embed option.

re embedding: that's what I thought I did. (If I click on "embedd as patch/object" on my demuxer objects (not the subpatch!), the objects end up with an "edit" button, no "update", but I suppose that's normal for objects)

Anyway, I played around some more and found that I can run exactly 51 demuxers in an otherwise empty patch, but not 52. Each added demuxer adds about 580bytes to the overflows. By my calculations that means that one instance uses up around 580 bytes, and the total sram is about 30K, which in turn means that any patch that won't tolerate even eight of them uses over 25K in sram already.

Not knowing the first thing about what needs sram and what doesn't, I suppose I will just take that to be a normal sram usage and look for things like dials and displays to eliminate in the main patch.

Sorry if that was a wild goose chase, I'm learning...

[jaffasplaffa]

Yeah it seems like a lot of memory for some switches, I agree.

@jaffa: the extra stuff is there so that i) the outlets keep their values when not selected, and ii) the outlets don't jump when selected, but only latch on when the pots cross the outlet's current value; so if you can simplify it while keeping those features, i'd be real curious & grateful (as I said, i'm a newb)Buzz - MPE Synth.axp (106.8 KB)

Ah yes, I actually did the same in my own patch, just forgot about it.

You also set presets to 0 in the subpatches so that cant even be tweaked to gain more SRAM overhead. Hmm. Sorry dunno what else to suggest here.

I did something similar for The Modular thing controller board a while ago. I dont know if its more effective than your version, but maybe you can get some inspiration to try another approach:

MusicThingModular Controller subpatch

Try this one out. I have made a test version for the 6 knobs. You use the first button on the right to choose between layer 1 & 2. It is pretty sijple to add the last stuff from here. Or else you can also check Tom Whitwells patch on Github. It shows how to set up everything. You need to use @hellcores hookmod object for this patch to work. There are 2 versions. One that uses the cv from the gpio directly and one that converts the gpios to midi cc. Layer 1 is midi cc 1-6 and layer 2 is midi cc…

[Captain_Burek]

Just in case anyone's interested, this is my final version, a little simpler still (once i figured out the whole left-to-right thing):
8way_control_demux.axo (22.2 KB)
I suspect it doesn't get much simpler/smaller than that, but then apparently the sram footprint wasn't that unusually big to begin with. So I am considering this issue closed.

I also made a version of this with 8 strings included, which is useful if you have a display. I am using it with tiar's OLED display object.
8way_demux_w_string_outlet.axo (22.9 KB)

Since I also want to add the actual values for the params on the display, I modified tiar's f_to_c object. This plays well with the demuxer with strings:
combinestringwfvalue4display.axo (1.3 KB)

I opted for only 2 digits without decimal points, so the name can be 7 characters long. In fact, it has to be 7 chars long, otherwise the value disappears to god knows where, so add spaces as you see fit (longer doesn't hurt). I can't figure out for the life of me is how to make a short string longer in the object by adding spaces. Suggestions welcome.