As we’re planning increased timing resolution in Renoise, some important questions come up. One possible and very flexible solution is this:
Tracks contain note events and command events that each have a timestamp attached to them. This timestamp might be (linenumber, delay) where delay is a value xx=00-ff (hexadecimal) or 0-255 (decimal) that means a part of a line, xx/256. The largest changes here are
Increased timing resolution of 256 timeticks per line. This will allow finer placement of notes and advanced edit operations like humanizing and groove quantizing.
An event has a line/delay position, not the other way around found today where a line has a note in it. This means that a line might contain more than one note on/off! To visualize this, zooming in/out in time in the patterneditor must be implemented, and some sort of color code or other marking must be applied where not all notes can be viewed. This will also allow very short notes (down to 1/256 of a line).
Pianoroll and midi import/export will take full advantage of this change of course.
Now we want some opinions from you:
What should happen with the current “speed” parameter? This parameter is here from the old days of FT2, and is good to have for compatibility. But it causes a lot of confusion, and with a change like this it will be IMHO obsolete. There are mainly two things this parameter is used for (any other?):
a) Getting a higher pattern resolution either by setting it high (more resolution within a line) or setting it low (more lines per beat). This will be obsolete, since the new resolution will exceed this by many times and zooming in/out will let users view more the pattern with or less lines per beat. It could be replaced by a “lines per beat” parameter though, to set the number of lines a beat should be in a song, or a “normal” zoom level.
b) Making a groove by using speed change commands in the pattern. This will need some replacement. One idea I have here is to introduce a new parameter to be changed as parameter commands in the master track, a tempo multiplier. This can be a value 00-ff where for instance 80 means normal tempo and lower/higher values means lower/higher tempo relative to the current tempo.
Any other comments and ideas for this are welcome here. Does this sound perfect? Or do you have an even better idea? Or will it ruin your way of composing?
This future feature seems to scare me a bit… the whole conception of tracking could change… and I would be greatly sorry about this
But the idea of a “zoom” seems to stick in my mind as there could be something usefull hidden in it… hmmm
Let’s brainstorm a bit
I visualize it this way:
-You are working on your normal pattern
-You have to place a note somewhere between two lines…
-You click on the first line… (with some function key pressed)
-a new mini-pattern splits the current pattern between the line you clicked and the next one… showing what’s hidden in the middle… (Somewhere in the configs you are supposed to set some mini-pattern option like the numbers of lines our mini-patterns contains.)
-a new click puts the two half patterns back toghether
-The line you edited is shown in a slightly different way… like a color or a small dot in the beginning…
Every line would have that mini-pattern popping up… non-marked lines could contain just empty non-edited mini-patterns. this way playback will be linear as it is now…
Another way to get advantage from improved timing could be “The Slider”.
when you function-click on a note a slider pops up under your pointer… You can select a delay value for the note you clicked by moving the slider up or down…
As soon as you release the mouse button the note delay value is set (with 256 timetick per line precision) where 001 means the note is played almost right after the the previous line… and 256 means it is played almost before the next line. Improving this might lead to suppress position 128 in the slider because it will mean “play the note exactly where it is”…
Another point to keep into consideration is the Groove settings.
I honestly wasn’t able to juice out anything good from those sliders… (my fault?) so I wonder if improving timereso will somehow compell you developers to work on some new/better way to swing patterns…
Of course unless it’s to the better for everyone I assume
Exactly the point of this thread. Sadly, it hasn’t got a lot of response yet. Compared to the potentially large changes that might happen, that’s strange IMO.
Pretty much like what we’ve thought. Except that I haven’t thought of it as a “mini-pattern”.
Yes. This is what will make it completely backwardscompatible.
We were thinking more like a delaycolumn for each note (and effectcommand), with values 00-ff where 00 means exactly on the line and ff=255 means just before the next line. The column would be optional like todays vol/pan.
The delaycolumn alone will give higher resolution. For a lot of people, only using this will be enough. For instance, when just moving the start of a note slightly off-beat it’s much quicker to just enter a delayvalue in the pattern than to do all the zooming in and out.
So what will be gained by the zooming? The point is to remove the biggest (IMHO) limitation of the normal tracker pattern and be able to (within one notecolumn):
make notes shorter than one line
put noteoffs and ons in the same line with a short delay between
put more than one note and noteoff on one line
When zoomed out, some mark must be put next to some lines to show that there are more details not shown, since only the last note can be shown.
What I’m not sure about is how the zoomed in view will be like when it comes to the delaycolumn values. Any ideas?
zooming would be a long-time wish come true… i was about to make that suggestion some time ago… i just wonder what you will do with the track effects, afaik they work for one line… so what happens if you want to make a volslide or noteglide or arpegio…? i guess you have to zoom into highest detail for that and write a whole lot of commands?
This new structure will allow much easier and better implementation of operations like humanizing and quantizing. I recently thought of one idea for a “groove quantize” commands. The operation can take a track as input, or a block which it repeats, and use the rythm there to quantize the wanted notes.
Yeah ok I can see that … I just thought my suggestion made more sense from a programmatical / layout POV.
So how would existing delayed notes be handled? Would they be “automagically” moved to the appropriate sub-line? Or would they stay on sub-line 00 and just keep the existing note delay command? What if you issued a note delay command on an already delayed note?
I think the current delay command must be removed. The speed change commands will then be changed to tempo multipliers (or whatever we choose to replace them with) and delays will be translated to the new delay. A small quantization error will occur, but it won’t be more than 1/256 of a line big.
Just an additional suggestion:
A function to spread the notes to unoccupied note columns.
So if you for some reason has 2 notes in the same line you could easily spread them to two different columns (thus making you able to see them both in 100% zoom)
A nice idea, wouldn’t be hard to do. Also, a better recording scheme would be nice. One way we’ve discussed is to store all the recorded notes in a hidden “recording track”, and apply them to the pattern after the recording is finished. Then the notes and noteoffs can be much more intelligently placed than by choosing a free note column in realtime, since the notes not always can sound with the full intended length now. Then different recording modes like merge or replace will be a matter of applying the notes afterwards with different algorithms.
Thats not a bad idea.
More ideas (just brainstorming )
For instance it could be nice to have the notes placed fram lowest to highest pitch (from left to right) when playing chords etc.
Or sometimes you would just split everything up to let say C3 to the first x columns and the rest over C3 to the last y columns. This way you could easily split left and right hand etc. This could be done after the recording by selecting pattern/track/block.
And another thing could be to select manually which columns it should write on during the recording. If you have planes to have that mute button on each column, then I guess you could have a rec button there too?
This way you could easily do several recordings on the same intrument(same track) (guess its not that important if you can use the same vsti on several tracks).
I definitely second that. I hate it when I try to record on a track with multiple columns, where one column already has notes entered on it, and then I record into the track and my old notes get interfered with.
First, I absolutly agree to a new resolution feature.
The above idea is a little bit too complex and circuitous. You have everytime to click on the (+) to edit it, zooming in and out all the time.
Eediting a track in this way is a horror, e.g. you can not use the edit-step function etc.
Why not implement a zooming feature for the whole pattern? You could replace the speed-button with a resolution-zoom-button and mark each track (not each note) if there were notes editied on a higher resolution than the current selected one.
For example, you have set the resolution to “06” (default) which will be a pattern resolution of 64. When you want to edit in a higher resolution, you have to set it to “03” and the whole pattern “zooms” and you get a length of 128. “02” to “256” “01” to “512” and so on.
So you can switch fast and easy between different resolutions and edit the whole track at once instead of clicking on each note.
So you just could replace the speed-button with a resolution-button; It will allow to load old tracks with speed-settings as well; simply assign the speed settings to a higher resolution.
For example, the following sequences are the same (bpm)speed with different note-resolution:
The benefit of the second preference is that you now can add 1/16 notes easyly (to achieve e.g. shuffle beats); and you can not add notes only, but also effects and midi-cc, to achieve e.g. great (midi-)delay-effects (which no efx-processor can provide).
This is for professional work essential.
As Jonas mentioned this method is implemented in the Amiga Miditracker.
I think this method is more user-friendly, because clear and easy to edit.
Furthermore I guess it is easier to implement.