"Trigger To Gainer"-Chain Eats Sample Attack Phase

[Bit_Arts]

Welcome back to BA’s Timing Bug Show!

“Velocity Trigger -> LFO Reset -> Gainer” eats about 6ms of the sample attack. Came across this when I tried to trigger an LFO-volume envelope for a kickdrum. Did not use any delay in any way, nor anything else. When the LFO is reset to set the gainer to max volume about 5-6ms of the kickdrum’s attack get lost… and the kickdrum becomes a drum… without kick.

(the 6ms are measured with a source muted delay, added as first device in the chain then, raising its delay-time in milliseconds till the complete attack phase appears.)

[Bit_Arts]

Download sample XRNS: Attack_Missing.XRNS

[dblue]

This is not really a bug per se. It happens because the gain level changes are ramped/smoothed, which is essential to prevent clicks and other artifacts from occurring when the gain level changes very suddenly. The funny thing is, with ramping enabled you lose some of the attack but the release fade sounds smooth, but with ramping disabled you’d get a nice sharp attack but the release fade would probably sound terrible. Obviously the gainer simply wasn’t designed with this type of usage in mind, so you can’t really win here unless the device itself is redesigned to take this stuff into account.

I think in this particular simple example you’d be much better off using an instrument volume envelope instead. This may or may not work for your entire song, as I don’t know what other envelope automations you had in mind.

Edit:

For what it’s worth, I’ve encountered the same problem myself when using DSP chains (RingMod, etc) to synthesise my own sounds. I would also love to have more options available when it comes to applying envelopes, even if it was just the ability to enable/disable/adjust the amount of ramping on the gainer. Some kind of extra control over this stuff would be great, to allow for instant attacks or whatever I might need.

[kazakore]

Are you sure dBlue? 5mS seems a huge amount to be explained away by that! One full cycle at 200Hz.

How about a suggestion of adding the LookAhead we have on the Signal Follower to the Velocity and Key Tracking Devices? Would that be a possibility?

[dblue]

@kazakore

Are you sure dBlue? 5mS seems a huge amount to be explained away by that!

Check it out for yourself:
renoise-gainer-ramping.xrns

Warning: One of the samples in this example is pure DC at 0dB, so watch your speakers!

This example simply has an LFO with a custom envelope alternating between its minimum and maximum values, which is in turn controlling a gainer. The LFO is in points mode so changes should theoretically be ‘instant’.

Take the first pattern labelled ‘dc offset’ and render it to sample. You might expect the resulting waveform to resemble a square wave with instant changes in its amplitude, but in reality you can see the ramping very clearly and how much it actually smooths out the attack/release.

[Suva]

Just use the lookahead setting to fix this.

[Bit_Arts]

Wut lookahead settings, Suva?

Thanks dblue for pointing the reason out. The ramping seems indeed to be the reason instead of a timing bug. Still to me a gainer is a gainer (only) and actually I think its like blocking a huge advantage of digital audio to constrain smoothing/ramping for a gainer.

Kazakores lookahead idea for the Gainer is kinda nice, but I’d definitely prefer a bit-exact device.

[dblue]

@Suva

Just use the lookahead setting to fix this.

There’s no lookahead on any of the devices we’re talking about here

It could be interesting to have lookahead on the Velocity Device and Key-Tracking Device. But since these devices are analysing pattern data rather than audio signals, I wonder how they should be timed? Should the lookahead be in pattern lines (+ ticks or delay steps) or in milliseconds?

[Suva]

Oops sorry, I thought you meant signal follower. Correct me if I am wrong: You can still do it with delay setting and send channel?

[kazakore]

@dblue

Check it out for yourself:
renoise-gainer-ramping.xrns

Warning: One of the samples in this example is pure DC at 0dB, so watch your speakers!

This example simply has an LFO with a custom envelope alternating between its minimum and maximum values, which is in turn controlling a gainer. The LFO is in points mode so changes should theoretically be ‘instant’.

Take the first pattern labelled ‘dc offset’ and render it to sample. You might expect the resulting waveform to resemble a square wave with instant changes in its amplitude, but in reality you can see the ramping very clearly and how much it actually smooths out the attack/release.

The A&H X:one range of DJ mixers use a VCA crossfader and certain of the range in the early days suffered from this exact problem (an RC network is used to give a subtle ramp so that you wont get any pops or crackles from a less than perfect connection.) Made it impossible to scratch with some of their mixers until the adjusted the design for all the range.

Still don’t have a fully working computer at home so can’t look and play with your example. Showing mS on the timeline clearly, along with maybe samples on other side, preferably starting from zero, would help a little but even as it is I can clearly see that is going to eat away at any hard attack! Renoise already has a ramp to stop samples from popping/clicking and this is of small enough amount to not be noticed in this kind of situation, why does the Gainer need so many orders of magnitude more? 1/10th or less of that current ramp time looks like it would still be more than sufficient.

[Bit_Arts]

Nope, you can’t, Suva. Just try it out. File can be found above.

[Bit_Arts]

