Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

Using the Analyser prim

DSP related issues, mathematics, processing and techniques

Using the Analyser prim

Postby HughBanton » Mon Jun 15, 2020 8:18 pm

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 1345 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
User avatar
HughBanton
 
Posts: 265
Joined: Sat Apr 12, 2008 3:10 pm
Location: Evesham, Worcestershire

Re: Using the Analyser prim

Postby adamszabo » Tue Jun 16, 2020 9:56 am

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?
adamszabo
 
Posts: 657
Joined: Sun Jul 11, 2010 7:21 am

Re: Using the Analyser prim

Postby HughBanton » Wed Jun 17, 2020 12:09 pm

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
User avatar
HughBanton
 
Posts: 265
Joined: Sat Apr 12, 2008 3:10 pm
Location: Evesham, Worcestershire

Re: Using the Analyser prim

Postby adamszabo » Wed Jun 17, 2020 12:24 pm

HughBanton wrote: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
adamszabo
 
Posts: 657
Joined: Sun Jul 11, 2010 7:21 am

Re: Using the Analyser prim

Postby HughBanton » Thu Jun 18, 2020 9:05 am

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

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!)
User avatar
HughBanton
 
Posts: 265
Joined: Sat Apr 12, 2008 3:10 pm
Location: Evesham, Worcestershire

Re: Using the Analyser prim

Postby adamszabo » Thu Jun 18, 2020 10:10 am

But how would you output green data from from the dsp/assembly box? It makes no sense
adamszabo
 
Posts: 657
Joined: Sun Jul 11, 2010 7:21 am

Re: Using the Analyser prim

Postby HughBanton » Thu Jun 18, 2020 10:34 am

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.
User avatar
HughBanton
 
Posts: 265
Joined: Sat Apr 12, 2008 3:10 pm
Location: Evesham, Worcestershire

Re: Using the Analyser prim

Postby adamszabo » Thu Jun 18, 2020 11:54 am

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.
adamszabo
 
Posts: 657
Joined: Sun Jul 11, 2010 7:21 am

Re: Using the Analyser prim

Postby HughBanton » Thu Jun 18, 2020 1:00 pm

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

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

H
User avatar
HughBanton
 
Posts: 265
Joined: Sat Apr 12, 2008 3:10 pm
Location: Evesham, Worcestershire

Re: Using the Analyser prim

Postby trogluddite » Thu Jun 18, 2020 4:48 pm

HughBanton wrote: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.

adamszabo wrote: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.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1727
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Next

Return to DSP

Who is online

Users browsing this forum: No registered users and 22 guests