Sample modulation AHDSR timing curiosity

A little observation with the AHDSR sample modulation device. Now this all depends on how you look at it. I’m looking at this from a mathematical/programming angle.

The idea is to play a test sample which consists of a 1 second +1 sample (you’ll see in instrument 00 in the attached xrns below) and send it through the AHDSR modulation applying a 1 millisecond attack/with no curvature. So I set the AHDSR to look like:

pic1

Also (to make a small comparison) I did a similar setup in Tracktion/Waveform and rendered out the result from its sampler (the result of that is in instrument 01 of the xrns.)

In instrument 02 is my rendered out track from Renoise. Then I compared the beginning of the two samples. (Naturally you have to zoom in a lot because you want to look at the first 1-2 milliseconds of the sample(s).)

According to the Renoise minute time ruler, Waveforms ‘ramp up’ volume is 1 millisecond in length. The Renoise sample attack is more around 2 milliseconds in length before full volume is reached.

I thought what happens if I put 2.0ms in the attack time? Render out the track result (put in instrument 03). Comparing 02 and 03 instruments. To my eyes the Renoise 1ms and 2ms attack rate is very similar. I also get the feeling as though Renoise is also trying to apply some sort of very crude curvature (even though it should be completely linear?) and it looks more like 3ms has elapsed before the sample completely reaches full volume.

You probably going to say, who the hell cares? What’s 1 millisecond here or there? Nobody is going to notice. I agree, for most musicians chances are this is all a moot point. It is just an observation. Certainly a little curious algorithm/math result considering that from the users perspective they have specified a 1ms completely linear attack volume ramp up. After all that is what is specified from the user interface. You may have things like ‘anti-click’ and probably other things going on behind the scenes. But I do know that if I dial in 1ms attack time in Tracktion/Waveform I get a 1ms attack volume ramped up time sample on output (shown in instrument 01).

ahdsr.xrns (15.3 KB)

1 Like

Been discussed to death , I created a topic 7 years ago …the quircks are still there
Imho the envelopes are only more or less accurate at the starting point , everything beyond that ( when using the drawable envelopes ) is kinda meh …no instant attacks etc…there is always this interplation time and depending on that interpoaltion time , the envelopes will NOT reach their full modulatin point point ( see posted topic )
Full frequency of ringmod and filter is never reached when drawing fast repeatinge decaying envelopes in the envelope window .
It’s something I really want the team (TAktik) to fix , if the envelopes would be accurate ( at any point ) smaller than 1ms I would be happy

Ah, I forgot about that topic.

Ok, maybe not surprised that it would be too much to get into.

I’ll give the reason why I thought this important. You see I’m not really all that bothered if this works or not. After all a musician just kinda knows that the more they move the attack slider to the left, the faster the attack, the more they move the attack slider to the right the slower the attack. Likewise for the release.

But, from a moral point of view the Renoise user interface boasts super great numbers here. Taking the Volume AHDSR device it claims to achieve (for example) 0.0ms of release [I interpret that as ‘clicks and all’ to the sample rate shear cut release. Then it is up to the user to ‘dial in’ how much ‘anti click’ attack/release wanted?] However (as we know due in part to fixed anti click etc…) currently doesn’t produce that output that has been dialed in. Also If I dial in say 10ms of attack get closer to 11ms of attack.

Also I notice that a lot of other ‘DAWs’ set a minimum that there dial/slider can go to. For example in Bitwig 3 the ADSR release dial I think in the sampler has a minimum of 10ms (if so reminding the user there is going to be at least around 10ms of ‘release processing time’ on this sample(?)) In Waveform/Tracktion sampler the minimum attack/release dials seems to be 0.00ms. From what I can quickly see Tracktion/Waveform does pretty much honor those figures better than Renoise.

Anyway, Raspberry Pi/M1 is top priority.

I have the impression that you come too late with this suggestion (actually not sure if there is any in here?). In the end a lot of good songs are made with Renoise and if the instrument section is too imprecise for you, thankfully there are a ton of good VSTi alternatives. I agree would be neat to have a really precise timing mode in Renoise, completely independent from ticks. But in the end, a lot of other mainly maintainance stuff needs to be added first, like you said m1 support for example. Also, as far as I understood Taktik, he considers Renoise being too old from a conceptional point of view to implement such fundamental changes. It is what it is.

I only wonder if such stuff could be easily improved by really simple changes, e.g. by doubling the possible tick resolution for example.

The envelopes variations like AHDSRr , fader are essentially the standard envelope window with specialized controls .
All can be done with the standard envelope and sadly enough all errors also apply to the other ones ( fader , ahdsr ) .
Imho it needs a rewrite

Yes, indeed. The main problem is and was backwards compatibility here: We tried to generally improve things in the new modulation system while still being able to perfectly play back old songs with the old modulation system. To do so we had to do a lot of compromises.

So there’s no easy “fix” and this indeed would need a complete rewrite, which unfortunately currently is out of scope. So for now, use the modulation where it works for you - for everything else use plugin instruments. That’s unfortunately all I can do for now.

3 Likes

I understand completely .
But , the renoise 2.0 overhaul from speed to LPB also gave the user a warning when loading an old song .
Perhaps the same can be done when the improved envelopes (underlying ticks engine ) have become a reality .
No matter what , Renoise still Rocks and you’re brilliant to keep it going !

