help on stereo audio matrix w/ extra switching capabilities

[rcrath]

Hi,
I built a stereo audio matrix with some extra stuff in it (here). It has two features designed to make live playing simpler and to save cpu cycles easily. The first is that a param can be linked so that if all cells in a particular column are off, then the processing mode of whatever is connected to that column's input will be set to mute or bypass, and if all cells in a row are off, whatever is connected to that row's output can set to bypass. The second feature is to provide a parameter for (hansjes?) tail group, which allows a bidule or plugin with a delay to finish its decay before switching the bidule off when it is switched off.

The problem I am having is that the group is eating up 10-20% of my cpu, which sort of defeats the purpose of a cpu saving group. Everything in it seems to me to be very processor UN-intensive. The math is simple, and it is really about just tediously hooking lots of little, low cpu things together. Can you guys take a look at the group and see if there is anything obviously hogging cpu, and of there is anything I can do to fix it?

BTW, the group has still been pretty useful. It does save some cycles, but I am doing the next iteration of my live layout and when I tried to use more than one of these matrices, most of the cpu cycles (80& for 4) were used up just by the matrices. I might be able to get by with the regular matrices for everything but one of them, but I'd like to figure out what is eating the cpu so much.

[rcrath]

mode control.png (3.63 KiB) Viewed 213 times

I'm going to try again here with a bit more detail, as this has me stumped. I have rigged up a stereo matrix to a bunch of triggers, one for each cell as shown in the big picture below. Each column and row is then hooked to a simple math group: if the column or row is equal to 0, then send a 1 to the parameter modulator, which is connected to the mode of whichever bidule is being routed through that row or our from that column. Thus if there is no signal on a column/input, the bidule fed to that col is turned off via a parameter link. Same goes downstream for outputs/rows. If you want something to stay on even when no input is coming in for example, on a live looper connected to an output of the matrix, which you might want to stay on after the loop is set up and input is shut off, you just leave it unlinked.

The problem is that when I have a bunch (32: 16 cols + 16 rows) of parameter modulators in a layout, they use more dsp than they should. If I just make a simple layout with one PM set off when state=0, it uses %0.10 or so of the dsp. But when I have 32 of them in a layout, they use %10 of the dsp instead of the expected %3.2. I checked by bypassing things selectively, and it seems to be the PM, not the binary logic op or the many gates, that is causing the extra processing cycles when many are used.

So I have a couple of questions. First, why does the PM use proportionately more processing power when using a bunch of them? Is there any way that anyone can see that I could achieve the same effect of turning off unused bidules when they are not connected? Selectors won't really work I don't think, because I would lose the flexibility of the matrix.

Second, do I even need to bother? In other words, if a bidule is connected to an audio matrix and no signal is going through because none of its correspondent cells is checked, is it still using dsp? It seems that it would make sense that if there were no signal route through the matrix to an output then the bidule would be bypassed. Is that the case?

stereo matrix.png (112.91 KiB) Viewed 213 times

[seb@plogue]

In other words, if a bidule is connected to an audio matrix and no signal is going through because none of its correspondent cells is checked, is it still using dsp? It seems that it would make sense that if there were no signal route through the matrix to an output then the bidule would be bypassed. Is that the case?

Nothing gets turned off automatically inside Bidule if there is no parameter linking to go along with it. So anything connected to a matrix where an entire column is not checked will still run.

[rcrath]

Thanks Seb. Any ideas about how I might solve the dsp problem here?

[seb@plogue]

Thanks Seb. Any ideas about how I might solve the dsp problem here?

Maybe the test version with discrete signal could help there.

[rcrath]

Maybe the test version with discrete signal could help there.

Sorry to be thick, but what test version and what discrete signal?

[seb@plogue]

http://www.plogue.com/phpBB3/viewtopic.php?f=4&t=5166

[sondod]

Just wanted to chime in on this. I've found that param mod's eat a lot of CPU in numbers. Sure one or two of them are just a blip, but once I get like 8 of them going in a group it represents a noticable hit even with no activity. I've taken to doing something similar to what you're doing to change the processing mode specifically for param mod groups. So if you know that eight mods can only be changed by a similar chain of events putting a switch on it to only have it processing when the value is being changed. The drop in CPU represents a significant change. Hope this helps. Great idea for a group btw. I only wish there was to auto link things.

[rcrath]

Thanks. For now I am trying a different method, just using the tail matrix group for the delays and using a different switching model for everything else, having the plugin or bidule's mode switch the matrix instead of viceversa. I will look at the test version with discrete signal when I get things smoothed out a bit.