You could sort it with color, symbols, whatever. The idea isn’t hard to grasp, but visualizing it without creating a disproportioned abomination might be. But everything can be contracted and expanded seperately, or with the use of the switch mentioned.
Then I guess you’ll be only pleased to hear that you’ve misunderstood. When zooming the whole pattern will be zoomed by the same amount, much like you suggested.
So it is just a matter how to visualize a used higher resolution in a track in the best way.
Related to that, this idea
with different colors might be a good idea, but what colour you choose when 3 or 4 different efx were used in higher resolution.
Maybe the amount and kind of efx could be shown on the top of each track and not on the positions.
I think the most tracker user are accustomed to the usual illustration like
00
…
63
64
…
127
please read the previous posts more carefully. First of all, we will introduce a delaycolumn with delays 00-ff which will be in 1/256ths of a line. This will replace the current “delay x ticks”. The speed parameter doesn’t fit very well into this new scheme, so I proposed removing the speed parameter, and replacing it with a tempo multiply parameter instead of speedchange commands in the pattern and a “x lines per beat” parameter instead of the song speed. The tempo multiply command can be much more accurate, 00-ff, and thus replace speed command for creating a groove. How to best interpret this multiplier value I don’t know yet other than 80=normal, 00=slowest speed, ff=fastest speed.
As a frequent user of speed changes, can you think of anything that can not be done with this scheme? Or more likely, what do you think is needed to make sure this will not be inconvenient and slow to work with? Is it enough to have a lines per beat for the whole song or would this better be a per-pattern parameter?
At any zoomlevel, notes and commands will be displayed on the line they occur at.
So:
Assume you have this in 4x zoomed in view: C-4 01 40 8001040F04
D-5 01 30 700105 ------
the zoomed out view should show this: D-5 01 30 7001050F04
The underlines is shown here to more easily separate the columns.
The bold parts will be showed in a different color or another marking to show there are more events within the line that are not shown.
Since D-5 will be the note sounding after the line it makes most sense to show that note with it’s with instrument/vol/pan instead of C-4. The last command 0F04 shows that which event is to be shown will be handled separately in each column.
Also, the delay column should be directly editable, so the above example with delay colum (colored):
I’ll have to think more about this to give you a definitive answer about the rest, but what I can say immediately is that the answer to this is “we need a per row command”, a track command as 0Fxx is.
This is true without any doubt: having a single LPB value is way too limiting.
what I wanted to know is:
if I write this (4x zoom)
C-4 01 40 80 0104 0F04
----------------0108--------
----------------0104--------
----------------0108--------
will the pitch slide value change on a per-line basis?
Do you use speedchanges for other things than grooves?
Please give some examples. Perhaps we should have both tempo change, tempo multiplyer and LPB commands. There’s an important conceptual difference, as LPB will affect the notelengths and the others will affect the tempo. The LPB command would only apply to whole lines, ie placing it with a delay within a line doesn’t make sense.
Yes.
Even if you zoom out again, hiding three of the four commands, all commands will be carried out at the time they are placed. So when fully zoomed out, you will see a single command (possibly in a different color) but the sounding result will be that of all the four commands.
I use both tempo and BPM changes each time I need more resolution: for example when I add a drums fill-in, in which each note have a different volume, most of times.
An example: say I have BPM 125 and speed 6.
If at the end of the pattern I need to put a drum fill-in in which there are triplets, then I set the speed to 2 only in the last part of the pattern, or even for one or two rows only. Obviously, I must add 2 (temporarily) empty rows for each triplet row.
This is exactly the equivalent of a 3x zoom in your new system.
Using the LPB command, I probably should set its value to 18.
Using the delay column, I should put a delay of 2 and a delay of 4 for the second and third note, without changing the speed value.
Actually, LPB seems to be quite useless to me, in the sense that I would probably tend to not use it, preferring the good old “speed”.
Another frequent case of BPM/speed usage is when gradually raising/lowering speed, for example during a piano-only section.
These parts have quite a “free” tempo and have a lot of speed/bpm changes, even one for each row.
I assume you mean “both tempo and speed changes”. When higher resolution is the requirement, the new system will be quite a lot more powerful.
Yes. The only difference being that with a pattern zoom you would temporarily zoom in on the whole pattern, edit, and then perhaps zoom out when editing other places. So with the speed changes you use here you have yourself created a sort of “local zoom”. Looking at it that way, here only some parts are zoomed, but those are zoomed all the time. Would you miss this difference?
Why 18? With speed 6 one beat is 4 lines, with a change to speed 2 one beat is 4*3=12 lines. So LPB=4 equals speed 6 while LPB=12 equals speed 2.
How you think about these equations depend on how you interpret the speed. This is a major confusion for both new (and even experienced) users, and makes it a hell to fit into new features like MIDI import, VST(i) plugin beat- and temposyncing, more advanced edit functions like quantizing etc. This is one of the big reasons I myself wish to get away from the blurry “speed” concept once and for all now that we’re preparing for an engine that are not based on the old ticks.
If you are now refering to the new delay column we’ve been talking about (indeed, there are no other delay colum), then you have missed an important point. This will be a two-digit hex value xx=00-ff, where 00 is no delay and ff is right before the next line. So a delay of 2 will be only a small 2/256th of a line delay. With a LPB of 4 that would be 2/(256*4)=1/512th beat!
Is this because of habit or do you have a reason why you think “speed” is better? I’m asking this because with this new system I’d like to remove the old speed and replace it with the new concept. Having both will just be too messy. To get this new resolution and flexibility I feel it’s better to drop the “ticks” and “speed” that are used today completely.
Tempo (bpm) changes will be the same. Wouldn’t the regular BPM command and a new BPM multiplier command be better to use than speed changes here?
A little offtopic idea: letting these parameters have envelopes on the mastertrack one could make very free tempo much more easily. (yes IT, I know you dislike envelopes ).
I think martinal got this figured out very well.
I think its time to get rid of the old limited system
As it-alien describe his use of speed changes in end of patterns you will do exactly the same by zooming (you change the speed on screen when you zoom in). And you will have the new tempo parameters to tweak as well.
Moving all the tempo to master track makes sense too.
I like this idea more and more. Hitting a key and you have xTimes better resolution would be just amazing
Nothing much new to add from me… just wanna support martinal 100% on this one
Getting rid of the speed parameter and moving to a resolution of 255 “ticks” per “line” is just about the best thing to move the tracker concept forward… Combined with the piano roll and the MIDI file import/export, these things could very well bring Renoise to the professional music market.
Exactly. The fears of It-alien are unfounded.
Making a great break at the end of a pattern with the speed parameter or with a higher resolution is much the same. But one great advantage of the higher resolution is that you need not add lines to the end of pattern to achieve the same beat; and you need not to adjust all the other tracks to the new speed!
E.g: F-06, patternsize 64. you want to make a break:
With setting speed to F03
track 1 base
…
60 d-4
61
62 d-4
63
you add a break… (adding 4 lines + additional notes):
60 d - 4 F-3
61
62
63
64 d - 4
65
66 d - 4
67 d - 4
now you have to assign all other tracks to the new Speed F03 to keep the beat/melodies! Imagine you have 12 tracks, and every track must be edited. Damn much work.
With setting the resolution to “2x”:
track 1 base
…
60 d-4
61
62 d-4
63
you add no lines, just press the button “zoom” (imagine there is one;)
the above lines are now displayed like this (+ a little break at 126,127):
120 d - 4
121
122
123
124 d - 4
125
126 d - 4
127 d - 4
(what is the same break done in 1.)
and you need not edit the other tracks at all, because the pattern-length and speed is the same, all other tracks are still in beat.
I am in complete agreement with martinal, pysj and weetee, the new concept will make renoise much, much more professional and I am convinced most users will support it as well.
A question - what would happen to old songs loaded in from previous versions of Renoise (or xms or mods) that use the speed change and / or delay commands? Would they be converted to equivalents or would Renoise run in some sort of compatibility mode?
Another question - I don’t see the point of a delay column if you are going to allow a note to be placed at any one of 256 ticks within a line anyway… ? Just for convenience / back compatibility?
I think a compatibility mode is out of the question. That will only lead to problems.
Delay commands using ticks can easily be converted to the new delay commands, and speed change commands can be converted to tempo multiplier commands. There might be more than one way to do this, depending on how the speed is interpreted, so perhaps there will be config options for prefered loading behaviour. I haven’t thought a lot about this side of it, since basically the new structure can handle anything the old one could and more.
This will however introduce a possible quantization error in the timing, but if properly done the error should be kept at maximum 1/256th of a line. So there’s a chance that old songs will sound slightly different, but it shouldn’t be much.
So that you can see/set how much the note is delayed in 1x view. And if you record a note to lets say 3/256 part of a line you would have to zoom quite a lot.
Anyways you can hide delay columns as you can with vol/pan.
So basically you’ll be able to do either / or. Either place a note at some 256th of a line (call it a tick) position … or delay it. What if you place a note on a line at, say, tick 100 and use a delay command on that note? Will it be allowed? I think that would be confusing, say you delayed it 20 ticks, it would show up on line tick 100, but would not start playing until tick 120 … it would be kind of weird methinks. Perhaps a delay command should only be allowed on tick 0 of a line?
Or am I seeing this wrong? If you placed a note at tick 0, and delayed it 20 ticks, then zoomed in all the way, would it actually show up on tick 20? Or alternately, if you placed a note at tick 20, then zoomed out all the way, would it show up with a delay command?
I guess my main question is, is the delay command column and placing a note on a tick within a line, two separate ways of viewing a single action? Or is it two different actions completely?
BTW however the details work out I support the idea 100% - I think it would be a good way to go …
You got it.
Is I said. The delay column helps you see where the note is placed.
Point is that you can then see there is a note at position Xticks when you are in 1x view. Delay is just telling you where the note is… just as the line number.
As martinal has suggested: if there is 2 or more notes in same line (1x view) then you will only see the last note in some other color or something (in 1x view).
Just think of the delay column as some sort of linenumbers for the 256 ticks.
When you zoom in, the notes will be placed on the tickline closest to its real position.
exsampel
1x view:
00 c-2 – – 84 ← note delayed 84 ‘ticks’
01
02
4x view:
00 — – – – this tickline has all data from 00-3f ticks (1/4 of 256 hex)
00 — – – – this tickline has all data from 40-7f ticks…
00 c-2 – – 84
00
01
01
01
01
maybe the linenumber could change color and show the ticks when you zoom.
Then only the first tickline has the linenumber… and the rest has its ticknumber
like in 4x view:
00 — – – – <-normal color on line number
40 — – – – <-some other color
80 c-2 – – 84
C0 — – – –
01 — – – – <-new line. normal color
40
80
C0
This is exactly the issue I’m most unsure about. One solution would be to only allow editing the delay value when zoomed all out. Or only allow entering delay values within the delayrange of the current line when zoomed in. Or automatically moving the note to another line when another delay is inserted… One problem I see now is if two notes in the same column is assigned the same delayvalue. I guess we will need some sort of “validate and possibly reject” functionality when entering these delay values. I have to think more about this. If you have more ideas on this issue, bring them on.
The same action, affecting the same parameter. Think of the delay as a sort of “line inside the line”… We probably need to make some clearer terminology here
00 C-3 01 40 80 00 — <== this note is not delayed
40------------------------
80 C-3 01 20 80 15 — <== this note is delayed by 15 tick
C0------------------------
if I write such a thing, I expect the second note to be played after 80+15=95/256th of a line, so I think this is the right way to display delayed notes, or you could prevent people from using note delay column in the zoomed lines, but this quite sucks.
This also rises another question: what if the sum of position+delay is more than FF?
00 C-3 01 40 80 00 — <== this note is not delayed
40------------------------
80 C-3 01 20 80 85 — <== this note is delayed by 85 tick
C0------------------------
after having astonished people on 1997 with a 5’30" single pattern song, I think that the time to create a single row song is coming
).
