Something Which Annoys Me

Ideas & suggestions
1

lets say I make 4 patterns.

in pattern 01 I make an automation to raise the trackvolume from 00 to ff,
in pattern 02 nothing happens automationwise,
in pattern 03 I make an automation to lower the trackvolume from ff to 00,
in pattern 04 nothing happens again.

no, if I play the song from 01 to 04, then stop, then go to 02 and start play again, the trackvolume is at 00, although it should be at ff.

so my question : is it possible that even if not in play mode, renoise can taker over automation-values when I browse and move through patterns ?

I know that the workaround is to set a 0cff at the beginning at pattern 02, but thats only a workaround, a real solution would be much nicer.

2

I understand the problem and must say that this also really annoys me :
Currently the automation works exactly like a visual representation for patterneffects. Nothingt more and nothing less. This means, that an automation exists for each pattern only and not for the whole song. In “normal” sequencers you always have automations for the whole song, (there are no pattern boundaries) and there you dont have the problem that you can also specify extra pattern commands to control the effect parameters.
What we have planned for the arranger in Renoise is that you can either view an automation as patterneffects or automation, to get rid of this problem. So at each point in the song, the status of an effect parameter is well defined at any position.
I got an idea, now that I`ve explained the problem to myself ;) :
When you change the pattern or songposition, we could simply search where in the song behind the current position the last automation/patterneffect was set, and set the value of the effect to this value. Why havnt I thought of this before ? :) Or have I missed something ?

3

I acutally just finished some “thats all very easy” post, but while typing it I realized alot of tricky things, so I had to remove it.

Its actually a thing with quite some things to look at.

Basically we have different ways to set values, automation and trackeffects (the 1xxx values for VSTs)

  1. a pattern has an automation for an effect :

if I scroll through the pattern with my keys, just read the values out the curve and fill them in.

  1. a pattern does not have automation :

the tricky thing is that, if I have pattern 01 with automation, 02,03 and 04 without and 05 with again, and I am currently in pattern 05 and switch to pattern 04, then, to make it work, renoise has to read the last automation value from pattern 01 (because thats the value which would be “it” if I just play from 01 to 04).

the bigger problem is if I have another automation in pattern 02 only, then renoise has to read the one automation from pattern 02 and the other one from 01.

  1. trackeffects :

and thats the real tricky part, because these things are set once and can be set for every value possible.

so, my first idea was to go “backwards” in the song everytime I start to play and get the values for every effect that way, or to go from start to the position I am currently at, but this sucks, because :

this might be a huge CPU-hog because of browsing the song-structure internally all the time, and if renoise does this only when I start play then I cant see the correct calues in the dsp effects window when I am in pause mode.

so the other possibility, which is not a CPU- but a possible memory-hog :

have a table with every track and pattern which monitors effect changes.

the point is : I am sure you already have a table for that to store the inital effect values for the song.
now you would need to expand that table in this way :

create a column for every effectvalue which gets changed anywhere in the song (no need to do that for the ones which never leave their initial state) and put their value for every line-position in there, so that renoise can simply read out each value which applies to a certain position within the song.

the point (as I just realize) is, these could be a kind of “hidden” automation-curves, except they dont have those “aliasing” options like linear or curve, because they switch from one to next without ramping. (and isnt that the point vs. line option in the automation window ?)

So, the conclusion after typing down alot of chaotic thoughts (sorry, I am drunk again :D )

the best way to implement this without having to change the renoise format at all (or at least not much) is to create a automation curve through the whole song for a value whenever it gets changed within the song (no matter if done by trackeffects or by a automationcurve itself) and hide it.

this way you can read out and display the correct value for any effect at any songposition without having to change the renoise format or the renoise code too much.

now the question is if I am stupid or brilliant.

4

No need to do this now, but with the new automation <-> pattern relationship
we’re planning, this searchback shouldn’t be a problem. And is planned.
(taktik, we’ve discussed this before, so you have thought about it :) )

Searching for track commands now might require some CPU load, but searching
for envelopes should be cheap, as will it be with the new automation structure.

To do it on-the-fly all the time is a bit more complex than doing it on playback
start, but with some careful caching of the previous automation clip for each
parameter it should be perfectly possible. Look at code editors today, they
parse and identify much more complex structures on-the-fly without problems.
And if it’s slow, many optimizations can be done: only the state of the current
track needs to be updated when moving the editcursor, and only the visible dsp’s.

5

(taktik, we’ve discussed this before, so you have thought about it )

yes, but we talked about how it !should! be, but not about a possible workaround for now ;)
Anyway, we should avoid these workarounds for now and make it fully featured in future instead. Everything else is more confusing than helpful.

6

ohh … :(

I thought this envelope thing would be a nice idea.

7

yes, but we talked about how it !should! be, but not about
a possible workaround for now

I wouldn’t dream of believing that you’re already thinking
out new workarounds now, after all this bugfixing :)

Anyway, we should avoid these workarounds for now and make it fully
featured in future instead. Everything else is more confusing than helpful.

And in the end only increases the total development time, increases maintenance problems,
probably also increases the amount of support we have to give.
(Plus, workarounds make you fat, bald and colors your teeth :rolleyes: )

8

oooh… don’t be sad :(

we’re only saying we don’t want to waste time to make it half finished,
when we’re going to implement it properly later… you should be happy, really :)