vowel filter and modulation problems

[TrojakEW]

This one works.

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;

movaps xmm0,one;
shufps xmm0,xmm0,0;
movaps one,xmm0;


[tester]

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.

I don't know what it does, but your next fix seems to not work - either dies or just sends a value that does not exist (check on all channels)...

Here is the original topic:
http://synthmaker.co.uk/forum/viewtopic ... =45#p89297

and attached copy from there.

[trogluddite]

Not too sure about the bug - not had time to look that deep - but it does look as if it should work.

However - here's something else to try; eliminating the unpack completely.

1) Feed the two filter blocks with the complete mono4 input (no unpacking).
2) In the second filter block change the first opcode 'fld in[0]' to 'fld in[1]'

The 'fld' opcode grabs the value of a single SSE channel (it a CPU floating point unit instruction rather than SSE)- that's how the previous unpacker examples are working. So effectively, that first instruction in the filter is a built-in unpacker - all that's needed is to change the 'in' channel that is being used - the following 'fstp temp[0]' opcode will re-direct the value to channel [0] of the main filter routine.

[tester]

Well - I leave the asm stuff for asm gurus. I have no bacground for making conclusions on results. I mean - I read, but my understanding is somewhere else among the clouds... Overloaded.

[TrojakEW]

2) In the second filter block change the first opcode 'fld in[0]' to 'fld in[1]'

This doesn't work here too.

But Tester why is there pack4 in mod cv? Why not use mono only like this?

[trogluddite]

This doesn't work here too.

Aaah - sorry, my bad. The connector for 'in' is set to be a 'monoin' in the code, so it won't receive on all four channels - changing it to a regular streamin should allow the mono4 to connect correctly.

[tester]

But Tester why is there pack4 in mod cv? Why not use mono only like this?

Because the whole design is large and has hunderts individual oscillators for modulation; some of them are packed x2 or x4 to make things simple. Spliting it into mono designs means few things: more wavetable based oscillators to rewire by compiler, more selectors in blue section, less syncing.

Besides this issue seems to act in the bacground of FS compiler, so I have no idea whether it affects something else or not.

[trogluddite]

Oops - ignore my previous posts, I had misread the problem, and now have a fix...

vowel-error SSE FIX.fsm

(53.09 KiB) Downloaded 899 times

Once I had the schematic up on my big screen, I saw what you meant about the modulation. Couldn't see that part on my little laptop, and jumped to the conclusion that the packer at the top (audio input) was causing the problem!
(always read the question properly!! - as my teachers were so fond of telling me at school).

You'll be pleased to hear that the FS compiler is not broken - it hasn't changed at all.
The problem is caused by the weird way that mono connections work. The 'x' and 'y' inputs of the co-efficient calculations have only a mono in - but the values are being used to calculate mono4 filter co-efficients.

Normally, that is OK, because stock "mono" streams actually do use all four "mono4" streams - but with all four values set to the same value. It has to work that way, because the SSE commands in the CPU always process all four channels, even if you're not using them - so by default, stock components "broadcast" on all four channels, just to be sure that the "unused" channels don't cause the CPU any problems.

But this setup breaks if you feed it a mono signal that comes from an unpacker (or certain kinds of assembly), because the unpacker mono outputs really do only process single channel - leaving the other three in a somewhat uncertain state. No doubt, this is because it saves quite a lot of CPU to do it that way.

I've popped in a little module on the 'x' and 'y' inputs that fixes this, by copying channel [0] to the other three, and using a mono4 code input instead of plain mono (that's why my other 'unpacker' designs worked - because they also have this 'copy to all' feature). It's a handy little module to have in the toolbox, whenever you need to send a mono stream to all four channels of a 'mono4' component.

[tester]

As for your earlier posts - definately I ignored them.
Somehow I knew that you misread that problem.

Thanks for fix.
And nice to have you back on forum.

[trogluddite]

No problem - been a while since I did any ASM; I was starting to worry that I'd forgotten how to do it!