Quality Questions

Hi.

At the moment Renoise is unusable for be, because it’s quality.

The biggest problem is with automation:
Volume automation now sounds like this (mp3)
Volume automation that I need (mp3)

There’s almost the same problem with glides:
Glide with Renoise (mp3)
Glide that would be usable (mp3)

Renoise’s user interface looks really good, especially when you right-click somewhere, and the menu fades in and out. I wonder why it’s so hard to make this working with volume, VST, VSTi automation too. It seems that the GUI has more priority. But when the GUI has more priority than the sound quality, it is not “pro audio”.

There are also some other little problems I have found:

While a wave starts like this,

…why ends this way?

It should start like

…and end like:

Please correct these things to make Renoise one of the best audio software. And don’t say that these things with automation and glie are “features, not bugs”, and don’t talk about FastTracker2 compatibility, because Renoise absolutely not FastTracker2 compatible, and it shouldn’t be. If you want to run FastTracker2, you can run it with dosbox, either on Linux or on a Mac OSX machine.

I think these aren’t big requests, but they are mission critical.

some answers/questions:

1] at which speed did you record that mp3 samples? speed (as it is for every tracker) affects resolution of commands.

2] did you use ReNoise WAV writer, or did you use a virtual cable to record the WAVs? The problem you report should be far less noticeable using the WAV writer with cubic or arguru interpolation

3] the difference between ramp up and down could be due to due fact that the first has been made using a cubic volume envelope, while the fade out has been made with the standard sample fadeout, which is linear. Use a post-sustain curved fading-out volume envelope to avoid this. By the way, I don’t see why a smaple must start and end that way.

4] we reckon that one of weaks of ReNoise is note and command resolutions, and the developers are working at this. What you can expect in a near feature is doubling of volume range from present 00…40h to 00…7F. Also, in a more far future, a general increase of resolution (probably fixed to 256 ticks per row) will be implemented. See “A question of speed” for more info.

Much to my own surprise I was actually able to recreate this quite easily.

If you automate the volume of a track, it does indeed produce these “jumpy” results, regardless of linear/cubic envelopes, and regardless of being played back realtime or being rendered to wav with either cubic/arguru.

Fortunately I don’t really have much use for automating the actual track volume, I prefer to do volume fades via other methods (like the individual instrument/sample volume) which have proved to be smooth enough up to now.

Still, weird stuff that could definitely be handled a little better in future versions I’m sure.

There are 4 ways to automate you have 3 envelopes options: Point, curve, and linear.

You can also record your automation into the track or to the envelopes or you can write into the pattern how you want the volume.

Try use point automation to draw the way you want the curves to look. Then you can switch to linear to interpolate between the points.

Also you can automate by hand. by setting up two values marking them and pressing CTRL+I to interpolate between them.

However you do have a point in that there is no way to interpolate between two close values in the automation.

This can be tested by putting the bpm down to 32 and the speed up to 12-16. Now there is plenty of time between track position 1 and track position 2. Then automate the volume from 0 in track position 1 to 100% in trackposition 2. Eventhough there is plenty of time between the two lines, and you use interpolation Renoise will jump from 0 to 100% volume when it reaches track position 2.

I hope the developers will make it an option to read the interpolate between the lines with the track automation envelopes.
This could be a option for each automation envelope. Because it will increase cpu load if Renoise has to read the automation also between the lines.

As for the command I don’t know what command you have used.
But atleast one way to achieve the effect you want is by using the 2xx and 1xx command.

Yeah… Instruments envelopes update per tick. And track envelopes only update per line/row. This is pretty bad if you ask me. You are forced to use high scroll speed (low speed setting or very fast BPM setting) to compensate for this.
Lets hope renoise will get better resolution in the not so far future. B)

Dear It-Alien!

Please try to make this little song sound smooth:

demo - volume automation.rns

Implementing 256 ticks per row is not enough.
A pro audio program should interpolate between them.

While these things aren’t fixed Renoise is useless for professional use.

Might be an idea to set the tickspeed in that to 5 and double the pattern size… But I understand, what you mean.

your problem is that you try to do it with very low speed and tempo…

try this version for example… sounds smoother?

are you serious??? :blink:

EDIT: it gives you the resolution of half of microsecond at 120 BPM!!

OK.

So, this was the original one.
demo - volume automation.rns

And you say that this is the perfect solution? :huh:

demo - volume automation - The Smoothest.rns

THIS IS A JOKE, NOT A SOLUTION!!!

well, it sound smooth to me, doesnt it? ;)

You could of course do some of the volume-effects with different instances of the rni-instruments.

But, this sounds smooth to me, too. The other solution is VSTi :) The loudness-effect could be interpolated through VSTis or extra plugins.

Man, this is not a solution. This is a JOKE! :angry:

And this is not about just volume automation.
What should I do if I want to automate a VSTi’s cutoff freq, for example?!

How would that be done with Cubase? Or Logic?

I want to be honest, I don’t get it. Controlling CC-Filters or whatever with Cubase works the same, doesn’t it?

The other thing is, that whatever tickspeed or BPM-Setting you use, only the finished result is important.

the thread-starter truely has a valid point there and one should not have to circumvent the highly digital sounding volume ramping by cranking up the speed until the screen looks like it was on amphetamine.
i encountered the same digital sounding automations with filters, which in the end, had to be modulated by LFOs to make them sound reasonable. but using LFOs hinders flexibility if you’re not after looped modulation patterns, so like almost every workaround, it implies a drawback.
interpolating between modulation points / rows would be the solution but would certainly bear a higher stress on the CPU.
nevertheless, this is a must feature if you ask me.

Ah, okay - the interpolation has to be “Tick-Independent”, if I understood right?

either that or maybe rely on a variable (user definable?) multiple of the actual tick setting.

I am supporting the threadstarter as well. The standard speed for getting good sound for easy modulations is F03. To handle more extensive curves you have to increase the speed, but then you are loosing control of the song (the patterns are just too fast), and you have to adjust all the tracks to the new speed. The approach from trackit schowed that. The effort is just far too high to present this as a solution. I have no fun to control my track at that speed, because the main concept of the tracker -great overview, flexibilty, fast work- would be lost.
The solution would be the resolution-concept, which is discussed in “A question of speed” with zooming in and out. A true interpolation, so that the modulation curve hits exactly all values in time is a must, and not every step regarding which speed you have on (like it is now).
This problem is for me the most important lack of renoise.

sure renoise have room for improvement, i didnt say its perfect :) and BTW increasing resolution is one of the wanted features for me too… I just offered him a workaroud so he can improve his results until then. Yeah, at speed 1 and high BPM its redicilous, i didnt suggested to do that :) but at speed 3 and BPM 92 its totally normal and relults are far more smoother than his original that had redicilously low bpm…

EDIT: It could be even perfectly normal with doubled BPM of 184 (at speed 3) most of my songs are at speed 3 and bpm from 150 to 190 and i dont experience any difficulty in pattern flow

Totally agree. See my avatar.
Taktik, go on and do something for this thing. Its the quality that means so much these days.
…And, please code 24bit standard output to render options!