Quality Questions

This problem is caused by the relationship between ticks and lines.
This is also the problem Choice expressed i believe more than a thousand times but then in a different way.
You can avoid this by extending your tracks and raising the speed (but in that case you also have to raise the BPM to compromise the tempo-loss).
But you will bump against the problem that the automation resolution is bearably handlable due to the lack of a zoom-feature (which is on the schedule to be implemented in one of the upcoming two revisions)

And like IT-Alien said:there is also brainstorming about adding a higher tick resolution of 255 which gives the possibility also for automation to have smoother scales.

The slide command effects are going to be fixed as well.

I got enough resolution for what I do. I usually end songs with an abrupt stop. then start again … oh oh oh… ~renoise is still the best tracker in the world~ … la la la :w00t: :walkman:

Another problem when raising bpm is, when using renoise as master and (bpm-)synching external midi-synthesizer. For example controlling the LFO-speed or an Arpeggiator. So raising bpm is in most cases simply no option and dependant on the song simply unwanted.

Nice to hear. But the zoom-feature should not just zoom concerning the steps; e.g. when editing an automation curve on “zoom” F6, say a simple linear curve from 00 to 63, and then zooming to F03, all steps should have a value, not every second (or fourth). So doing an automation curve in every zoom greater than F01 should have an interpolation like in F01.

Are you kiddig? Do you really think that extending patterns and using extreme high speed is a solution?

Propably I do not want to zoom anywhere. I need interpolation between rows! And I can’t understand why it is so hard to implement…

Well it would only be necessary to calculate the interpolation values one time and that when you write it in.
Once you write two values in it would automatically calculate between the two values and write those values down into the invissible ticks between the lines.

However I can see one problem if the interpolation is for pattern command.

Lets say you dont want it to interpolate?
You want a sudden cuttoff like this:

40
00

Now if you have a resolution of 16 ticks between the two lines and you play it slow it would interpolate.

Therefore I think the interpolation should only be for linear and cubic envelopes.
This way you can use envelopes when you want smooth stuff and use patterncommands when you don’t need smooth stuff.

Btw I don’t really need to be able to zoom in. I think it is one of the advantage of trackers that you dont zoom.

Well, maybe renoise is not your ‘pro’ tracker afterall if you do not accept some of the usual tracker tricks…

I don’t agree that if someshing was crappy in FT2 then it should be crappy forever.
On a ~33MHz i386 with 11kHz/8bit samples this thing wasn’t matter, that’s true.

I used FT2 for many years, so I know “some usual tracker tricks”. And I don’t think that crappy sound quality is a tracker “feature”.

ok, we acknowledged your point, and we showed that we are already considering an extension of resolution capabilities of ReNoise.

In the meantime, please use another music application of your choice, if you find this unusable and doesn’t fit your professional needs.

OK, thank you.

Unfortunatelly, no other music application fits my needs, but Renoise with smooth automation would be so good… :unsure:

Hehe, that’s the problem. Renoise is the best app I’ve come across, but it still lacks a lot of stuff (well, that can be said about most apps I guess). We’ll just have to sit tight and wait, and vote, and nag the devs, while using it the best we can despite some limitations.

If some other tracker would fill my needs better, I’d probably switch in an instance… but Renoise sure looks like the most promising candidate right now. ;)

funny how users consider normal nagging developers, but not normal aswell to be nagged by nag screens for registering software :rolleyes:

Oh, maybe it was a bad idea to send Taktik that virus with a popup which every 20 mins says “Please consider implementing proper interpolation for automation in Renoise”? :lol: :P

I take it back, don’t nag the devs. And add more nag screens for the unregistered version - I’ve paid so I don’t mind. :D

ps. I didn’t actually send a virus. ;)

Yes, the automation should not be bound (quantized) to ticks. We will take care of this in a future release. When exactly? Sorry, cant say.

Why isnt it already? Because its quite hard to realize in a tracker environment. It will require quite a bunch of more CPU cycles but if you dont want smooth automations, you still could use the point mode then…

Thats why I think it should be optional for each envelope as a checkbox.
So it only calculated when needed.

But I don’t really understand what so hard and why it should take up that much more cpu.
Because the instrument envelopes already do this…

Isn´t just a matter of precalculating the volume for each tick between to points and then reading the volume for each tick.

I, too, think this is a big problem [as I’ve given it full points in the poll].

I’d suggest the same resolution as Logic, a professional music application. Logic has 960 ppq resolution. This means: 960 points per quatre note. So this is equivalent to 960 ticks per line in Renoise on speed 6 or 480 ticks per line on speed 3 [right?].

are you sure its 960 per quarter note and not full note?

This is a topic on its own. Automations can/should have a sample precise resolution.

Its not just about volume. Its about any automateable parameter…

First I’d like to say I think it’s dangerous to try and guess what a user’s intentions might be when writing software and therefore think that if you incorporated interpolation - that it should be a manual selection. In otherwords I think a very good point was made about people who might not want to use interpolation and use the current implementation of the value sliding intentionally. So if you implement interpolation in the future, don’t impose it as the only option.

Secondly we are talking about extra cpu cycles here. I’d like to offer a suggestion if, and only if, it makes sense. I’m not sure what the underlying data structures are like in Renoise, or how you would implement this on a technical level. But can you not precompute the interpolations and store them with the pattern data instead of interpolating the values on the fly as the pattern plays? Perhaps I missed something and this is what was meant… Just the fact that there were more values to read in, and there for more calculations to make. However my impression was that people are concerned about calculating the interpolation algorithms in realtime as the pattern is playing. Just wanted to offer the concept of pre-computing the interoplation values once and storing them. Obviously this would have to be driven by an event/listen based system if the user edits the pattern and changes the value(s). But here again you only need to recaculate the edited portion.

Just an idea…

Just guessing, I would say the interpolations per tick are very marginal (there’s not many ticks per second) compared to e.g. multiplying sample volume @ 44100 times per second, and a volume effect is very cpu light. Precalcing many parameters on many patterns might cause some mem usage, so that’s means another (possibly also marginal) problem. Anywho, this is pointless to try to figure out… the best way is just to do it and measure the difference in cpu. God, I think I’ve been a programmer for too long :) I’ll shut up now.

Anyway, great to be back at the forum after a well needed vacation :D