Groove Settings

I just wanted to point out again that the groove settings (still?) don’t work. Is that hard to add? Would be nice to have it in the 1.5 final :unsure:

Using 1.5beta3 here and the groove settings work ok. But there’s a catch - your notes have to be on every line in the pattern. So for example, if you use speed 03 and then skip every other line for more “accuracy”, the groove settings won’t appear to work, even though they actually do (put notes on every line in speed 03, and slow down your bpm, and you’ll hear it).

So, it does work, just not as we’d probably like it to work - by being able to specify which lines the groove is applied to or something.

You are exactly right. And as i am always using speed 3 it does not work for me.

So after trying what you said, namely putting a note on every line at speed 6, i figured that i totally don’t understand the logic about how this feature is supposed to work.

It has sliders that read:

0&1
1&2
2&3
3&4

I thought these numbers represent a line each, so if you slide 0&1 to 100%, lines 0 and 1 would be delayed. But when i observe what renoise does with that setting, i see that line 1 is being delayed only.

So why is it line 1 rather than 0 and 1?

In a normal scenario i want this:
0 -
1
2 - delayed
3 - delayed
4
5
6 - delayed
7 - delayed
8
etc.

(or if at speed 6, scale this by 0.5)

So right now you cannot have line 0 being delayed, since if you put slider 0&1 to 100%, the first note (line 0) is not being delayed. I have to say i did not find any settings that would not give you awkward results.

I think if renoise just would actually do what the sliders say (regarding the line numbers), the whole thing might work. I mean, i remember at least getting decent results in renoise 1.x on speed 6.

I’d love to see this working! :dribble:

edit: i don’t know how hard this is, coding wise, but i find the theory very simple.

Loolarge

It is a little strange I suppose, but from what I can gather, the groove gets applied to the inbetween lines, and the whole thing repeats every 8 lines.

So, for example, with groove settings set to:

0 & 1: 20%
1 & 2: 40%
2 & 3: 60%
3 & 4: 80%

This will happen:

00 - C-4 — no delay
01 - C-4 — delayed by 20%
02 - C-4 — no delay
03 - C-4 — delayed by 40%
04 - C-4 — no delay
05 - C-4 — delayed by 60%
06 - C-4 — no delay
07 - C-4 — delayed by 80%
08 - C-4 — no delay
09 - C-4 — delayed by 20%
0A - C-4 — no delay
0B - C-4 — delayed by 40%
0C - C-4 — no delay
0D - C-4 — delayed by 60%
0E - C-4 — no delay
0F - C-4 — delayed by 80%

etc.
etc.

Some kind of “Skip every X lines” or a multipier value of some kind would be useful to use with the groove settings.

You mean you want groove settings being apply with a row-offset option (or skip-value). Meaning that groove machine has to apply groove to every xth-row set in the option.
Don’t know if it is hard to add.

Perhaps an even more interesting/advanced method (and this has actually been mentioned in the forums already, around the time of 1.2 I think) would be some kind of groove track in the pattern editor itself, which would be visually similar to the master/send tracks.

Then, instead of simply having the rather limited 0&1, 1&2, etc. setup which is currently in-use, we have a dedicated track as long as the pattern, which we can use to put any kind of crazy groove effects we want. :P

Quick mockup graphic:

Hmmz, you can use a send-track to do the same, but then you have to use the old speed / bpm settings the oldskool way.

The only advantage with your groove track would be a numeric percentage constant you could place in the effect column.
But this could also be done by adding a new effect command that does this and leaves out room for another kind of track.

Not sure I understand what you’re saying about the send track thing? Is there a way to use a delay command on a send track to affect every track you send to it?

I think I’m beginning to get a good idea of how the devs feel about adding new effect commands, heh. Seems like there just isn’t anymore room without completely restructuring the command system. Seems like it would be easier from a programming perspective (given the current Renoise program structure) to add it as a dedicated track.

