Using the Analyser prim

[HughBanton]

I find that I've regularly used this basic technique to generate float arrays of all sorts .. interpolating various controls, making envelope & LFO shapes, writing waveforms and so on. Here's a very simple example :

analyser_dem.fsm

(1.23 KiB) Downloaded 1527 times

A quick description for those who haven't seen it before ..
In this instance it runs the dsp code 32 times over. In the very first pass, stage(0), it does ALL of the calculating, and writes the 32 results into array[32]. Then, in each of the 32 passes, it reads out the contents of array[32] just one element at a time, 0 thru 31. Pretty darn fast of course, it does all this in a mere 0.7mS at 44.1kHz. (Calculating & loading the array[32] takes just 1 sample, ~0.02mS!).

I'm guessing the Analyser prim was originally intended just for test purposes, however this kind of stuff is a most useful second string to its bow, I know lots of people have used it like this, and I've often thought the name 'Analyser' a bit archain.

However it occurs to me, the Analyser must only ever read one SSE channel (presumably chan 0). But with some packing and unpacking it could in theory surely accomplish the same thing at x4 speed in just 8 passes, processing 4 numbers at a time?

This would obviously need some re-configuring of the prim (and maybe a new name to boot). If you think I'm of sound mind regarding this (don't answer that ..) should I perhaps suggest such a thing on the FS4 Slack forum? Unless there's already some other shortcut for doing this is there?

H

[adamszabo]

As you can see the analyzer has a poly input and not a blue signal, so one cant really have a dedicated input for all sse channels. I guess it just reads channel 0 by default, but if it were possible to have 4 inputs I guess it would have already been done?

[HughBanton]

Thanks Adam.

Not wanting to veer towards tula & trog's most interesting "DSP code box - flawed?" discussion last week, but I guess I'm really wondering whether, for applications using the Analyser that aren't actually asking to be analysed - such as this one - whether a different kind of prim would be a useful component? One that used full SSE capability internally could certainly come up with the answer four-times quicker. (Maybe a component with multiple ins & outs; at the moment if you want 2 parallel results you have to use 2 Analysers).

But then you also realise that, in my code, array[32] was actually calculated & completed during stage(0), 1st sample, and it then takes a further 32 samples to get the Analyser to reveal the data to us. In real-world terms that's a bit like asking for someone's phone number, and they text it to you very s l o w l y .. maybe one digit per day!

I have a question while I'm here: in code like this I can specify polyin & polyout, or streamin & streamout, doesn't seem to matter either way. Does it actually make a technical difference?

H

[adamszabo]

Thanks Adam.
I have a question while I'm here: in code like this I can specify polyin & polyout, or streamin & streamout, doesn't seem to matter either way. Does it actually make a technical difference?
H

As far as I know, you can specify if you want a polyin or polyout, it will be always white, a streamin and streamout, detects your connection automatically. if you connect a white signal to it, it will be changed internally to polyin

[HughBanton]

Woke up this morning ... and the penny dropped. (I get a lorra that these days )

In DSP & Assem boxes in FS4, among many many other things, we now have floatarrayin, memin and memferin, which can be read within your code just like any array. I've used them all.

I'd be able to immediately find the solution (or at least a very major enhancement) to my example above if we also had floatarrayout. In the above, instead of declaring the float variable array[32], you'd include floatarrayout array[32]; at the start. (drool ...)

And hey presto - no need for the Analyser at all in this example. And only stage(0) now needed so output delivered at ludicrous speed.

Haven't a clue if this is even practical, I'll sit on it for a bit before suggesting it for the 2023 upgrade.

H

PS memout? memrefout?? (Not even sure what that would do!)

[adamszabo]

But how would you output green data from from the dsp/assembly box? It makes no sense

[HughBanton]

Oh. Seems reasonable to me .. floatarrayout would produce exactly the same as the Analyser prim does in my example.

After all, inside DSP/Assem you can have an internally generated array (as per my array[32]) that can then be manipulated, so all I'm proposing is that the array be made available to the outside world. No?

But I can see there would be limitations, it would only have to be used for calculated results, probably stage(0) stuff only.

[adamszabo]

The arrays in the dsp/asm box are different than the green ones. They are specially stored in mem adresses that can be access at sample rate. The green array is different.

[HughBanton]

Hah! Thanks, most grateful for the explanation of that detail.

Ah well, the Analyser method as it stands works OK for me really!

H

[trogluddite]

PS memout? memrefout?? (Not even sure what that would do!)

They wouldn't do anything - at least, not anything useful!

In technical terms, the "mem" inputs pass a "pointer" into the code - that is, not the array data itself, just the memory address at which it can be found. Once you have the memory address, you can both read and write to the memory by choosing the appropriate instructions. So there's no need for "mem" outputs - you just have to remember that whether the data is coming in or going out, it's always the same block of memory that's being referred to.

The arrays in the dsp/asm box are different than the green ones

This is only a matter of convention rather than anything technical, though - both are just contiguous chunks of memory containing end-to-end float values. The differences are only in what assumptions FS makes about their content, and what access it allows us...

- DSP code assumes that "mems" contain four values per index - one for each SSE channel.
- Float Arrays are always strictly one value per index.
- Float Arrays let other parts know when the data in the array has changed by sending a trigger.
- There's no implicit way to know when the data in a "mem" has been changed.

In ASM, you can treat a "mem" as "one value per index" if you want to - structurally identical to a Float Array, just without the handy automatic trigger generation that access via a green primitive provides. (I'm not yet familiar with the alpha's new "memrefs", but it may be that they provide this kind of "single-value" array already to DSP/ASM?)

If, as Hugh mentioned, the alpha also has floatarrayin, then the "array filling stage(0)" may even be possible already. It would have to be a pointer of some kind, just like a memin, so ought to allow writing as well as reading. The only problem would be that you might need additional gubbins to generate appropriate triggers if you were changing the array contents from DSP/ASM during runtime.