The current (oldschool tracker) model for speed and tempo handling seems bit outdated for me. What about changing it to more simpler and actually musically more effective one:
Tempo (for example 120bpm)
Rows per beat (For example default 4)
So when running song at 120/4 renoise plays 4 rows in one beat (like current speed 6), setting this to 8 will play 8 rows per beat (like now with speed 3).
You don’t have to ditch the Speed parameter, as some people really rely on it, but make it hidden somewhere, and treat the RPB parameter as a multiplier for tempo.
For example:
120bpm * 4rpb = 120 current
120bpm * 2rpb = 60 current
120bpm * 8rpb = 240 current
It would make it much easier to use pattern commands to set tempo aswell. And you shouldn’t have to use nonsensial bpms like 999.
I am sure this has been discussed here before, but I was too lazy to search the boards.
Your proposal has more deep implications that it seems, I guess. What about commands that depends on speed? They will have to be deprecated or redefined. And a lot more things that I don’t even dare to think
As said, it doesn’t take away Speed parameter. Atleast for now.
The Speed parameter is put somewhere in advanced settings, and is assuming 6 by default.
So if you have:
120bpm, 4rpb it behaves like: 120bpm speed 6.
But if you have:
120bpm, 8rpb it behaves like: 240bpm, speed 6.
For example.
Of course it brings other changes with it. But I am not posting this as “Hey, make this or I’ll cry!!111”. I am posting this as: “Hey, I have an idea how to make things simpler to use, let’s discuss”
Wouldn’t more lpb require increased tick resolution, which is what multiplying bpm does after all? Would speed or bpm change accoring to lpb? Isn’t this just adding modifiable lpb and replacing lpb and speed with each other?
This would be practically backwards compatible more noobs into renoise trick. Would be some hassle for experienced users to get into new ways replacing ancient traditions. For usability not really needed as such, but neither have I nothing against definable lpb.
Sounds like a great idea… reversing LPB and speed making LPB configurable…
Or better:both…
I think i’m gonna find some more blackmail material against Taktik for this idea.
We’ll see how fast we can get this into Renoise.
I think the reason behind not letting user adjust all of play speed related settings is to avoid confusion arisen from the fact they all interact with each other. Change one and others change along. If speed and lpb would be reversed how would pattern view react to lpb change in pattern command column? Visual speed of playing a pattern would change if pattern would be stretched, and pattern length too, which would mean pattern length should be also measured in beats rather than lines. If not then pattern length x would not be static number of beats, which would also cause some confusion.
It seems that current speed concept is so tied to the pattern structure that major rethought would be needed for changes to be reasonable. After all speed and lpb are just different sides of coin, thus no real benefit in functionality could be achieved. I very well see why the problems of reconstructing the concept could be too much for making the change, even if it would make it easier for some people not familiar with tick sequencing to get into Renoise.
Well, it surely does have some benefits for old musicians aswell:
You can have “normal” BPM’s (In reality, 800bpm track would be practically white noise, but people use it to get more resolution).
You can easily change speed: Patter command to change from 08 to 04 sounds more logical, and you can actually change them using pattern commands while at tempo 800 you can’t go on tempo 400 with pattern commands as both are out of the range.
Your carefully programmed tick based effects won’t get effected by 2x slower tempo change.
I would love to have a LPB. Can’t understand why that would bother anyone.
It would just define the screen resolution (how fast the pattern will scroll). It would not change number of lines or change tick resolution. Much easier to understand I think.
Yes yes, but
120bpm, 8rpb it behaves like: 240bpm, speed 6 is practically 12bpm speed 3. You see speed is there to adjust line resolution. To achieve results we dont neccessarily need adjustable lpb but an increased tick resolution which in turn would bring us more control over lpb. In Renoise a beat is certain number of ticks, so when lpb is changed, the speed is changed and the very same limitations apply than when changing the speed. So no, lpb adjustable does not bring any improvement unless tick resolution is improved. If or not that could be made non-static is not in my knowledge.
Participate in question of speed thread to see the status of thinking of getting more speed.
Maybe I’m missing something, but… Why exactly would we need a LPB setting?
To me, it only seems to bring more confusion. It’s already bad enough that we have speed, now you want to add another one of these and still have speed hidden somewhere?
A simple zoom option seems to do what LPB does and it’s easier to understand and use, IMO.
Heh, maybe we’re talking about the same thing, just different name/implementation… Anyway, I vote for a zoom toggle near the pattern editor. No LPB/RPB, just a zoom toggle with no acronyms.
LPB would improve resolution if speed becomes depending on it.
You could then raise the speed (having more ticks to spend on the same row) but your pattern flow will not increase in scrollspeed.
Well, the presumption of an improved (sub-tick) resolution was the very basis of the whole zoom idea that I mentioned.
So… if you zoomed in hard enough you could see thousands of new (previously hidden) lines inbetween, while still maintaining the, for example, 64lines pattern lenght. Those inbetween lines could then be labeled with decimals.
