It’s been a while since I messed with Renoise. I downloaded it back in December, but wasn’t really able to do anything productive with it. There were a number of things related to TIME that didn’t make sense to me.
At that time I wrote the following to renoise support:
I received the following reply:
Today I just downloaded 1.8, and it seems that the metronome beats at the same speed for Speed=6 and Speed=3, but the metronome slows down at Speed = 12. Why is that? BPM is still set to 100.
I also found the whole ticks/speed thing to be confusing. I wrote the following at that time:
eduard [taktik] told me to post this to the forum in order to get other users opinion on this request. I think the veteran users are probably accustom to the present design, but wanted to make this point: the present design doesn’t seem natural for those used to thinking in musical time, and this makes it confusing to new users. I think we’d all like Renoise to reach a larger market, as that would increase revenue and incentive to improve it’s performance and features, etc. So, do you think the above request would lower the learning curve?
But yeah, I’m totally for ditching the “speed” and tick resolution thing and for moving towards a more common approach, similar to that in other music programs.
I’d easily live with some backwards incompatibility, too.
I think a non tracker like time base would definetely be better, but that is only because i’ve used tempos 6,3, and 1+2 (on every other line) whole time… -
Not actually sure why anyone would use any other tempo but there must be some out there who still do. (?)
Actually i think it would be also really useful for the developers to add a poll on how many users actually use any other speeds than 1+2, 3, 6 or 12.
I also think that the overall resolution of renoise would not need to be any bigger than that of for example using speed 6 and bpm of 999.
Just thinking of this from a point of view which would not need much changes to the renoise’s core itself and how the songs made already would be absolutely compatible with more resolution. If the max bpm was dropped to 333 and it was made possible to zoom 2 times into the pattern the we would have the same resolution as using the bpm of 999. And if we added some kind of zooming for the Delay values ← meaning that we added a view that could show the delay values as a normal renoise pattern… That would sort of decode the D1,D2,D3,D4, etc into a tick value if zoomed and the other way round too… You could add a note when you had zoomed in and it would add a D value behind the note that would be shown on the line if the “zoom” was back to “normal”.
So if both the bpm was dropped and the “grid or viewing” for D values was added both as part of zooming, then we would have a really sharp resolution…
But… just brainstorming… that resolution might still not satisfy everyone because for example a groove of 15% could still not be produced it would be something like 13% and 14% and 16% that you could make but still not 15…
I think a non tracker like time base would definetely be better, but that is only because i’ve used tempos 6,3, and 1+2 (on every other line) whole time… -
Not actually sure why anyone would use any other tempo but there must be some out there who still do. (?)
Actually i think it would be also really useful for the developers to add a poll on how many users actually use any other bpm than 1+2, 3, 6 or 12.
I also think that the overall resolution of renoise would not need to be any bigger than that of for example using speed 6 and bpm of 999.
Just thinking of this from a point of view which would not need much changes to the renoise’s core itself and how the songs made already would be absolutely compatible with more resolution. If the max bpm was dropped to 333 and it was made possible to zoom 2 times into the pattern the we would have the same resolution as using the bpm of 999. And if we added some kind of zooming for the Delay values <- meaning that we added a view that could show the delay values as a normal renoise pattern… That would sort of decode the D1,D2,D3,D4, etc into a tick value if zoomed and the other way round too… You could add a note when you had zoomed in and it would add a D value behind the note that would be shown on the line if the “zoom” was back to “normal”.
So if both the bpm was dropped and the “grid or viewing” for D values was added both as part of zooming, then we would have a really sharp resolution…
But… just brainstorming… that resolution might still not satisfy everyone because for example a groove of 15% could still not be produced it would be something like 13% and 14% and 16% that you could make but still not 15… [/quote]
Hi O29,
Unfortunately I can’t follow much of what you write (I’m too new).
When you write “i’ve used tempos 6,3, and 1+2 (on every other line) whole time…” do you mean SPEED settings of 6 or 3? Not sure what 1+2 means?
And when you write: “how many users actually use any other bpm than 1+2, 3, 6 or 12”
Do you mean SPEED in place of BPM? I’ve never heard of a BPM of 1+2.
For me changing the RESOLUTION changes the number of steps per unit of time. Therefore, the BPM or beats per minute, should not change at higher or lower resolution. You’re not changing the duration of a minute, so BPM should count the same no matter the resolution of your grid.
delay values and stuff should should either be timed in real-time (seconds as in .250 sec or whatever) or music time (BPM ie, 1/4, 1/8D or whatever)
But… just brainstorming… that resolution might still not satisfy everyone because for example a groove of 15% could still not be produced it would be something like 13% and 14% and 16% that you could make but still not 15… [/quote]
For groove, couldn’t you just use some command to SHIFT the sample forward or backwards in time by a fraction of your grid resolution?
for examle in the sampler/beatbox GURU you can use a feature called SHIFT GRAPHS to shift play position
of a ‘Pad’ forwards or backwards between adjacent steps. Thus the Shift Graph represents timing deviations, smaller than a step, from hard step-divisions.
I don’t know Renoise syntax yet, so I’m using pseudo-code:
if you have some beat
1:B
2:
3:S
4:
5:B
6:
7:S
8:
couldn’t you add groove with some command that shift the ‘hit’ forward or backwards by a fraction of a step (shown here as a %)
1:B
2:
3:S(forward 13%)
4:
5:B(backward 9%)
6:
7:S(forward15%)
8:
to inject a humanized ‘swing’ effect into your Patterns?
renoise would have to be smart enough to “look ahead” in order to anticipate those shifts backwards in time, but would this solve the problem?
forward 100% would we the same as placing the sample in the subsequent step/row.</0x0000562855c5ff20>
yeah this is actually the same thing i was talking about earlier what i meant by the delay values. Only now it cannot produce a groove of 15%… but yes that would be cool … check this out →
yeah this is actually the same thing i was talking about earlier what i meant by the delay values. Only now it cannot produce a groove of 15%… but yes that would be cool
[/quote]
Oh, OK, so the solution could be to just make delay a percentage of a ‘step’. What do delay values represent now? ticks?</0x0000562854aaac08></0x0000562854aaac08>
The delay values represent something like a fraction of a tick… For this timebase i think there is no term at the moment (please someone correct me if i’m wrong). There are 6 fractions of a tick for the speed 6… 3 fractions of a tick for speed 3 and 12 fractions of a tick for speed 12 for example. Then on speed 6 you can have delay values from D1 to D6 available for use. Don’t really know what’s behind this but that’s just “the way it has allways been”
The delay values represent something like a fraction of a tick… For this timebase i think there is no term at the moment (please someone correct me if i’m wrong). There are 6 fractions of a tick for the speed 6… 3 fractions of a tick for speed 3 and 12 fractions of a tick for speed 12 for example. Then on speed 6 you can have delay values from D1 to D6 available for use. Don’t really know what’s behind this but that’s just “the way it has allways been” [/quote]
I think delay is in ticks. says so in the manual. you might be confusing ticks and rows i.e. rows are composed of ticks. I think ticks are the lowest unit of measure. But I could be wrong!</0x0000562852d00400>
Ticks is the lowest resolution. And the speed sets how many ticks (resolution) per row there are.
It ought to acctually be called resolution instead.
The BPM is acctually how fast you play the ticks.
So the delay value are in ticks.
And I acctually think it could be better if it was in % instead, but that would require other changes.
Well there is one problem with zoomin in, and that it that when you zoomed out, things would look like the shared the same row. When you are not able to zoom out it is not possible to put notes in the same row.
The solution to put notes inbetween the rows of two notes is to put them in another note column and give them a delay value.
You can also create a groove by using delay value.
Something still just seems very problematic and counter-intuitive about all this. When I look at a timeline-based app, such as Sonar, it’s just so obviouis how everthing works. I’m not imply at all that this app isn’t useful, I’m just interested in taking a close look, as a new user, at my experience learning the product, in order to see if any ideas arise that might make it easier for future learners.
So far I suggest that Speed should be Resolution. And maybe the value should correspond to the duration of a step in musical time. For example, if Resolution is set to 1, then one step in the sequencer corresponds to one beat–that is, a whole note. Resolution=1/4 gives you quarter notes (one step is a quarter of a beat, thus you get 4 steps per beat). Likewise 1/8 gives you eighth notes, etc.
Now we have several choice: we could set a limit on the number of beats per measure, such as 4 or 8 and then create higher resolutions by allowing BPM changes i.e. double BPM to create more resolution. But I think the inconsistency is a little undesirable. Setting higher resolutions adds a tons of rows, but I’m not really sure if this is a problem or not. If it is, maybe one solution is to allow variable resolution throughout a song. i.e. you can have 1/32 note capable measure when you need them, and such 1/4 note capable measures when that’s all you need. What do you guys think of that?
Also, I suggest fixing the metronome because it should count beats per measure regardless of the speed setting. This was fixed in 1.8 for speed 3 (the metronome used to count faster). But when Speed = 12 the metronome now counts half as fast (50 BPM). I think I understand the reason–because the metronome is counting ticks, and the ticks are coming too slow. So I think you have to “unbundle” the metronome from the ticks and run it on it’s own clock or something. If the metronome doesn’t count BPM correctly it’s better to just remove it, as leaving it broken is a source of confusion.
Question: why is there no musical ruler (or is there one and I just haven’t found it)? For example, why not label the rows musically? You can still leave in the row numbers, but maybe add the beat information:
“If it is, maybe one solution is to allow variable resolution throughout a song. i.e. you can have 1/32 note capable measure when you need them, and such 1/4 note capable measures when that’s all you need. What do you guys think of that?”
You can.
So if you want higher resolution than say 6 you can double the bpm and set the speed to 12 with pattern commands.
Unfortunatly it only supports a bpm up to 255 by writing FF.
So the maximum Bpm you can double from 6 to 12 is 126
Hi yeah i totally mixed lines and ticks earlier thanks maxhodges and splajn for clarification…
Just to clarify my own earlier post a little more, if the amount a note is delayed in “ticks” would be displayed as a D -command, then that would remove the problem of notes appearing to be on the same row.
So if there was somekind of converter of the displayed pattern data between the zoomable views then maybe that would do as a simple enhancement to the resolution without having to change the renoises core at all.
This way we could still edit the tracks as before and also the delays could be displayed also by ticks if zooming in… If the Renoises resolution was enhanced, then maybe the D -command could have 2 digits behind it.
