DSP Robotics Support

I have created a little fellow for on-click change of preselected values, and here is the problem. The unit itself works correctly. But when used 1000 times like this per project - the selector (switching that way) causes a big big problem.

So my guess is, that both (on/off) values would have to be continuously running, and the switch would have to be non-invasive (no on-the-fly recompilation of the project?). I don't want to make this via green slide primitive, due to bad transition results (although switching works correctly there, via simpler, "select" prim).

Concepts how to approach this?

Like this?

In your original version: When you have 1000 of this, then everytime you switch on/off, there'll happen 1000 recompiles of the stream section. Your second version avoids that but has the downside of the always running stream parts.

As I tested the second attachement inside the main app - I see, that there are no performance problems, so it can stay there as it is (it generally transports static values via de-zipper, so no other straming modules are involved when it's on). I wasn't sure how it will behave after such update, thus I just wanted to check if there are ways to avoid potential overloads. First version (with selector) was not acceptable, because with 1000 selectors on board, among 500k+ prims - the app just hangs (for several seconds / forever) or crashes when you try to turn the jamming mode on/off.

I guess there are no ways (code, asm) to switch on/off streams (in terms of their activity) without recompiling the whole thing? Something like "stop module/prim activity" node would be useful in FS; wen turned on - it would just pass the signal through.

tester wrote:I guess there are no ways (code, asm) to switch on/off streams (in terms of their activity) without recompiling the whole thing? Something like "stop module/prim activity" node would be useful in FS; wen turned on - it would just pass the signal through.

You can jump over your own ASM code, but you can't bypass stream primitives without recompiling the stream section.

I send later as a feature request (if I don't forget; heavy day today). If you say it can be done via ASM, then I guess it can be done via FS architecture too. It would be nice at least to stop built in oscillators (sine, wavetable, etc.) that way.

Somehow I have less trust to self-made (i.e. via asm) oscillators. While they can be great and optimized in many ways in terms of performance (cyto's work on SM forum) - sometimes (too often under heavier load) for unknown reason they get blocked, and don't output the sound (even if there is no error on input).

...on the other hand - is there anywhere wavetable oscillator modified that way, to test?
But one with no (0-1) limits nor (0+) boundaries on nodes, and with external resync would be good (compatibility).

tester wrote:Somehow I have less trust to self-made (i.e. via asm) oscillators.

Well, the oscillator primitives are selfmade, too. Eg. Since Snowflake release, the oscillator primitives run on code that I sent to Malc.

tester wrote:...on the other hand - is there anywhere wavetable oscillator modified that way, to test?

modified to do what? There is actually no way to build a custom wavetable oscillator that is as efficient as the stock version, because you don't have memory access in code.

I see... Okay, thanks for info, and congrats.

I guess the stability of oscillators depends on how they were created, or there was some error in old SM.

...modified to be "released-on-demand" (custom node) from activity in terms of CPU usage, without recompiling the whole schematic. If that would be possible, then in many cases - I would not need to use selectors (less glitches), and it would not reset some other of my codes each time I switch something on/off. But it is nothing of great priority.