fix #259 init debounce counter #264
Conversation
|
I haven't yet properly understood either the problem or the diagnosis, but if the cause of it is in the boundary conditions assumed by the NRT wrapper, then fixing there is the way to go: if the RT object works as expected, then it oughtn't be changed. |
|
the RT worked only because one would need to start the DAC and the play at the same time to 'miss' that attack. So I think we just never caught it. With this fix, it works both in RT and NRT. |
|
So now the slicers will always emit an event at |
|
yes (not the sample, but the value of the algo - in amp it is a diff between properly initialised env, I've checked) - this is what we expect in RT (from silence) so not having that (from assumed padded silence) in NRT was problematic (for instance in Rod's case) |
|
Well, if it still passes all your detailed supercollider tests, have at it |
|
As far as I can see the code as it was prevented slices at t==0 and it's unclear if that was a design, or an accident. However, I don't see a clear rationale for disallowing that in either RT or NRT case (and in the latter is more likely problematic). I think the change here is probably better default behaviour. |
|
Clearly this was by design, explicitly to avoid detecting an onset at the first sample. I think the rationale was linked to the padding which happens outside the object. I am not sure whether this may have changed. The design was based on a number of test cases, sometimes with potentially conflicting requirements, so it was "the less worse option" at the time, but if this passes all of these now then I guess it should be fine. |
|
it passes all the unit tests so I'd merge in |
Fixes #259 by setting the init of the debounce counter in the 3 slicers that had it to 0 instead of 1. when 1, the condition when the (infinite state of 0 input) to (any signal) which should correctly trigger an attack at frame 0 was ignored, which is a conceptual error compare to our RT one.
Conceptually, we always assumed silence padding as it is what happens in the CCE in RT to these inputs. It is the less worse option. that counter was starting at 1 and dismissing signal at input.
see the bug report to have a comparison patch. or just approve :)
thanks