Also, it would be extremely easy to manage a dedicated track rather than an effect command. For example, you could quickly copy and paste the groove track to new patterns, rather than potentially wasting time extracting just the groove effect commands from a track (if your track had a mixture of groove effects, panning, retrigger, etc.). Shift F4/Shift F5 is a lot more efficient than playing around with block selections and Alt+F4/Alt+F5’ing those, y’know?

From a logical point of view it just seems to me like it should be kept separate from the audio tracks, which it currently is anyway. Given the fact that it would really only need to be a 2 digit column (00-FF), I don’t think from a GUI point of view it would really get in the way that much? Maybe its visibility could even be toggled on/off somehow, for people who never use it and really wanna get those few pixels of room back :P

The reason why i want this to works is because if you do it the oldschool way, it screws the BPM-sync of alls VST/i’s.

I think the concept of the groove settings is simple but effective, so there is just a little bug to exterminate :panic:

I mean you just use the F0xx commands to change between various tempo elements, which was the past trick used to change a songgroove and it affects the whole pattern, not just sets a delay upon each row like the built-in groove does.

You set the groove for one or two measures, select the range, copy the block and use CTRL-P to continuesly paste the groove block throughout the send-track (for that pattern).

It gives you every room to change the groove any way you like it and change it anywhere in your song.

Just try this groove block:
Row Sendtrack
00 - F040
01 - F080
02 - F0A0
03 - F080

Copy it and continuesly paste that block, if there is anything you don’t like about that groove, change this block (and copy it continuesly again) until you got what you need.

The sendtrack or mastertrack is sufficient for such purposes.
Just add another sendtrack and name it groove, that’s all.
You frankly already gave the good example with your image snapshot.

And if you have VSTI’s that are sensitive to BPM syncing, it’s probably even better to use BPM grooving than delay grooving as BPM synced VSTI’s probably adjust better to this method than to a patterndelay.

No, i don’t think a new command is even necessary, using the known ones require a little accustomisation to get the hang of it.

I’ll extend the old-skool groove-part settings one day with an example.

Oh! Ok, heh.

Yeah, I used the tempo trick myself quite a few times in the past, in FT2 and stuff. Seems a bit unnecessary these days though? We know Renoise has the power to do this kinda stuff in an efficient and intelligent way. It just needs a little fune-tuning to be perfect. :P

Just applying note-delay is not really intelligent.
The routine that performs it just applies a multi-row delay effect but using delays only work out when they fit into the scheme and that groove settings do not always work out right is just that perfect example of a situation where delays don’t work out. The few threads here pointing it out saying enough.

I was fond of using pattern delays myself (they also always work, but not necessarily fit in well enough) because it only required me to use one effect comand and one value, i just had to put them into the right rows.

Just to play devil’s advocate once more… Changing the bpm every line is not really an intelligent solution either.

How do I quickly/easily figure out exactly what bpm my track is actually running at? Switching between something such as F050 (80bpm) / F090 (144bpm) gives a nice shuffle, and after playing around for a little while it seems that the overall bpm is roughly 93bpm (at speed 06). But how do I figure that out quickly if I need to? For me it doesn’t always matter that something I create is done at an exact bpm - I just do whatever I think sounds nice, but I know there will be times when I need to work at an exact bpm, or be exactly synchronised with other things, and this method simply isn’t practical in those situations.

Then there’s things like the strange behaviour that suddenly appears in functions such as sample beatsync - the pitch of my sample suddenly going up and down wildly, as if you were playing a vinyl record and constantly changing from 33rpm to 45rpm. Yes it can be avoided by turning off beatsync and doing things other ways, and in certain situations it even gives a desirable effect, but most of the time it’s just not practical and can slow down your productivity. Trying to manually bpm match a loop to your track, constantly playing and stopping, editing the finetune, over and over again, really isn’t that much fun.

Then there are VSTs which rely on the host bpm for certain synchronised effects such as delays or arpeggiators. RetroDelay, which is a really wonderful tape delay style effect that I use very often, simply becomes unuseable in the bpm-synced mode. The once lovely delay effect suddenly becomes a horrible warped demonic noise, pitch-shifting and jumping all over the place. Again, yes it can be done another way, by disabling bpm sync and manually setting the timing you want. But again, it’s just another little convenient thing which goes a long way in keeping you more productive and efficient with the actual process of making music.

Sometimes I don’t want to be an knob-twiddling freak, getting every last parameter exact and perfect by hand, I just wanna get the ideas out of my head quickly and get a nice, basic track going which I can build on top of, y’know? I view the groove settings in Renoise as a very powerful, time-saving device, and I would love to see it expanded upon in the future to unleash more of its potential.

Anyway, I just want to clarify again, I’m simply playing devil’s advocate here, just trying to show you the other side of the argument. I hope it doesn’t sound like I’m just bitching and complaining about things. I really try to give my thoughts in a constructive way as much as possible.

The silly irony to this is that when I use a groove in a track I usually don’t actually want it applied to the whole song, hehe, so I just manually put the delay commands on the notes that I want. But it’s also very nice to have tools like the groove settings available if I did want to use them, and I know there are other people here who would obviously like to see some more flexibility there.

Then use pattern-delay instead.
But also with patterndelay, your bpm will differ however the song bpm value will remain straight so other hosts can remain synchronised to Renoise (or vice versa).
It’s either that or raise the speed (thus make it slower) and compromise that by raising the BPM and just double or triple the pattern-size and apply the groove settings upon that.

E.g.

FD02
FD01
FD00
FD01

Using Speed 03 (F103) and BPM 160 (F0A0)

Edit: Found out that true BPM calculation still isn’t right using pattern delay though :P

However if VSTI’s can’t handle multiple BPM changes, i consider it a pretty much bad implementation of the synchronisation routine.

I wasn’t aware of the FDxx command, but it’s like you said. Good thing is BPM doesn’t change, bad thing is that BPM is not correct this way. :(

Help, gimme the groove! :drummer:

I don’t think so. Tell me one delay plugin that can handle this(without artefacts like pitch slides).
And what about samples. If you would programm a sampler that notices speed changes, it would have to change pitch all over the time (or do timestretch). This might sound awfull either.

You tried the VST BPM option in the Song properties differently right?
(Like it’s set to tick/BPM instead of BPM only?)

That setting is not relevant, since when using the FDxx command repetitously, the actual playing BPM differs from the BPM that Renoise tells the VST(i).

I just did several tests, and this is the case in all my results.
Renoise file

I used the internal delay here, but the results are the same with Delays that actually sync to the host. Anyway, you can clearly hear the tempo changing, while the BPM setting remains at 120. I also did layer the rendered wave-files in soundforge to test whether they are out of sync.

I know, i am getting pretty picky here, but.

I think this process is pretty hard to do, the current bpm calculation is probably send to the VSTI when it is being called which ofcourse is not the average value.
So this one has to be (pre)calculated, but then again this counts for the whole song.
Now if we could attach the bpm-calculation of each pattern to itself, you might have something you can work with. (And the bpm value will be shown in an extra column next to the sequence name)

It’s a lot of work to add such a feature i guess.

No,

this will happen:

00 - C-4 — delayed by -20%
01 - C-4 — delayed by 20%
02 - C-4 — delayed by -40%
03 - C-4 — delayed by 40%
04 - C-4 — delayed by -60%
05 - C-4 — delayed by 60%
06 - C-4 — delayed by -80%
07 - C-4 — delayed by 80%
08 - C-4 — delayed by -20%
09 - C-4 — delayed by 20%
0A - C-4 — delayed by -40%
0B - C-4 — delayed by 40%
0C - C-4 — delayed by -60%
0D - C-4 — delayed by 60%
0E - C-4 — delayed by -80%
0F - C-4 — delayed by 80%

The overall tempo does not change when adding a groove.

Using pattern delays to add grooves is really a bad idea.

First its far to unprecise (its about groove, and not about changing the whole timeline), second you can only have positive delays with the pattern delay command.

The only problem with the groove thing that is currently implemented is, that its:

  • available on song base only
  • it assumes a 4/4 signature
  • it works only how it should with a speed factor of 6

The first two points cannot be changed that easily (now). The speed problem should be considered as a bug. I will see what I can do to fix this for the final release.