DSP Robotics Support

So I was putting together a bit of DSP code, and everything was working perfectly, but I realized that my code took an input range of 0-2 and I thought it might be nice to change that to 0-1.

Simple solution was to multiply the input by 2 and call it good.

So with my variable declared as "streamin x;"
I wrote the code "x = x * 2;"

And at that point the code self destructed, outputting a signal of infinite amplitude or something. I did not feed it an input value out of range (0-1). Why would it do this? Is it creating an infinite loop? I don't see how that's possible since the operation should only be performed the one time every time the code runs through and as far as I know values aren't remembered by the code after ever step. Commenting out this line makes it work as expected again.

Anyone know? Thanks.

Yeah, I think it creates a counter of some description, it feeds back.
Here is a code that you can use->

just name the answer a different thing than the multiplier

Thanks for posting; I'll check that out later.
You know you could have just pasted the code in the forum too.

This problem has come up a few times over at the SM site in the past.
The simple rule to follow is this...

Never write to a streamin variable - i.e. treat them as 'read-only', and don't try to change their values within your code, always put the result into a different variable.

streamouts are much more robust - you can change them as many times as you like within a code block, and only the final value will be seen by 'the outside world'.

This is to do with the way that SM/FS works internally - the streamin's and streamout's are not truly 'local' variables. Rather than the input value from a link being 'copied' into the streamin variable, inputs, outputs and links work by sharing a common memory address between them (in the simple case of a single link).
So if you change the contents of a streamin variable, you are also changing the value of an incoming link, and possibly the value of streamout variables of preceding modules.
Very weird - I guess it saves a good few CPU cycles copying all those values around - but there's been quite a few cases of folks chasing their tails looking for bugs in their code because of this one!

Thanks Trog! Will remember that.