EnvGen still behaves incorrectly for early gate, but other doneActions #2189
Comments
|
Really appreciate these thorough unit tests. Would be great to add them to our test suite. |
|
Yes! Would be nice to fix the issue first – I just don't know where the bug sits. |
|
The issue is still present on |
|
On 3.9.2 windows scsynth I get the same problem |
|
let EnvGen_next_k print gate by uncomment this line you will see that always that a test fails the gate is always 0. In #3094 I am proposing a fix for other issues of EnvGen that lets early gate in the same status (but not worse) |
|
I did a test with EnvGen.ar with EnvGen_next_aa. The argument for a_gate was provided by an audio bus with a synth making the gate changes. Test was succesfull in scsynth and fails in supernova only for 6, 8, and 12. My conclusion is that a gate shorter than control period in a control rate input is a nonsense: you will get 0 or 1 but not both values in the same control period, this will never happen "correctly" as the issue is trying to solve. |
|
Sonoro is right - the reproducer as written is not internally consistent. Sub-block changes require audio rate signals. Shall we keep this open for the supernova discrepancies, or close this as invalid? |
|
I would bet that the issue in supernova is with doneAction 6, 8 and 12 (not specifically with EnvGen) in general. (Could be tested with Line for example) |
The point is (if I remember correctly, this is pretty long ago) that if you have a This may lead to hanging notes in some applications, and extra checks are not exactly trivial or beautiful. |
|
My conclusion was that if you have a kr envelope initiated with gate=1 and in the first block the gate goes to zero, half of the times you will get a 1 and the others you will get a zero. If I am true this means that a limitation exists in scsynth that dont let you use in a kr argument variations shorter than the control block in any case. This is not specially bad except for gates!! |
I see, you're thinking of the language perspective and Victor is taking the server's. From the server side, it is literally impossible to have a kr signal change in the middle of a control block. The language can send a |
|
yes, exactly. From the server's point of view, it is a change from 1 to 0 in the initialization stage. Something goes wrong there. It is a typical corner case, but it is relevant in practice: you may have no way to check what messages end up in a single bundle. |
|
All tests work now. |
This is related to #1063.
Here is a reproducer:
The text was updated successfully, but these errors were encountered: