DSP Robotics Support

I borrowed vowel filter from SM forum and trying to adjust it for slow modulation purposes.

But for some reason - this thing is dying when I connect modulator pushed through mono4, while normal oscillator does the job.... Values are kept in ranges. Mono's and mono4's are adjusted to fit I/O. Readouts show one thing, headphones other thing.

I'm lucky with dying modules recently

oh man how do you always find that strange things?

it works with this "get mono" module, i think it from one of trogs toolboxes? but not shure from where..

I work in beta tests from time to time.
Now you know why

Did some digging and it looks, that it dies only when oscillator is pushed through mono4 unpacking. After redesigning the original osc to standard mono - it worked. So - sending the bug to devs...

Thanks for reminding me Troggies works. They bring some light on the problem I guess.

Nubeat7 - do you have mono4 unpacker that would work correctly? I can't find that version of Trogz tools with "get mono fixed" (have in older version 3.5a, which isn't working too).

just the one from the example i posted above, isnt it working on your machine? it is working here..

The "get mono" above works, and I think i found where it's placed on SM; I was rather thinking about replacement for "mono4 -> 4x mono" extractor. Otherwise - 4 copies per 1 extraction needed.

Something like this?

TrojakEW wrote:Something like this?

Code: Select all

streamin in;
monoout one;
monoout two;
monoout three;
monoout four;

push eax;
fld in[0]; fstp one[0];
fld in[1]; fstp two[0];
fld in[2]; fstp three[0];
fld in[3]; fstp four[0];
pop eax; 

also dont works in this example!?

TrojakEW wrote:Something like this?

Code: Select all

streamin in;
monoout one;
monoout two;
monoout three;
monoout four;

push eax;
fld in[0]; fstp one[0];
fld in[1]; fstp two[0];
fld in[2]; fstp three[0];
fld in[3]; fstp four[0];
pop eax; 

This one dies. From what I can see - it may have to do with some additional instructions in ASM code (shufps and some difference in numbers). So either is the formant filter from SM somewhat buggy, or the pack/unpack is missing some security. To my limited understanding it would look as if somethig was sharing the same memory, thus readouts show one thing, and schematics do the other thing.

Doesn't shufps only change channel routing? Mask 94 in original code output channel in order 3,4,2,2 while 78 sets 3,4,1,2.