color coding the content blocks seems like a vital part of implementing zoom like that. that way you get some idea of what the content is, even if you can’t read the code. i guess you’d want the color to correspond to the instrument, though being coded to the note value might also be helpful.
As someone who is fairly new to Trackers I’m just trying to get my head around the concept of the “Speed” setting, so I’m really glad I found this thread.
Coming from a linear sequencer + notation background I don’t see any problem with the current resolution of Renoise, but the “Speed” concept does my head in. I have always been fairly average at maths, so reading this thread took a lot of concentration! 
Am I right that, at the standard setting of Speed=6 LPB=4, one line is the equivalent of a Hemidemisemiquaver (1/64th note)?
What I’d like to do is create a table similar to this one that I created for Reaper:
http://www.cockos.com/wiki/images/9/99/Notation_revised.png
so that new Renoise users from a similar background find it easier to relate to the Pattern.
Can someone tell me what the current maximum resolution (i.e. one 6th of one line) equates to in musical notation?
Cheers,
Malcolm.
the more i use renoise the more im sure that the main thing i want to be changed is the whole way speed/bpm/resolution works.
Id find it so useful to double the working resolution of one track without having to double bpm and expand another. Drum effects, fine timing editing etc etc would all work better with either this or a zoom function.
I love renoise but i dont like having to use workarounds as the rule rather than the exception. Not trying to slag off the tracker heritage but this timing system is not an improvement on the much more establised tweaked and bug fixed system of music theory thats out there.
Oh god that sounded arsey… didnt mean it as such…
I know exactly how you feel. It’s also annoying when you want to sync something to the host tempo.
I don’t mean to sound harsh either, but I’d rather see if the ‘Speed’ was ditched, buried and forgotten altogether. I can only imagine the confusion that it creates to new users, or those new to trackers. If it’s not possible to remove it altogether (for backwards compatibility) at least hide it somewhere. 
Hello I know just what you are talking about… =)
Here is a copy of a posting I made about an idea few days ago…
------------->
Hi,
Just because it seems like it’s going to be a bit longer since renoise can be used in a tighter resolution… perhaps we could have a split bpm box as a substitute?
Most of us use eiher duplicated tempos or BPM’s multiplied by four. So there would not be need for more than a division of 2 or 4 in that box.
I personally find it a bit difficult to use delays or LFO’s in the plug-ins with bpms such as 620 etc. That’s usually because many presets for synths have LFO’s that are tempo synced or delays or other settings that get screwed totally… smile.gif
peace…
<-------------
I’d really like to see some kind of solution to this =)
But… loving renoise either way… hope to see this tweaked somewhen…
Re reading through this thread and thinking about things…
I think id most like to see “speed” redefined as ticks per line and then another box next to bpms which could multiply the currently shown bpm value (x 2 x 3 x 4) etc without it showing differently or communicating with vsts etc differently. Idealy this would auto expand info in patterns and the length of the pattern itself.
Perhaps there could also be different editstep values for each track? Then we’d be working in 8ths, 16ths, 32nds or whatever depending on the track we were in (might be good if it moved down and up to the editstep value rather than just down)
Then some kind of multi level zoom out/in feature to hide lines on all tracks and get an overview of a pattern might be very useful too.
This is pretty neat, but I can’t help but think that there is a simpler solution than adding a second “level” of lines.
If you need more resolution there are very reliable traditional strategies already:
- lower the speed & up the BPM (cons: long pattern)
- for intermittent high-res usage, automate bpm/speed in the fx column. (cons: gross. and ruins the line count - for example it’s common that beat 4 is at line 12, but this would mean it’s at line 16 or other)
IMO, there is no current issue with resolution - the issue is in displaying patterns so that traditional “workaround” solutions are practical solutions.
In other words, I think it’s too complex to add in the concept of “sub-lines”. To me, they are all just lines. No need to create a 2nd level.
I have 2 main suggestions:
-
Allow zooming OUT (not in). If you want high res, then lower speed / up BPM. Now if you don’t want to see so many lines, zoom out, and you will see a view where multiple lines are aggregated into 1.
-
Allow more flexible line highlighting, such as different highlight schemes for different patterns, multiple colors to choose from, and a more flexible highlight editor. This alone could really go a long way in navigating around long patterns, and, for my personal use, would eliminate problems in resolution because I can navigate just fine in a large pattern.
Now, the next issue is that even if you are in some zoomed-out view, you will still see pattern lines which skip, like
001
008
016
024
032
I don’t see that as a problem though - this is way easier to get accustomed to than a zoomed-in view.
Another possibility related to highlighting, which addresses the “automation of speed/bpm” issues – How about the ability to set highlighting by number of ticks or beats, not by line. For example, “highlight every 4 beats in blue”. Now when you automate speed, it will change how the pattern is highlighted, so everything is still beat-aligned.
Also related – how about a new effect number, or even a whole new track, to control highlighting, event aggregation, “zoom” of display, etc.
All this goes towards the same end: make it simpler to do high-res tracking.
Since I’ve been lurking these forums for a while and just started posting last week, I thought this would be a good time to cast my opinion on this topic.
I’ve always thought that the term “speed” was misleading and confusing, and that it really represents a BPM multiplier (as pointed in some of the posts here). And for the sake of backwards compatibility, it could be kept and renamed as such. I also really like the idea of a visual zoom in for sub-line timing. This would hopefully make things like quintuplets much much easier – right now, *-tuplets are hard to pull off without “tricks”.
As for the “zoom in” vs. “zoom out” issue, I don’t think it would make the biggest difference to me. As long as there is a visual change in resolution to make micro/macro timing easier, I’m happy.
i find speed@BPM intuitive probably b/c i hammered it into my brain and tried to have a very familiar grasp on how older trackers used those values (iirc ft2 online help has the equation in it?).
however, if things don’t really work like that anymore and there is good reason from a codebase and user standpoint (it seems in this case all three are true), i agree about it being the right move to move to some new model.
having said all that, i do really enjoy the correlation involving speed and rows as shown in the vertical column lines in the envelope editors.
im also new to renoise,and i also have problems "getting"how excactly the speed/tempo thing works
i normally make music at 250bpm(how do i set it to that in renoise??)
depends on how you want to fill the pattern, the amount of resolution you’d like to create your musax…
250 bpm, speed 6 = 250 bpm
250 bpm, speed 3 = also 250 bpm, but renoise will scroll much faster through the patterns giving you the opportunity to create much faster drum rolls for example.
basically there are a lot of different settings that’ll come down to 250 bpm, but you’d have to place your samples accordingly.
Whatever bpm/speed combo you choose, you can check the ‘real tempo’ in the song settings tab…if I’m not making sense it is the sensemillia.
thanks that makes sense,im a little closer to understanding it now
BUMP
This is obnoxious and unnecessary.
Show some respect, restraint, and patience.
If you have nothing new to contribute, then the equivalent of some bratty kid in the back-seat going “Are we there yet?” is unwelcome.
Sounds good but I think the speed indicator shouldn’t be linked to tick resolution. There should a seperate setting controllable with effect column commands that should set the value of how many ticks per line. Then you could have basically any speed and resolution without having to implement a zoom function.
Er even better. Dis the Tick system totally, increqase the resolution overall whatever speed u were using. and rewrite effect column commands and offsets to be based on Percentage of a line instead of tick based. For example:
0D00 - ODFF Delay note 0-100% of line
D0 - DF (in volume or pan column) more rough but works the same based on percentage of a line.
F0 - F1 (in volume or pan column) cut note after 0-100% of the line have been played.
FF00 - FFFF - stop all notes (note off) in track att 0-100% of line.
That would be enough.
Care to explain how?
Awwww … Well anyways… Why Having tick resolution linked to speed? why not set a specific number of ticks per line regerdless of what speed you’re using. 64, 128, or 256? Anything would be better than 3 if you wanted to use speed setting 3.
Here you can clearly here the distsortion of the sound using few ticks per line when pitchbending with and envelope in instument editor for instance.
Pitchbend using speed 24 - 500 Bpm
Pitchbend using speed 06 - 125 Bpm
How much would increasing the ticks per line impact the performace? Is the Old speed/tick link just a bad decission from the past because performance issues or, does it make any sense to a programmer, cuz I can’t really see what’s the point of keeping that old system.
Well. No decision is made yet for how this will be in the future.
A LinePerBeat (LPB) option has been discussed quite much.
Even a TPL (Tick per Line). Either a fixed value or user defined has been suggested.
For the speed, thats a difficult matter. For some ppl the whole point IS to have speed linked to tick resolution (change the behavior of instrument envelopes and all sort of other things).
There is also a backward compatibility to take into account here.
And finally how much work it would be to change the entire system, and how it will be performance wise.
There can be a hell of a lot of work to change something as ‘simple’ as this.
The goal is however to somehow somewhen increase the overall resolution (both for notes and pattern commands) so ppl are not forced to use insane scrollspeeds. If this is done by pattern zooming, a new graphical editor, introducing LPB/TPL , note delay columns or other ways is yet to be decided.
In my opinion…
… the whole Speed-concept is counter-intuitive. You want the BPM of the song to decide its speed, not a combination of BPM and an auxiliary unit.
So my vote goes to an arbitrary Resolution variable, that either expand or condense the visible note scope. For an example, consider the following scenario: You use speed 6 and want two notes to follow another. The first note should start at the beginning of the beat, and the second note should follow after 1/32:th, replacing the first note.
This would look somewhat like this:
00| C-4 00 F3 0000 | D-4 00 D3 0000
01| --- .. 0000 | --- .. 0000
In Speed 3 however, the two notes would simply follow each other. Some confusion arise as, while the metronome ticks on at the same pace in Speed 6 and Speed 3, it is faster than both at Speed 4 and 5. Likewise, even though the metronome hints that Speed 3 is just a higher resolution of Speed 6, the pattern line numbers remain the same (and highlighted the same as well.)
Introducting Resolution, at Resolution 1 you would basically have a blazingly fast scrolling pattern (visually) while still retaining the same speed. Raising and lowering the resolution condense respectively expand the visible note field, giving the impression that the user is zooming into or out of the pattern.
This approach would call for some changes to both pattern commands and visual representation of pattern data. First of all the note delay, note-cut and note-retrigger commands would be removed as they no longer serve a purpose; if you want to delay a note slightly you zoom into the pattern and set it where it should be - likewise for note-off commands. Graphically the row-column in the left end of the pattern view would emphasize on the resolution, showing actual line number in bold and fractions in a smaller font, possibly indented:
Resolution 7
00:00 | C-4 00 .. ----
:40 |
:80 |
:C0 |
01:00 | D-4 00 .. ----
:40 |
:80 |
:C0 |
02:00 | E-4 00 .. ----
:40 |
:80 |
:C0 |
...
Resolution 8
00:00 | C-4 00 .. ----
:80 |
01:00 | D-4 00 .. ----
:80 |
02:00 | E-4 00 .. ----
:80 |
...
Some problems that might arise with this approach is the exponential nature of Resolution: at Res 5 the pattern view starts to look ridiculously filled with fractions. Likewise, at lower resolutions (a low resolution is 8, a high 3) note data will be hidden from view. Colour coding can help the user see that there is more data “in the folds”, but it may not feel like a practical solution…
I’m sure this has been suggested before, I’m just giving you my take on the issue. 