Fix UGen initialization: OscUGens #5787
Conversation
mtmccrea
force-pushed
the
topic/init-sample-oscugens
branch
from
101d1db to
566fd1c
Compare
|
[EDIT: this issue is resolved, thanks @dyfer!] I was getting failing MacOS tests based on Now I'm seeing failing tests related to Are there known issues with |
Yes, there are issues in these tests and thus they are disabled in the CI.
|
|
@mtmccrea RTAlloc tests are now disabled in the CI and I made some changes to the testing script as well. Can you try rebasing this PR on the latest |
The UGen's calc rate erroneously checked against the bufnum slot instead of the input signal slot, so the calc func would never be DegreeToKey_next_a.
This also ensures in != unit->mPrevIn on first frame so that index is calculated.
Was outputting `y(-1)` for init sample and setting `y(-1)` to `y(0)` and `y(-2)` to `y(-1)`.
Don’t assume init sample to be 0, properly calculate previous sample by rolling back phase.
Calculate the initialization sample by the proper `next_` function, based on input rates, reset state for first sample. Reset the initial phase after calculating the initialization sample.
Calculate the initialization sample by the proper `next_` function, based on input rates. Reset the initial phase after calculating the initialization sample.
Calculate the initialization sample by the proper `next_` function, based on input rates. Reset the initial phase after calculating the initialization sample.
Calculate the initialization sample by the proper `next_` function, based on input rates. Reset the initial phase after calculating the initialization sample.
mtmccrea
force-pushed
the
topic/init-sample-oscugens
branch
from
566fd1c to
81d7a16
Compare
|
Thanks @dyfer! After the rebase the tests are passing now. Thanks!! |
Purpose and Motivation
A majority of UGens do not initialize with a correct initialization sample, and subsequently output an incorrect first sample. A lack of clarity and consistency around how UGens are initialized has led to many UGens being improperly initialized. The affects include: UGen graphs aren't properly "primed" (users see unexpected results), samples are delayed, filters can pop from incorrect feedback coefficients, accessing unassigned memory, etc. Users regularly report Issues that can be traced back to UGen initialization problems.
This PR also serves as a concrete reference for discussion found in the RFC: Fix UGen Initializations, more details can be found there.
This PR is part of an ongoing effort to fix UGen initializations, the progress of which is tracked here.
(I will update this post with Issues this fixes.)
Types of changes
FSinOsc,FoldIndex)Changes in behavior of UGens would all technically be breaking. However, the changes are largely (entirely?) confined to the output of samples within the first block.
I chose to use
OscUGensas the starting point because I expect these changes are minor (likely won't be heard), and are hopefully not overly controversial.Changes to UGens which are more elaborate or might create more substantial change in behavior will be left out of these kind of "batch" fixes, and submitted as separate PRs (
TWindex(#5815),KlangandKlank(#5817), in this case).To-do list