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

Well this M2F usage is interesting...

For general discussion related FlowStone

Well this M2F usage is interesting...

Postby aronb » Fri Feb 19, 2021 1:16 am

Hi All,

This is new to me, an input affecting an output. Maybe I just don't get this. I have seen M2F used in various ways with Mem Modules, which I completely do not understand, so this just may be another of those cases :oops:

Can someone explain this, and the other uses of M2F please :?

Take a look at the schematic, it shows the M2F behavior...

Odd_Behavior.fsm
Odd or Not?
(13.73 KiB) Downloaded 759 times


Thanks for any and all info!

Aron
User avatar
aronb
 
Posts: 154
Joined: Sun Apr 17, 2011 3:08 am
Location: Florida, USA

Re: Well this M2F usage is interesting...

Postby Spogg » Fri Feb 19, 2021 9:14 am

I can certainly reproduce a weird behaviour.

The problem is that your DSP code in = abs(in) is attempting to write to the input rather than to an output or a float. If you change the code to out = abs(in) there is no problem.
Why does it behave this way though? I suspect the DSP to ASM compiler was never made to deal with such a situation, or maybe it was intended as a way of writing back to a stream input, though I can’t imagine a real use for such a feature. I know that if I accidentally use an input name as an output I get odd results.

When you see an M2F terminating something but its output and trigger isn’t used, it’s so that whatever is connected to the M2F blue input will then have access to the blue stream system so it can run and run in sync with blue. In this case you might say that the M2F input is also a kind of output but in reality it just makes the blue stream clock and sync available.

I hope that helps.
User avatar
Spogg
 
Posts: 3318
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England

Re: Well this M2F usage is interesting...

Postby HughBanton » Fri Feb 19, 2021 11:01 am

This could actually be quite a useful (obscure) technique for signal processing! If you replace the line
in = abs(in); with, say
in = in/2 + 0.5;
you get exactly what you might predict - a half-amplitude sine-wave moved up to zero.

Mind you, there are more 'normal' ways of using such code :|

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

Re: Well this M2F usage is interesting...

Postby aronb » Fri Feb 19, 2021 3:19 pm

All,

Thanks for the replies and info everyone!!! and so: Here is more "odd" behavior...

In this example (again it may be useful somehow), the counter seems to somehow "wirelessly" jump to other inputs and even the PC's audio I/O system! It also seems to distort the other channel as well ???

Turn down the volume BEFORE starting your audio!!! When the ramp resets, it produces a click :!:

More_Odd_Behavior.fsm
One more oddity
(23.32 KiB) Downloaded 753 times


I typically use "X = X + 1" or "in = in + 1" type methods to implement counters - I believe a lot of us do :?:

NOTE: I just stumbled upon all of this by accident, none of this was planned. I found an old module in my collection, and when I connected it I noticed odd and unexpected behavior, and felt the need to share.
Have fun experimenting - this is odd, scary, and cool stuff.

Aron
User avatar
aronb
 
Posts: 154
Joined: Sun Apr 17, 2011 3:08 am
Location: Florida, USA

Re: Well this M2F usage is interesting...

Postby Spogg » Fri Feb 19, 2021 6:01 pm

It’s actually another version of the same “illegal” issue.

The DSP code is trying to alter the value of in, and as you found in the other example this does the assembler’s head in I would say.

To count you need to specify a float like float cnt; Then you increment cnt and do whatever you wish with the value of cnt. You can test cnt and reset it etc. like cnt = cnt-cnt &(cnt>=1);

It's an interesting method of abuse you found there :lol:
User avatar
Spogg
 
Posts: 3318
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England

Re: Well this M2F usage is interesting...

Postby HughBanton » Sat Feb 20, 2021 12:46 pm

Leaving aside the abuse for a mo :lol: and excuse this totally lateral bit of nit-picking but ..
Spogg wrote:To count you need to specify a float like float cnt; Then you increment cnt and do whatever you wish with the value of cnt. You can test cnt and reset it etc. like cnt = cnt-cnt &(cnt>=1);

This is indeed the correct method to set cnt back to zero.

However in the common situation of generating a ramp, or an index counter, you're often incrementing using an arbitrary float. To demonstrate lets pick 0.11. The passes through the counter will yield 0, 0.11, 0.22, 0.33 and on to 0.88, 0.99 and next in line is 1.1, so time for the 'reset'.

To zero? No! Counter needs to reset to 0.1, which is then followed by 0.21, 0.32, 0.43 etc. This gives you a continuous symmetrical ramp, at a frequency controlled by the increment.

The dsp code to achieve this example would simply be :

float cnt;
float inc = 0.11;
cnt = cnt + inc; // count up
cnt = cnt - 1 & (cnt>1); // overflow, so 'reset' : 1 is subtracted from cnt.

Note that the '1' here is effectively the wavelength, which can also be a variable, so in more general terms :

float cnt, waveLength = 1, inc = 0.11;
cnt = cnt + inc;
cnt = cnt - waveLength & (cnt > waveLength); // overflow, so waveLength is subtracted from cnt.

If you're using this arrangement to repetitively count through a wave index, waveLength might well be 4096, or 512 or whatever. The above covers all such cases. And 'inc' is more likely to be a frequency input - i.e. streamin inc; - rather than a fixed float.

There y'go. Now, back to aronb's mono stream abuse ... :shock:

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

Re: Well this M2F usage is interesting...

Postby HughBanton » Sun Feb 21, 2021 11:45 am

weird mono science.fsm
(255.46 KiB) Downloaded 771 times

Who needs connectors ... even the disembodied scope shows a signal!
Raise the volume level carefully ;)
H
User avatar
HughBanton
 
Posts: 265
Joined: Sat Apr 12, 2008 3:10 pm
Location: Evesham, Worcestershire

Re: Well this M2F usage is interesting...

Postby Spogg » Sun Feb 21, 2021 1:38 pm

HughBanton wrote:
weird mono science.fsm

Who needs connectors ... even the disembodied scope shows a signal!
Raise the volume level carefully ;)
H


This sketch has got too silly. :lol:

But Einstein would’ve been impressed with the “spooky action at a distance”.
User avatar
Spogg
 
Posts: 3318
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England


Return to General

Who is online

Users browsing this forum: No registered users and 48 guests