DSP Robotics Support

Here MyCo, check this one if it works on your machine. I have different seeds each time (only the first value tends to be similar very often).

Now, here is one thought about what you said on "not working". During experimentation, only once - for some reason - one of the schematics stopped to generate different seeds on load. Because I used only copy/paste - nothing was changed in structure of seed generation, thus I suspect there is some bug in FS. After removing some of cells - schematic started to work again, so I can't provide the buggy one.

Anyway, I could provide initial external seeds via such theme. Generally the whole idea is to have different values after each app load.

p.s.: in your timer - I would need initial delay option too, if you could add it (multiple units are synced that way with each other).

Hey MyCo - could you add to your optimized ASM randomizer an input node for external seeding? (...and initial delay node for value "latcher" code...). I would be grateful. I'm looking at these ASM things, and it's like Chinese for me.

Meanwhile I played around with various options (no success in performance), and I'd like to try your approach "as is".

...

Thanks.

I'm trying to get the idea on how this ASM stuff works.

These numbered xmm fellows, are some sort of labels, to which you assign various things (like inputs, operations), yes? As far I try to follow wiki and cyto (complete? incomplete?), there are 8 "labels" (0-7) accessible to assign things, yes?

I think I'm starting to see a light in the tunnel.

xmm0-xmm7 are processor registers for the SSE instruction set (SSE registers). Basically you can think of it as variable names for variables that are stored in the CPU. Each SSE register is 128bit long and can contain 4 single precission floats or 4 Double word integers or 2 Double precission floats. The double precission floats aren't supported by Flowstone and most of the time you only use the single precission floats, so you don't have to care about the internal format of a SSE register.

Okay, thanks. I guess next year will be the year of ASM for me.

One final thing MyCo. I just noticed, that one of my modules (which uses changes between 0 and 1 to initialize) is incompatible with your triggering system. I extracted that part. Could you take a look and change it to compatible with your system?

p.s.: in my part - this hop at 256 probably must be unchanged (it's related to green part, replaced here with constant floats) in order to produce proper results; cyto's invention for effective envelope generation. Is there a way to make boolean switcher without creating second ramp (performance related)? I mean - changes between 0 and 1 driven by impulse (something like "bool to true" reaction)?

I don't know what you exactly mean. But I've changed your code so that it works with my impulse timer.
Your code looks like it's generating just a decay, so I've included a much simpler version for a decay that works with my impulse timer.

Maybe it's better to tell what your goal is, instead of posting parts of it, that alone don't make sense.

Depends on what you mean by "just a decay". This one offers control over length (from short, like less than 1 second, to very long periods, like 2 hours), fade in (just length; usually 3ms or few seconds) and fade out (some sort of curve - guess exponential, midpoint set in dB). It was designed by cyto (I don't know how you estimate his knowledge/experience) some time ago - and as far I remember, was made for both: high performance and long periods of time; there were some issues with other approaches. The whole discussion on that is burried somewhere on SM forum. Since then - I just remixed it a little bit (parts left green, parts included in code), because I was experimenting with something that required more operations on streaming. If you have simpler idea how to make such decay - sure, why not, I'm eager to see it. The only downside of this one is - that if you shorten the fadeout during fading - it "compresses" the sound and "dongs" with loud overload (works fine in next cycle).

As for extracting parts - blame Trog... He taught me, to "remove unnecessary parts of the schematic and provide only the functional/vital ones" that require particular attention.

In essence, timed trigger retriggers both - random parameters that can be sent/scaled to various components of sound (frequencies, modulators, panning, and so on) and envelope that operates on that sound. The whole thing works pretty nice, but your approach on random part - will save some CPU in multi-unit setup. Which is crucial, because after adding some new features - I just reached comfortable level of work on my laptop and started to experience glitches.

The only thing left to check are the audible nuances of white randomness so to speak, but I think it should be fine.

So again - thanks!

...but a brief analysis and observation leads me to the conclusion, that you would be able to make even more effective/stable decay in ASM, just in "no time".

It depends on the requirements.