How to not release a stream?

[MyCo]

I don't think that this causes State 5 to show up. BTW: you can't see 5 in "readout" module for state 5 when you have several voices playing. The readout converts poly to mono and always shows the sum of all active voices.

[digitalwhitebyte]

yes, the readout does not help to see this, but if you make a check in the code you can extrapolate it.

Now I do not have any examples at hand,
but in a scenario like this should work, but I do not remember the correct settings for the M to V primitives.

// ENV primitive have Hold True

// Get stage from ENV stage output
st5 = (input_ENV_stage >=5)

// FAST RELEASE
fast_cnt = (fast_fcnt+(input_envFastRelease)&0.001);
fast_rel = (1-fast_cnt)

// to ENV primitive intput End
out_done = (st5)|(frel<=0);

// OUTPUT ENV
out_env = envelope_routine*fast_rel;

edit: some correction

[jacob]

When I send the end signal with a code block to the env-module, is the voice then really stopped/ended? Because if it is still there but only with zero volume, it would need much cpu after I pressed some keys I guess.

By the way, what CPU usage should I try to keep in? Can I show the cpu usage with some module/readout?

[MyCo]

Here is an answer from Malc regarding the state/stage5 issue from 2009:

There is a stage 5, it's used to indicate to the sound process that the current channel can be removed. As such we never expected anyone to see this. Usually you'd have just 1 envelope and when this is finished the stage goes to 5 and the channel is freed. However if you have more than 1 env then they all need to be stage 5 before the channel is freed.

This means, even after a release, a voice can still be there staying in state 5. The time in state 5 is very short, maybe only some milliseconds, so the CPU waste is very low. However this if you don't care about that state, you'll get weird clicks like in some old envelope modules in the S|M forum.

You can see the CPU usage in the FS status bar. But often it is better to use the task manager or ressource monitor. In a schematic, you can only use a CPU cycle measurement to compare CPU usage. The cycle counts don't tell much, but if you compare modules, you can see which one is better. Andrew J. made a "CPU Cycle analyzer", it's in the S|M Forum somewhere.

[digitalwhitebyte]

Here is an answer from Malc regarding the state/stage5 issue from 2009:

There is a stage 5, it's used to indicate to the sound process that the current channel can be removed. As such we never expected anyone to see this. Usually you'd have just 1 envelope and when this is finished the stage goes to 5 and the channel is freed. However if you have more than 1 env then they all need to be stage 5 before the channel is freed.

This means, even after a release, a voice can still be there staying in state 5. The time in state 5 is very short, maybe only some milliseconds, so the CPU waste is very low. However this if you don't care about that state, you'll get weird clicks like in some old envelope modules in the S|M forum.

after years I never stop to figure out, haha
so if I understand correctly, it can be used as a synchronizer to mute voices still active in other envelope.

Another thing that I can not run, is the parameter NoSus, in the primitive M to V.
instead by setting the parameter NoReP is activated when the same note is repeated, and give a true value to the output Fast Realease of primitive ENV.

But also by activating NoSus I have not found a way to have control of it.
You've figured out how to do?

While the others are useful for creating Glissando and Portamento, of course, all this is very simple in mono, while the polyphonic, you can not have a real control on which this note is executed.

the problem in polyphony, is that you can not have a predictable control on all 4 channels, you should re-sequencing the allocation of voices to the next channel, so it would always be possible to know what are the current entries.
but now each time a channel becomes available it is used,
except when using the
parameters R_new, R_old, are in fact used to prevent the reallocation of voices, but can be used effectively for now only in mono.

Of course I know that you'll also have figured out how to do this.

[MyCo]

I don't understand what you want to achieve with NoSus. Actually I don't know what NoSus really does because I don't know what is meant with "Midi Sustain". I don't think that this refers to the Envelope Sustain state.

Portamento in polyphony is very hard to implement... not only in FS, but in general. You need a logic that connects previous notes to new notes. Let's say you have 3 playing notes and then you play only 2, from where do those new 2 notes fade from? The opposite is even harder: 2 notes are playing, 3 notes are coming in...

If you have a logic, maybe you can hack it in using memory write/memory read modules. The idea is: Write in a poly section the pitch of every playing voice into a memory. At the beginning of a new voice you read this memory and do your logic there to decide where this voice needs to fade from.

[digitalwhitebyte]

I believe that the function would like to control,
non-execution of multiple notes of the same pitch performed during the note on (Midi Sustain?),
but does not seem to give any reference on the various outputs from the primitive MtoV. has never been enabled?

For example, now if you try the same note twice the action is performed,
but they are associated with the same release, so mutating together, despite having a different id,
the different settings on the primitive MtoV does not change things.