DSP Robotics Support

Just wanted to chime in to add: examples like these are a good way for someone like me who's less, ah, code-minded to wrap their head around what going on, and be less prone to "How do I....?" when a short chunk o' code does a certain job in the smallest fastest way

Basically what I'm doing with selectors and multiplexers, is to redirect audio streams between nodes (organic modes, not poly). So hoping is not an option, because this will introduce distortions. This is simple operation, but done multiple times at once. Traditional selectors/multiplexers are not an option, because they force internal rewire of blue guts, which may even cause from time to time crashes. From past experience, buses are not that good too; the best way is to make signal either to pass through (or multiply by 1) or ignore it (or multiply by 0). And these are multi-choice switches, not 2-state.

If I may make one final offering ... (this should all really be in the DSP forum section but wotever ..)

In DSP we are not offered a basic "if" statement. Instead, we need to employ masking techniques because we're generally dealing with poly streams that regularly contain 4 conflicting states, and only a mask can cover this.

However that doesn't mean you can't do an "IF" in ASM if you really want! After all, both loop{} and hop{} actually employ if-type conditional jumps each time they check on the loop or hop counter, i.e. whether to loop back again, or not.

The situation we're discussing here - selecting an input>output function according to a Selector Switch index - is very much an IF condition, and can be implemented like this :


Only the matching condition is executed, the other 3 'wrong' conditions are all skipped over, so possibly this is the fastest method of all? You can certainly add as many inputs as you like with this one!

H

@Hugh, now you are hooked, it seems.
Indeed, your last selector code runs a few notches faster, in spite of the branching involved. I suppose it is because cmp is faster than cmpps. There is a subtle difference, though: In your (faster) code, you are evaluating only the first of four channels of the sw input variable, whereas cmpps actually compares all four channels. If sw has individual values for each channel, the results of the two codes will be different (although I assume that this will not be the typical use case ).

One last remark: Instructions like streamin sw, in0, in1, in2, in3; or float F0=0, F1=1, F2=2, F3=3; or je will only work in the FS alphas, and people may be put off when throwing your code in a FS3.0.6 or FS3.0.8.1 ASM codebox. I think in this forum we should better stick to FS3 syntax.

Ooops . I'd completely forgotten you can't 'comma' ins & outs & floats in 3.0.6.

So I made a start on reworking it, and adding a matching multiplexer - similar in>out lines but in the reverse order.

But nor, it seems, can you do these forward jumps anyway in 3.0.6, so stopped in my tracks! Sorry folks.

All very quaint, it is ...

H

And finally ..

MV tells me that 'forward jumps' in ASM were inroduced in 3.0.8 (but don't work in 3.0.6), and of course they work in FS4 which is an ASM goldmine in comparison.

Anyway, method above is valid in 3.0.8 onwards for making a custom selector or a custom multiplexer (with an Int selector input), or if you needed some complicated selectable routing.

tester wrote:Also, from the past, I remember, there was some asm hack, that allows to "stop" some inputs from processing, like the selectors do. But I don't remember the details now.

Oh, that's interesting. I can't find it either but I could find several uses for something like that! .. anyone? I'm aware that when a Selector is used on mono streams it does indeed 'disconnect' the un-selected processing behind, can offer a big cpu saving. Certainly none of the methods we've posted here do that.

H