Well this M2F usage is interesting...

[aronb]

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

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 878 times

Thanks for any and all info!

Aron

[Spogg]

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.

[HughBanton]

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

[aronb]

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 880 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

[Spogg]

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

[HughBanton]

Leaving aside the abuse for a mo and excuse this totally lateral bit of nit-picking but ..

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 ...

H

[HughBanton]

weird mono science.fsm

(255.46 KiB) Downloaded 893 times

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

[Spogg]

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.

But Einstein would’ve been impressed with the “spooky action at a distance”.