-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Juno6 noise oscillator terminates prematurely #164
Comments
#175 fixes this for the particular case of the noise osc in Juno, while notes are held down. However, because the "reviving" is conditioned on the note still awaiting a note-off, notes with long decays can still exhibit this extinguishing of the noise osc (set Release to long, turn up the noise osc, play a note, release the note, then during the decay turn the noise down to zero; turning it back up again will not reintroduce noise). This is an edge case I can live with; without this, the "revival" process would bring back entire long-silent notes. But there's something I don't understand: This "extinguishing" only applied to the noise osc, not the other oscs. The subosc, for instance, is very similar with its own amplitude slider, but happily returns. I'm not sure what's special about the noise osc - perhaps the fact that it doesn't have any chained osc? I was worried that perhaps only the noise osc was being terminated/suspended on amplitude falling to zero, but I confirmed with |
I feel like it would be valuable to try to design how the lifetime of a note progresses, including both initiation and termination. Oscillators start in a non-active state. This was originally marked by An oscillator starts when it receives a note-on event, which specifically means a nonzero velocity ( Naively, we might expect to be able to wait for the note-off event, at which point we could stop the oscillator and change its status back to off. The problem is "release" - the phase of a note sound dying away after the note-off event. This is the "R" part of an ADSR envelope, and is an important aspect of many notes. So, instead, we have to wait for the release to end. However, this is not so simple because there isn't a particular envelope generator with a fixed association with the amplitude envelope. We used to wait for all the envelopes to finish their releases, at which point we could be confident the note was over. However, we switched to a different principle, of just looking at the amplitude of the frames coming out of the oscillator, and noticing when they had fallen to zero ( The weakness here was that if an oscillator outputs zero amplitude because of some cause other than the note ending, for instance if its amplitude is being modified by a user twiddling a control knob, or even perhaps by being amplitude-modulated by a pulse that effectively turns it off for some period, then the oscillator can be prematurely terminated. We dealt with knob-twiddling as a special case in #175 by promoting Although looking at the output samples is appealing in its logic, I think we might well want to go back to tracking the envelopes, and keeping an oscillator active only until any amplitude-affecting envelopes have reached terminal zero values. It's not impractical to figure out which ones are connected to amplitude (by looking for nonzero values in |
The symptom is that the noise oscillator in the Juno 6 emulation will stop until the next velocity > 0 event once its amplitude is reduced to zero. So, if you have a patch, say, with saw and noise turned up, then while holding down a note fade the whole note to zero with the VCA level slider, then fade it back up, the saw waveform will still be there, but the noise will have been turned off.
I think this is related to the opportunistic oscillator termination using
zero_amp_clock
, which is intended to "reap" inactive notes even if no note-off is sent. I think I need to rework this to allow oscillators to "revive" after periods of silence (for instance if their amplitude parameters are updated).The text was updated successfully, but these errors were encountered: