A question of speed

Ideas & suggestions
81

Sorry for not reading through this entire thread from the beginning. Here is my opinion. I was an FT2 user and i am very used to the current speed concept. Speaking for me, the handling does not need a change but the timing accuracy (though these aspect may be connected to each other, i guess).

I had a song that i exported to wav, in order to continue work in logic for example. I entered the given BPM from renoise, but the drums where not looping correctly anymore. Same results with my Harddisk-recorder. It has a Bar.Beat.clock display according to a given BPM. For verifiyng if this was due unstable timing, i recorded the song (about 3 minutes) on two different channels. My result was: Renoise has a very tight timing, the two tracks where almost identical. But the given BPM is odd. I even remember some vst plugin displaying something like 119,15 BPM while renoise was at 120BPM.

Thats what i care about, a fix of this would make cooperation with other hard/software easier.

looking forward,

Loolarge :drummer:

P.s. And another fix for the buggy playback in renoise’s midi-slave mode would be great as well :rolleyes:

82

I remember someone wrote in this or another thread that Renoise has correct BPM and Cubase is a bit off. Are you sure logic shows the correct BPM?

83

I’m curious about what’s happening with this idea, now that we’re a few months down the road. Almost every day I find myself wishing for better resolution, and I can’t wait to see this in Renoise.

In particular I wonder whether anyone ever came across a good idea for the groove settings? I sure can’t think of an intuitive way for that to work (I don’t understand what happens to timing at the sub-line level). I doubt I’d use the automated groove unless I understood exactly what it was doing at each tick.

84

With the higher resolution, will the adjustable pattern length feature be kept?

Thanks.

85

Of course.

86

Don’t hold your breath. This is not for 1.3, I can not (and will not) say more.

87

First off I’d like to say that I think the main advantage of this proposed speed paradigm is that it makes several other functions redundant (normal note delay, retrig, tick/step and speed). If it’s implemented well, then it will be the next logical progression. Implemented badly it could be very messy.

With the new finer speed adjustment I think it’d be a logical time to move to a normal BPM measure for tempo.

How about do it like graphics packages do and represent notes visually… Example:

  • All notes have blocks of colour surrounding them

  • Very easy to see how long the note is

  • Short collapsed notes are represented as maybe a pixel line as you zoom in

|C-3|

___

|C-3|
|___|

___

etc…

I think this is the clearest approach. This way you could also click and drag notes.

I think with all this zooming, to save time you would have to be able to set the desired resolution you’re working in. E.g. 64 divisions per note, or even 48, or hell, 51 - it shouldn’t matter, but It’d good to be able to set them if only so you can zoom in maximum and know what resolution you’re working with.

The problem with showing it any other way is that what you will hear will be different from what you are seeing. That is, if the second note in the collapsed group of notes is more prominent, so it is the one which is shown, then you will see that note when the group is collapsed, but you will hear the first note first - this is not as intuitive an approach in my opinion.

Can I suggest another idea?

Have different tracks in different time signatures. This might sound like it’s more complicated, but I don’t think it will add any complexity with the new zoom function. E.g:

  • Track 1 is in 4/4, Track 2 is in 3/4

  • Tracks are shown as (spaced out for the sake of a plain-text example):

C-3— C-3

C-3— ----
------- C-3
C-3— ----

C-3— C-3

C-3— ----
------- C-3

etc…

It would make it really easy to work in different time signatures, and extremely flexible, if all tracks could be time-signature independant. It would muck up BPM though I think. It would make grooves in triplets very easy.

88

i do alot of blending of different time signatures in tracking and i think the current tracker scheme lends itself really well to working in non 4/4. having to specify what time signature a track is in, i think, would create more confusion. if you want a guid for determining where your beats are supposed to go, just change your row highlighting scheme.

89

orpheus, the use of different time signatures for each track to aid with polyrhytms and the likes has been suggested before (I can’t remember exactly what was said, but you should be able to find it with search), and the collapsing zoom stuff has too, in a few threads besides this one if I recall.

I think having the option to change the signature/row highlighting, pattern length (as mentioned by a few here, I think in the discussion about Renoise’s forthcoming arranger) of any given track from the default, which is set elsewhere, would be great.

90

You know, given some thought I actually agree with Johan’s earlier idea about dropping LPB (or speed, or any Second “tempo-modifier”) entirely and only go with BPM.
Why?

Well, I think like this: why, when trying to get away from using a non-musical term like ‘speed’, add another type that might end up just as obsolete? If there is a straight conversion between LPB and speed, as there seems to be (speed 6 = 4 LPB, speed 3 = 8 LPB), why replace one bad thing with another?

Instead, I believe I have a more interesting idea…

Until now, Zoom has (unless I have missed something vital for the whole point of my post) been described as a static GUI effect that let’s an user increase the pattern in and out in real time.

What if you could instead make multiple variable zoom ins on specific parts of patterns? When the track-marker enters one of these zones, it will simply increase its speed to match the zoom-in level. This will act exactly like a LPB-change. Also, it will allow you to clearly see what you have put in your zoomed in zones, at all times, without having to zoom in just to check if maybe there is some data hidden between the lines. (you can always zoom out of the zoomed-in areas anyhow, if you want a better overview of the song as a whole)

