You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lookup table oscillator (sine, pulse, saw, etc.) interpolate their amplitudes over adjacent frames, to avoid clicks when amplitudes change rapidly. This means the fastest that a note can start from zero is 5.8 ms (one frame), which is a little too long for the attack of some percussive instruments, like a punchy piano. It would be nice to be able to go down to ~1 ms.
Using shorter frames (e.g. 128 samples instead of 256) would improve this, at the cost of greater processing overhead.
We could also special-case attack frames, perhaps with a split linear amplitude fade (ramp up for some sub-portion of the frame, then have a different slope for the remainder).
The text was updated successfully, but these errors were encountered:
I tried setting AMY_BLOCK_SIZE to 64, and everything worked pretty well (except for PARTIALS, see #81). 64 gives us a minimum attack time of under 1.5 ms which is pretty good, but it means the per-block processing overhead (which involves floating point operations etc) is 4x greater, which will reduce the total number of oscillators we can manage for a given CPU capacity.
This was mostly solved by a06dad4 which shifted the amplitude envelope one block earlier. Thus, if the envelope generator value at time 0 is 1.0, the osc amplitude starts at 1.0 (previously it would fade from 0 to 1 over the first 5.8ms). This makes possible instantaneous attacks (attack time=0, good for percussion) but still leaves the second fastest attack time limited to 5.8ms.
Lookup table oscillator (sine, pulse, saw, etc.) interpolate their amplitudes over adjacent frames, to avoid clicks when amplitudes change rapidly. This means the fastest that a note can start from zero is 5.8 ms (one frame), which is a little too long for the attack of some percussive instruments, like a punchy piano. It would be nice to be able to go down to ~1 ms.
Using shorter frames (e.g. 128 samples instead of 256) would improve this, at the cost of greater processing overhead.
We could also special-case attack frames, perhaps with a split linear amplitude fade (ramp up for some sub-portion of the frame, then have a different slope for the remainder).
The text was updated successfully, but these errors were encountered: