Global Groove - Documentation / How does it work?

Help, Support & Bugs
1

In a final attempt to understand the quite controversial global groove function of Renoise, I aimed to recreate different global groove percentages using only the delay column. After trying out different things and consulting the documentation several times, I came to the conclusion that several things are not right.

The documentation says that when having a LBP setting of 4, where each line represents a 16th note, then the groove (when all sliders are set to the same values) will shift line 1 and 3 forward in time (they will be triggered later) while leaving lines 0 and 2 untouched. If we ignore for a moment that the sentence “Note that the numbers 0&1, 1&2, 2&3, 3&4 only apply to line numbers when using a Lines Per Beat Setting of 4” is incorrect and should rather read “Note that the sliders 0&1, 1&2, 2&3, 3&4 affect a delay of lines 1, 3, 5 and 7, respectively, when using a Lines Per Beat Setting of 4”, then everything is working as expected so far.

To figure out the correct delay to use in the delay column I did the following: I created a pattern where a hihat is played on each row. I activated the global groove. I then rendered the first two rows (0 and 1). I hence expect the second row to be delayed according to the global groove settings. Looking at the rendered part in the sample editor, I now deleted the first half of the sample (from length 0 to length 80) in order to only see what happens to the delayed line.

I first did this procedure with the global groove set to 100%. According to the documentation “Technically speaking, a 100% groove would mean that the second note is triggered together with the third”. Hence, in the sample editor, I should see complete silence now since I only rendered up to, but not including the third note. However, here is what I get:

The sample is delayed by an amount of something between AA and AB (where ff would actually be 100% as described in the documentation).

Next, I tried with a global groove setting of 50%, which is arguably more musically useful. Here is what I get:

The sample is delayed by an amount of something between 55 and 56. While this is clearly 50% of my first measure, it should be 80 according to the documentation.

The numbers 55 and AA should look familiar to us. They represent exact triplets with a LBP of 4. However, the global groove does not accurately hit these exact triplets.

[b]To sum up, we learned 3 things:

The global groove, while apparently trying to operate on triples, is not accurate

[/b]

1 Like
2

Uhm…whoever changed the title of this topic: If you have to change it, could you at least change it in a way that leaves the statement correct? Thanks. To be more precise, the “or” should be a “and”.

Also, I am surprised that there is so little (read: none) interest in this topic…

3

This is interesting. And the more i think about it i realize i dont like the groove/shuffle thing i Renoise. I wish it was possible to put track swing/groove/shuffle with the use of midi files or something similar. This is a bit of topic but seriously its a really important topic and makes a big difference in the “feeling” of the music.

Thanks fladd for bringing this up!!

4

In general, the current groove system is obviously a bit strange, so we definitely want to improve this and implement a new system at some point.

Anyway… The groove timings in the documentation are simply incorrect. This of course needs to be fixed.

Right now, 100% groove does not mean 100% note delay, but rather it equates to 2/3 of a pattern line — ie. a delay column value of AA, as you’ve already discovered.

So assuming the default 4 LPB (one 16th note per pattern line) and a groove setting of 100%, then:

  • Pattern line 0 will be extended by 2/3 of a line.
  • Pattern line 1 will be shortened to 1/3 of a line, and also delayed in time by 2/3 of a line.

I’ve quickly put together this simple tool which hopefully helps to visualize how the pattern lines are affected by the groove settings, and what each groove value equates to in terms of note delay column values.

4997 org.illformed.GrooveCalculator.xrnx

4996 org.illformed.GrooveCalculator.gif

2 Likes
5

thanks, this has always confused me somewhat, so i just didnt bother with the groove setting …

6

In general, the current groove system is obviously a bit strange, so we definitely want to improve this and implement a new system at some point.

Anyway… The groove timings in the documentation are simply incorrect. This of course needs to be fixed.

Right now, 100% groove does not mean 100% note delay, but rather it equates to 2/3 of a pattern line — ie. a delay column value of AA, as you’ve already discovered.

So assuming the default 4 LPB (one 16th note per pattern line) and a groove setting of 100%, then:

  • Pattern line 0 will be extended by 2/3 of a line.
  • Pattern line 1 will be shortened to 1/3 of a line, and also delayed in time by 2/3 of a line.

I’ve quickly put together this simple tool which hopefully helps to visualize how the pattern lines are affected by the groove settings, and what each groove value equates to in terms of note delay column values.

org.illformed.GrooveCalculator.gif

Thanks for confirming the documentation bug and thanks for the tool, it makes things very clear.

However, I would like to bring attention again to my point 3: The values are still a bit off AA, which means the global groove is inaccurate (albeit only a bit).

7

Thanks for pointing this out. I didn’t originally write this part of the manual, but I’ll test how it actually works and rewrite it to be accurate.

8

Me neither, but i did put it there. It was a direct copy and paste part from one of dBlue’s replies.
But a lot has changed meanwhile also to the timing model, it could be that the groove routines were never properly adjusted to the new sample precise timing schedules that got in since 1.8 or 1.9?
Would also mean that the French explanation should have to be adjusted as well… (It seems updated to represent 3.0 as well very nice!)

9