I’ll let you digest my idea before coming with additional rants.

Cheers! :)

91

i think that the lpb is a good idea.

on the one hand it’s kind of like a secondary zoom function, but it would also make it easier to do step programming in unusual time signatures as well as providing a way to reconcile the existance of the effect collumn. several track effects (0400, 0e00, 0d00, e0, f0, d0) operate between lines, i know that the delay collumn makes two of those obsolete, but the other two remain useful (so you don’t have to go between the lines when you don’t want to, and doing 256-iteration retriggering would RULE! :yeah: (and you could put a volume slide under it to boot :eek: and that’s really cool.)

i think the tweaked out entries should have a different back color. i also think that a ‘split’ function would be a good idea so that you can have a zoomed in view and a non-zoomed in view simultaneously (if you so desire).

so… have you guys tried it yet? i know that it’s probably nowhere near done and you’re really busy with 1.5 and all… yust wondering :rolleyes:

92

so… have you guys tried it yet?

no.

93

I think you may be missing a central point here. There will be no more “line”
as a time unit or song document part. A line will only be a GUI construct to
show you the song data in a tracker way. The timing of notes and commands
will be stored in beats and fractions of beats. The duration of the lines you
will still see in the patterneditor will depend on the zoomlevel you choose at
any time, and can’t be used as a timing base for any kind of effect. A volume
slide for example, will need to be rethought. Rethinking commands is the main
part we’re not completely done with. And the main part that will introduce
quite a bit of compatibility problems.

94

Don’t forget that many offsets will change when you zoom in and out… Read around but I couldn’t see it anywhere.

As an example, a delay of 0x80 would be 0x01 at 128x zoom, and nothing at all at 256x zoom. If you think from max zoom-in, it makes sense to only have delay values as a kind of “reminder” that the value isn’t right at the line people see it.

Also, why not allow people to zoom out more than to x1 ? :)

95

The delaycolumn should have meaning relative to the current zoom level.
The GUI will handle converting between the internal time format with very
hight resolution, and the delaycolumn values between 0 and 255.

So the delaycolumn values will represent a length of 1/256 of one line
at the current zoomlevel.

We can then even skip the hex numbers and use decimal numbers, and
use any number of digits for the delaycolumn. It could be just a matter of
choice, changeable at any time, since the real time format is hidden.

96

Not sure if I’m getting this right but…

That would mean that if you zoomed in to 256x, you’d actually have a resolution of 65536.

Wouldn’t the delay column rather represent a value of 1 / (maxZoom / currentZoom) and be variable in the sense that the more you zoom in on a specific note, the less the delay value you see will become, until it is 0 (or N/A) at max zoom?

In the same way, the delay-value would actually function if you zoomed OUT to 0.5x or so:

00 — —
01 C-4 —
02 — —
03 D-4 —
04 — —

at zoom 1x becomes:

00 C-4 x80
01 D-4 x80

at zoom 0.5x

To continue my previous post about Zoom in favour of LPB, you could present two types of zoom; one level that’s applied to everything, in addition to the ones applied to specific ranges. The good thing about this would be that you could zoom in and out while the song was playing, while the differently zoomed-in parts keep their relative size to each other.

97

i understand that lpb wouldn’t be something that affects speed or time, but it would be useful in step-programming odd-time rythm. and i don’t think i’m missing the point.

  
1x Zoom: LPB:1  
  
01: c-4 01 ..  
02: e-4 01 ..  
03: b-4 01 ..

suppose i want to make the rhythm 3/4 by putting a ride count in three on each beat.

  
1x Zoom: LPB:3  
  
01: c-4 01 .. c-4 02  
02: . . . .. .. c-4 02  
03: . . . .. .. c-4 02  
04: e-4 01 .. c-4 02  
05: . . . .. .. c-4 02  
06: . . . .. .. c-4 02  
07: b-4 01 .. c-4 02  
08: . . . .. .. c-4 02  
09: . . . .. .. c-4 02

this way renoise can crunch the numbers on adjusting line density to fill a given time signature for you. if you got rid of the LPB you’d have to calculate out the positions based on 256/3 wouldn’t you?

98

Hmm, I think I see what you’re saying.

I wrote a lengthy reply and then gave it some more thought, erased what I had written, and am now thinking again.

So… will pattern-lengths be based on LPB or…?

99

So… will pattern-lengths be based on LPB or…?

There will be no such thing as lines as a time unit.

The time unit is beats, whole beats or fractions thereof.

To write triplets and such, you would zoom in to for example
6 LPB in the GUI (this does in no way change the song), and
enter notes at those lines. Internally, the timing will be stored
in fractions of beats, so when you later zoom to for example
4 LPB, the same notes will be shown with delays.

But what to measure patternlengths in is one of the little discussed details.
Either it is measured in whole beats, or it can be measured in fractional beats
as well, in which case it depends on the resolution.

100

This is wrong. The patternzooming is the LPB.