DSP Robotics Support

In order to route LFOs to the destinations in other parts of the schematics, I've created a matrix similar to the stock matrix, Here is the mini version of what i have in the main project:

It was very strange to me the amount of CPU it uses, the matrix only, is using about 6% of CPU and upon changing the selectors, there is cpu spikes.
Should i trim down the sources and destinations to a very small list, or there is a better way to do this?

the thing with the bus based matrix is, that it forces recompiles when changing the source/target connections, i also found out that you can avoid audiocrackles with ruby selectors in some cases..

to be honest i dont understand your matrix - with green integers and stream.. are you sending also the steps of the step seq thruogh the matrix? maybe if you could extract the whole system with working streams (and audioout) to test the thing, then i could maybe find some alternative ways and test out whats working better..

Nubeat7 wrote:are you sending also the steps of the step seq thruogh the matrix?

Its the same as the original matrix, only with two inputs/outputs for each source and destination. The first value (Green) is LFO's status (on/off) and the second one (stream) is the main signal.
Just wanted to get the idea of how this thing works, and how others do it.
So you're saying if there is lots of things going on its better not to use a bus because it makes everything recompile?

Father wrote:So you're saying if there is lots of things going on its better not to use a bus because it makes everything recompile?

better or not ? there are not much alternatives except of getting lost in lots of selectors or to write it in code which is a bit tricky but you can have a look at my fx chainer here viewtopic.php?f=3&t=1704 as a start..

in general i think send as less as possible truogh the busses when you change the routing (are this on/off signals really needed to get sent trough the busses too?) i think it can be a long list of possibilities but a routing action should do as less as possible at once - like if you change routing 1 it makes a difference if 5 bus connections need to be reroutet or just one...

i remember my first fx routings using a busbased matrix for repeat x in some cases it needed nearly 2 seconds to change the routing which was impossible to use specially using selectors for busses was really slow, after weeks of trying out different solutions i saw the only way to do it in code to be able to route on the fly while audio is playing and without audiodropouts, but it depends on how complex the routings are some classical synth mod routings are working pretty well with the bussystem too - best bet try out some different ways - start small and easy and make it more complex step for step and you will see where it starts to be unusable for you

what´s also a nice solution, is to send all sources to all targets and just switch them on or off, you know this - you have sources on the y axis and targets on the x axis and a on / off switch (or amount knob) for each connection.. this is a really simple, easy and effective way

Great topic, I've seen it before but never thought about it like that. Everything you said is making sense to me.
I think the problem begins when the sources and destinations starting to grow, the green takes too long.
I'm not sure about the second solution. With bus or not! I'll try different scenarios and see what happens.Only if i don't get the same thing when turning them on and off.
I get the picture though, Its nice to have help from someone whos been here before!

Nubeat7 wrote:what´s also a nice solution, is to send all sources to all targets and just switch them on or off

....
like this..??..http://www.dsprobotics.com/support/viewtopic.php?f=3&t=2355#p11104

billv wrote:like this..??..http://www.dsprobotics.com/support/viewtopic.php?f=3&t=2355#p11104

Thanks bilv. Yes exactly like that! Nice!! How is the performance?
However your modulation is sent out in green, not a good idea for fast modulations like 1/16,1/32...it gets inaccurate but for most parts its no problem.
This looks promising, I'll finish mine with similar approach.

Father wrote:How is the performance?

the fsm was a experiment on the "performance" of the mods..
My usual mod, if I use 4 of them, hits about 4% FS cpu....
That fsm has 16 mods at the same cpu cost 4%..
I built a lot of different ones trying to get a result, in the the end,
it was an old 'myco' circuit that did the trick. The data is handled
a lot better. I know it's green, it's still a killer circuit, fed by a ruby tick
it's pretty tight, and it's just for modding knobs and stuff that have green input...
The "running all the time" part...another experiment....i dunno....
16 mods is another experiment....8 or less seems more practical in general....

The send matrix things seem to work ok. I like how this part is going.
Either way, build a control module or routing direct, seems to work fine.
hasn't been tested in a full synth yet....

Apparently the BUS module isn't behaving very nice when you change the inputs and outputs. I used your way,that is sending everything to the end modules and use a selector there. whether its stream or green. works really smooth and seamless.