Curve of decay affects attack amount ( reaktion time of envelopes is too slow )

[gentleclockdivider]

Explained into detail into this thread , it 's sad to see the problem is still present (with all envelopes )

The envelope and it's quirks

I spend ages recreating a sound in the insstrument editor and I just wasn’t able to do it . The sound was fairly simple ,a fast filter attack of about 7ms from minimum to max and a fast decay from max to almost zero …about 10 ms . The filter attack/decay of the original sound defined the overall character , aware of the fact that every filter has a different scaling / character , I did’t expect renoise filters to sound the same , but I assumed that the envelope would at least be able to achiev…

In the provided example there are two identical instruments , the only difference is that instrument nr .2 has a slope in the decay , this slope prevents the attack stage from going to full range ( controlling filter freq) .
The visual envelope shows the attack peak being lowered when adjusting the decay slope , and that is exactly what happens .
It gets even worse when setting attack to 0.2 ms and the decay to 21 ms , renoise just can’t handle these fast envelopes ( again clearly shown in the envelope visualisation )

Taktik could you please do something about this , or at least explain why this occurs
I know this can be remedied with adding an operator afterwards but this is just too cumbersome .
Don’t get me wrong , the new curves are awesome , but what’s the use if the reaktion time of the envelopes is still too slow ( everything faster then 20 ms )
curve.xrns (6.0 KB)

[taktik]

@gentleclockdivider

Taktik could you please do something about this , or at least explain why this occurs

Modulation envelopes are not sample precise. They get scanned & applied every SamplesPerBeat/256 samples only (we call this an envelope “tick”). At 120 BPM, 44100 Hz sample rate that’s 86 samples (SAMPLERATE * 60.0 / BPM) / 256. Inbetween those “ticks”, applied values are getting interpolated exponentially. So The peak in your example will be smoothed away.

This was/is done to:

1. be able to emulate and apply the old envelope playback from Renoise < 3, where envelopes, just like everything else in the playback was processed in “ticks”. We stopped using the ticks per line settings in envelopes in 3.0 though and at least made this a fixed SamplesPerBeat/256 samples window.

2. to reduce overhead. sample precise rasterization creates quite some overhead

2. could be fixed. But 1. is very hard to fix without breaking backwards compatibility. If I’d design a new playback engine, I’d do it differently too, but as long as Renoise needs to play back old songs from previous versions this is hard to change.

[gentleclockdivider]

Thanks for the explanation , redesigning the whole playback engine sounds like a titan’s task .
If this ever will be realised , you could let the user choose between 2 different playback engines on renoise’s start-up .
Again , thanks for the hard work and love you put into renoise …

[dspasic (senseiprod)]

backwards compatibility is generally huge issue in terms of developing, and evolving
Many backdoors and security issues (generally speaking) are encountered on that basis alone…

just my 2 cents