I’d suggest to extend the current Gainer with settings for ramping/smoothing, set to its current (internal) amount by default (for compatibility), with a slider down to zero ramping/smoothing. Automation for this would be nice, too. If there’s similar ramping for the filters (I’m not really sure about this), for filters this would be nice, too (Yeah, I know the intertia thing, but maybe there’s still ramping on inertia 0).

[dblue]

@Bit_Arts

Still to me a gainer is a gainer (only) and actually I think its like blocking a huge advantage of digital audio to constrain smoothing/ramping for a gainer

The trouble is that automations and meta devices such as the LFO Device are currently still governed by the Ticks Per Line setting, and therefore Lines Per Beat and BPM will also have an effect. In other words, the higher your TPL, LPB and BPM, the more resolution/accuracy you’ll get from your automations and LFO output.

This is very easy to observe if you compare the output of the LFO with various different TPL settings…

Test song is set to 60 BPM, 4 LPB, with the following LFO set to fade out a gainer over 4 pattern lines:

Under ideal conditions with sample-accurate LFO output, we might expect to see something like this:

And here’s what we get from Renoise:

With TPL set to 1, we get:

With TPL set to 2, we get:

And so on…

With TPL set to 16, we get:

As you can clearly see, increasing TPL results in more accuracy in the LFO output. Increasing the song to 8 LPB or 16 LPB (and changing the LFO frequency accordingly) can improve things even further. But even with higher settings the ramping is still required to smooth out the gain changes, otherwise you’d get ‘zipper’ noise and aliasing from the obvious steps in the LFO’s output.

Without any ramping we’d have gainer output that looks like this…
(Using the 1 TPL example again, just to clearly highlight things)

… which I can assure you does not sound very good at all

A gainer controlled by a sample-accurate LFO envelope would theoretically not require any ramping, so hopefully Renoise can eventually have sample-accurate automations and meta devices.

[kazakore]

@dblue

The trouble is that automations and meta devices such as the LFO Device are currently still governed by the Ticks Per Line setting

I didn’t know this. Always knew and thought of the LFO as a way to get around the single line resolution of the Automation window but didn’t know it just changed resolution from a Line to a Tick. Still better at least though…

[taktik]

@kazakore

I didn’t know this. Always knew and thought of the LFO as a way to get around the single line resolution of the Automation window but didn’t know it just changed resolution from a Line to a Tick. Still better at least though…

Yay, we are using ticks as event rate. Made sense cause all the other pattern FX also use this as their main timing resolution. Running LFOs and other modulation stuff at sample level would !drastically! slow things. So even if its not ticks, we’d need some other good default limit that simply sounds OK but is slower than raw sample time.

[Pysj]

@taktik

So even if its not ticks, we’d need some other good default limit that simply sounds OK but is slower than raw sample time.

+1!

Really need an fixed timing option that do not depend on song tempo settings. It’s not fun making instrument envelopes in 100BPM that sound totally different in 150BPM.

[dblue]

@taktik

Running LFOs and other modulation stuff at sample level would !drastically! slow things.

Yep. And just to put this into perspective for people…

Assuming a sampling rate of 48000 Hz …

Sample-accurate LFO output at 48000 events per second would be the equivalent of running at: 16 TPL, 256 LPB, 703.125 BPM

[Bit_Arts]

@Pysj

+1!

Really need an fixed timing option that do not depend on song tempo settings. It’s not fun making instrument envelopes in 100BPM that sound totally different in 150BPM.

Well, sometimes it makes sense, sometimes it doesn’t. For drums, percussions and even some tonal instruments I really like the fact the envelopes depend on the song tempo, while it sucks for others like pads, leads and similar stuff.

[kazakore]

@taktik

Yay, we are using ticks as event rate. Made sense cause all the other pattern FX also use this as their main timing resolution. Running LFOs and other modulation stuff at sample level would !drastically! slow things. So even if its not ticks, we’d need some other good default limit that simply sounds OK but is slower than raw sample time.

Didn’t expect it to be sample accurate, but maybe working alongside the 256 positions per line of the Delay. Assuming a 4LPB that would give a PPQN of quite similar to most DAWs out that.

Even 96PPQN of most MIDI sequencers dating back about 20 years would be superior to what we currently have with the LPB most people use. The oldest ones you can buy, running at 24PPQN, is pretty much where you stand.

But what precisely is this comment about on the front page?

High resolution timing

With the new timing engine added in Renoise 2.0 you can place events with an insane maximum resolution of up to 65,536 PPQ. This high precision allows live recordings to retain their natural, human feel.

What events? PPQ is what? Typo of PPQN? Pretty much utter bullshit though! And should really be removed or explained.

[kazakore]

Plus the LFO is made up of points, I kinda expected the amount of these you use in your custom curve to have an affect on the resolution, so using more would give you a smoother output than using few. So if you copied the curve from the Automation window, had the LFO going at one pattern per cycle, then you would get a change per line. If you had a cycle of 1/16th a cycle you would get 16 changes per line. As that is how many entered points you pass. Assume it must actually interpolate values between points and always change and Tick rate then?