replacing selectors

[tester]

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?

[tester]

Like this?

[MyCo]

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.

[tester]

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.

[MyCo]

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.

[tester]

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

[MyCo]

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.

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

[tester]

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.