The song groove itself is sample accurate. You can quite easily test this by rendering some 16th notes with 100% groove, and then measuring the exact number of samples that each alternating 16th note has been delayed by.

The issue with the note delay column is simply a rounding error. It’s obviously an integer with only 256 discrete values, so it cannot represent fractions such as 1/3 or 2/3 with total accuracy. For example, 2/3 of 256 is 170.666 recurring, so if you want to achieve a note delay value of 2/3, then you must either round down to 170 (0xAA), or round up to 171 (0xAB).

The bottom line here is that the groove settings were around long before we ever had the note delay column. The groove values themselves were never intended to correspond perfectly to exact note delay column values, and vice versa.

Aside from the academic argument, I wouldn’t worry too much about the effect of this rounding error on your actual music. At a typical tempo of 120 BPM and 4 LPB, the difference between a note delay of 0xAA and 0xAB (ie. the duration of 1/256th of a pattern line) is a mere 0.488 milliseconds. I think we can safely consider this difference to be completely insignificant from a musical groove point of view, can’t we? I defy anyone to actually be able to hear that difference in a blind test anyway :]

1 Like
10

Thats like shouting “Attica”

11

Was pointed here by taktik.

Really useful thread for my groove tool thanks!

Also thanks to dblue for the calculator tool!

12

So, just to make sure that I really get it:

The formula to convert from a more traditional swing value (the way most hardware/software does; 50% = no swing, 66% = perfect triplet swing) to Renoise would be

y = 3 * x - 150

right?

And that holds for the global groove setting (where all 4 sliders have to be set to the resulting value) as well as for the shuffle setting in phrases, no matter what the LPB setting is. Correct?

13

Can`t remember off the top of my head and maybe the accuracy could be improved upon…, but I did a calculation function on my Groove control tool which gives:

Slider % vs. note delay vs. Drum machine %

The values are all displayed on the GUI:

https://www.renoise.com/tools/groove-control

Groove%20Tool%20large_0.png

14

Can`t remember off the top of my head and maybe the accuracy could be improved upon…, but I did a calculation function on my Groove control tool which gives:

Slider % vs. note delay vs. Drum machine %

The values are all displayed on the GUI:

https://www.renoise.com/tools/groove-control

Groove%20Tool%20large_0.png

Mmh, interesting. What exact formula did you use? According to my calculations, a Renoise groove value of 23 should result in 57.6 in a more standard (drum machine) swing notion.

15

Here`s the code with notations, like I say, may not be fully precise…fortunately I seem to have made a lot of notes.

First function is note delay, second is for drum machine.

--------------------------------------------------------------------------------------
      --Function that converts the percentage of the groove slider
      --to the equivalent pattern note delay value (every second 16th note). returns string
      local function convert_pc_to_sixteenth_delay()
        
        --get the groove slider percentage
        local groove_percent = renoise.song().transport.groove_amounts[1]
        --the renoise groove sliders range of 100% seem to covers a range of
        --0% to 66% of the delay range. The full delay range is FF hex (256 decimal) so 66% is rounded to 170
        local RENOISE_GROOVE_MAX = 170
        
        --scale to 170 ((66%) three quarters of the 256 max delay range)
        local scaled_groove = 100 * (groove_percent/100) * RENOISE_GROOVE_MAX
        --scale to LPB value (default is 4)
        scaled_groove = scaled_groove * (renoise.song().transport.lpb/4)
        --convert to the hex value to show what would be typed into the pattern delay column
        --on every 16th note
        return string.format("%X", scaled_groove)
        
      end
      --------------------------------------------------------------------------------------
    --Function to convert renoise swing percentage to a Linn Drum equivalent (the first drum machine to implement swing in 1979) 
    --In a Linn Drum the swing values range from 50% to 100%
    --The 50% start value means equal time for the first sixteenth note and the second sixteenth note. i.e. 1 vs 2 and 2 vs 4 (of 16)
    --In renoise this is counted as 0% start value. The renoise range
    --covers from Linns 50% to [[[87.5%]]]] (only three quarters of the Linns full range)
    --The following function accounts for all these factors

    local function convert_renoise_pc_to_Linn_pc()
      
      --get the groove slider percentage
      local groove_percent = renoise.song().transport.groove_amounts[1]
      
      local RENOISE_GROOVE_RANGE = (100/66) --slider covers 66% of a 16th note
      local SCALE_FACTOR = RENOISE_GROOVE_RANGE * 2 --Linns theoretical 0-100% range covers two 16th notes so multiply by 2
      local LINN_RANGE_START_PERCENTAGE = 50 --Linn starts at 50% so we add this at the end of the calculation
                                             
      --scale then * 100 for percent.
      groove_percent = ((groove_percent / SCALE_FACTOR) * 100) + LINN_RANGE_START_PERCENTAGE
      
     --for drum machines that use Linn groove but start at 0% 
     -- local adjusted_groove = groove_percent / 2
     -- adjusted_groove = string.format("%.1f",adjusted_groove)
     
    -- return (string.format("%.1f",groove_percent).."% ".."["..adjusted_groove.."]") --format to 1dp
      return (string.format("%.1f",groove_percent).."%") --format to 1dp
    end