When editing a song and eg. switching the track volume down with 0C00 then back to full with 0CFF I would find it useful for renoise to take the most recent command in that track as the one to do. The problem is when scrolling through patterns it would be nice not to have to manually adjust volume commands, switch DSPs on and off etc or find the pattern where the relevant command was.
The way I`m suggesting that pattern commands are interpreted is as if you wrote
0CFF = written
0CFF = not written but still read by renoise
0CFF = not written but read by renoise etc.
0CFF
0CFF
0C00 = written
0C00 = not written…
0C00
0C00
etc.
i.e. you would only have to input the first command.
This would be a huge help to me especially as the workaround of using envelopes is a lot more laborious ( or actually writing in the commands at the start of every pattern especially as there are only 4 pattern command columns!)
you answered to yourself: we only have 4 columns! where should we put more commands if everything is filled by old commands always repeating?
I think this is an ability which tracker users develop with time… it’s like a C++ programmer which takes care of buffer overruns, pointer positions, memory management…
according to me, such a feature would be at the opposite of a tracker philosophy: complete human control over computer-aided composition.
This is not necessarily the way renoise would have to interpret it, I`m sure this must be able to be programmed behind the scenes maybe extra invisible pattern columns. Either that or the pre analysis mentioned or maybe a backwards analysis.
Im sure the devs would be able to find the least CPU hungry / latency causing option.
Also still with regards to this 4 visible columns is still not enough to overcome the inconvenience of having to pre play up to the point you wish to edit or re-switch off DSPs, adjust volumes manually. There are large numbers of commands to be accounted for in a large composition. 4 columns per track is not always enough in this context.
Yes this is an ability tracker users develop with time (just as workarounds are). For me the major advantages of tracking are about getting down my musical ideas accurately and quickly and hopefully this will increase with tracker development. I would rather spend my time editing throughout my songs on the music rather than having to repeat commands I have already put in to hear playback correctly. This doesn`t happen all the time when I have skipped down a couple of patterns (and more often when skipping up) and renoise is playing differently than if I played from the beggining (and how I intended playback to be).
I dont see how this gives more control to the computer as it would just mean the computer was doing more what you told it to do / intended it to do in a musical way. For me the tracker philosophy is more about speed and convenience and getting my ideas down and played accurately. Although I dont see the conflict here anyway!
Isn`t this the case already as now you can set pattern commands which can last the entire song? You can also check this by looking at the DSPs but this would need to be checked and done if you wanted playback to change at a particular point anyway.
Would this not occur anyway in playback if you had forgotten to switch the effect off with a pattern command? With a new way your settings would be up to date and any new ones you put in would always be played from that point on. Wherever you were playing the song from would be accurate.
I think though however from what you say later also maybe other features could be in order so you could check/ back reference your latest commands…
Also if this mode was detremental to anyones way of working I would say as with any other feature of that type that it should be configurable on/off. For me though this mode would be a big improvement for renoise.
On one hand moving backwards to get everything to sound as during continuous playback makes you listen to your song’s flow more which is good, but on the other being forced to do so is still one of the most annoying drawbacks of trackers to me.
In my opinion, effect values are a smaller problem compared to long samples - like freezed tracks. Constant moving backwards to a point where a long sample starts is even more problematic than effect values.
I know there’s a workaround - a sample can be triggered once a pattern with a sample offset - but that’s just a workaround (and it’s a pain in the @ss anyway).
I’m definitely for having an option of module preanalysis (effect values buffering, calculation of sample offset for long samples at the current start playback point) and/or prerendering for the cost of longer time before the playback starts.
An idea just came to me while studying data warehousing stuff - why not have checkpoints instead of prebuffering and backward analysis of the module? On the beginning of a pattern, you can buffer all the info necessary for making the playback sound as during continuous playing - like track volume, note panning, sample direction and offset for samples triggered in the previous patterns etc. - and use that when the playback starts. I think this might be a good solution to the problem as it doesn’t require preanalysis (the info can be filled when placing notes) so the time to wait for playback to start wouldn’t be long and is not very memory intensive either - just a bunch of values once a pattern. The buffered values could even be shown on the top of the pattern so that the user also knows what values have been set earlier.
we had some discussion like this some time ago (but I am too lazy to search atm), my idea back then was the use of “hidden” envelopes, which keep track of all effect values through the whole song.
And about the long samples … well, with the 09xx command renoise can slice them only into 256 pieces, and for really long samples this is very, very coarse. if you have a 4 minute backing track, one slice is 937 ms, nearly a second (!). so, there will be a big difference between a 0978 and a 0979 command for example … a whole second. so aslong as the sample is not exactly bpm-matched an internal 09xx handling of long samples is useless. for this renoise has to be able to handle samples byte-exact first (atleast internally), or the “backwards” or “start at any position” thing is impossible.
Exactly. I’m working on thinking in 64-bits internally as we speak
Moreover, as soon as I’ll start thinking with MMX/SSE2/3DNow optimisations, I will call myself “Paulie Phonick ULTRA” (or “Paulie Phonick MAX”- haven’t decided yet)
I`m not sure though if a simple unoptimized seeking for the last value of an automation or patterneffect on every song start would be that slow. Without asking my calculator, I guess this might be ok for songs that contain max 0xff patterns.
We should try this at least. Even if its too slow, a simple per pattern caching mechanism might solve this without making it too complicated to handle.
But before I start discussing dev stuff here, I just want to say that we should think of an easy solution for this problem for the next release. Its really annoying for everyone (newbies and tracking pros) that the status of all the effects is different each time you scoll a little bit through the song. This makes it really really hard to work fast as you have to listen from the beginning of a song every time to know how it wil sound at the end.
It doesn’t need to do a “backwards” read, but rather it should just work how envelopes work. Basically, it knows the value of any effect/etc. at any point in time, so if you move halfway through the song and start, it just starts with those values.
Sure. Searching envelopes would probably be fast and easy. Searching pattern commands would be slower and more complicated. But nevertheless, it only needs to be done once, when starting to play, so it can’t be that bad.
I’m no programmer but it shouldnt be that hard to calculate this really fast?
Some smart caching like keeping it cached to each individual track in each pattern (and later clips). So if you change something in a track it will only recalculate that track, and if changes was found when recaluculating, it will also check the same track in next pattern until it finds a pattern that has not changed. Then it will check if the changed pattern(s) is later on in the pattern list. If not, it will stop any further recalculating and keep the old one…
Keeping this as a background prosess so its ready long before you even hit the play key…