Just to clarify (because I’m a layman) what do you mean by ‘ticks’ in this context(?)

I use the word ‘ticks’ and where you come across it is in the Song Options TPL or ‘Ticks Per Line’. As I understand some pattern fx commands use ‘Ticks Per Line’ to break up a tracker line. So if you have 12 TPL set, and say the pattern fx is an arpeggio ‘Axx’ command, it will change/arp 12 times per tracker line. I suppose it comes from old trackers (Amiga etc…) as a way of controlling the speed of repetition of a given pattern fx per tracker line.

AFAIK changing TPL doesn’t alter the ‘upgraded’ (or newer) envelope modulation device output of the sample. The old volume envelope modulation device did depend on TPL i.e. something around Renoise <= 2.8.2

This is the ‘old’ volume envelope device in Renoise 3.3:
pic1
(Notice the ‘upgrade’ button at upper right.) This dsp device is dependent on song TPL.

The ‘upgraded’ envelope device is:
pic2
AFAICT (unless there is some other internal fixed ‘ticks’ value somewhere or whatever) this dsp device doesn’t seem effected by the song TPL.

Yes, they are not using the TPL settings: The internal new modulation sampling rate is hardcoded at 256 times per beat. The old compatibility device rate is 24 times per beat - which used to be Fasttrackers internal tick rate, if I remember well.

2 Likes

Ah, thanks for the insight.

I was referring to my findings that even in unsynced envelope mode, the graph is somehow dependent on playing speed (at least varies a lot, similar to an interference or whatever). This is very good audible with a fast pitch or high resonance envelope (of course not so much with volume envelope). So then I assume Renoise will somehow “remap” the points to this 256th grid on a speed change…?

Again I’m a layman here @taktik. Let me hypothesize/throw out a question.

The ‘modulation sampling rate’ is hardwired/‘quantized’ at 256 times per beat. If you were to increase that value say to either 512, 1024, 2048 etc… Would your modulation dsp become more and more ‘accurate’ on output?

You could say no, it’s more complicated than that. I appreciate that this is complicated (I know, I know.) Would it be safe to think that that ‘256 times per beat’ is one reason (of possibly many reasons) for the inaccuracy at fast(er) rates/values? (If that is the case, then I can mark your answer as a kind of ‘solution’.)

And if this is the case, is time resolution/envelope accuracy then bpm dependent? If so, it might make sense to double/quadruple working song bpm for faster/more responsive envelopes… I’m thinking about pseudo FM synthesis here, too…

Just tried this out. very interesting. pseudo FM effects do scale with tempo > faster bpm yields usable “FM” results all the way down to 1 ms time scales (at 999 bpm) on looped pitch envelope modulation :+1: @Neuro_No_Neuro I’m @ing you, bc, you might be interested to know this (among others, no doubt)

might have to start working at 600 bpm now, lol

2 Likes

No. Because this is just the rate where the modulation stream is read, target values are calculated and then get applied. All applied target values (Volume, Pan, Pitch, Filter params) are smoothed via a simple exponential interpolation in sample time though, so so at some point when increasing the modulation rate the parameter smoothing “smears” away the changes.

To fix this problem, the modulation must be read and applied directly at the sample rate - without any parameter smoothing. This effect can’t be archived by simply increasing the modulation rate.
This needs a different way of calculating and caching the modulation, especaially to avoid too much processing overhead. This isn’t rocket science, but is conceptionally completely different from how things used to be; thus both ways of applying modulation are hard to merry and maintain under the hood.

4 Likes

This works around this problem a bit, but won’t fix it and won’t give you a FM (sample rate) resolution.

You really don’t need to do everything in Renoise. Specialized plugins can do this a lot more efficient, with a lot more options to fumble around. We actually also never claimed that we can do such things.

The modulation system, as it is now, still has a lot of other benefits IMHO. Simply use it where it makes sense and is good at, and don’t try to use it for everything else.

4 Likes

Oh, I know. I just enjoy pushing the envelope and doing as much as I can at the edges of renoise’s capabilities. It’s my idea of a good time :upside_down_face: I’ve got plenty of VSTs for real audio-rate FM/PM if I want it. Thanks, though, and keep up the good development work! Renoise is the best :fire:

5 Likes

Well, @taktik - I’m happy that the envelopes and other modulators currently can get some very abstract effects, because working solely in Renoise is my musical dream. You’ve written such efficient code for everything else, I use it all, and only use plugins for ‘mastering’ the sound - some things just don’t sound the same without it, like tape-effects, mixing board artifacts, etc.

I do hope you’ll continue your great work on this beast of a sequencer and provide some of these updated modulation and sampler requests, because Renoise is fantastic at making the more abstract types of music that other sequencers just don’t excel at. Microsound/lowercase/throughcomposed music. I mean, my latest album to be released on Audiobulb March 2nd, is done entirely in Renoise. It’s that good. Really, take a listen to it. Sounds like a souped-up Max/MSP album, except it’s not generative.

And here’s a newer, gentler version of my pseudo-FM instrument. This is more along the lines of modular synth FM, not the PM Yamaha stuff.

FM Sine Wave Generator.xrns (2.1 MB)

3 Likes