New Tools: Iterative Quantize And Groove Tool

[neopan]

@nism

@neopan: I know the tool sometimes drops notes, it is a limitation of the tool, and unfortunately not one that I can easily fix. It happens when two notes are written to the same line in the same column, the first one gets overwritten in that case. Could that be what’s happening here, or do you think it is a separate issue? Some additional information would be useful: Does it delete all notes or just some? Are the dropped notes close to other notes? Have you tried to un-check the ‘keep notes in the same column’ option?

my bad, i got around it. when i entered only 4 notes it would erase them while adjusting the cycle lenght (without pressing apply) it seems ok when i enter more notes

[nisanmol (nism)]

@It-Alien

I have filed a bug report onto the tool page.

The quantization gets triggered automaticaly upon dialog opening.

Fixed.

[eyesee]

I was trying these tools and find iterative quantize the most useful.

it struck me while using it that if it were possible to read in another track as the target quantize,
you may well have a very effective groove quantize tool.

I was seeing what MPC grooves looked like in Renoise, but I think the midifile makes them LPB default to 4.
though maybe I can change that in prefs. in any case that seemed to make it hard to potentially see the right
amount of precision in the midi placements. I prepared the MPC midi in Logic and exported to a midifile.
so that will be at a resolution of about 240 ticks per 16th. 3840 per bar. I will see if I can upload the midifile
of the first 16 MPC grooves. because the MPC wanders slightly and possibly because of this LPB setting, you might
sense certain bars of the 4 bar grooves to be more fluid than others. you might find they make useful templates
if you were to put any in any of your tools.

thanks for the tools… />

[hm_amp_257 (hmā)]

Very useful, thanks nism!

[ffx]

Unsure if this is the official groove tool thread…

nism, I hope you don’t mind that I post here a modified version of your Groove Tool. Did optimize the groove tool by following joule’s and danoise’s optimization tips over here:https://forum.renoise.com/t/renoise-tools-speed-optimization-initiative/45510

Results in really huge speed up, so its much more usable now here, without slider lagging etc.

Also added shortcut and pattern->track context menu entry.

Also moves now at least the note column fx along with the note.

It still does not move the track fx, which still will result in chaos if there is a midi command. (Though I already prepared it)

Groove tool optimized / +note column fx move / +shortcuts

Attachment 6940 not found.

BTW. the tool does not move the fx data along with the notes. Will result in chaos for example when using midi commands.

[ffx]

Update, added at least now note column fx movement… See post above.

It still does not move the track fx. So still a note movement which consists of a midi command will result in chaos. I skipped this, because I am not sure how to handle it properly. Let’s say there are two note columns, one with a midi command:

inst inst      
    | pan | pan 
    | | del. | | del.
    | | | note fx | | | track fx
    | | | | | | | |
C-4 01 40 90 0000 E-4 01 M1 C0 0000 4000

Groove tool now moves the notes down by 40 ticks:

C-4 01 40 D0 0000 --- -- -- -- ---- 4000 <- destroyed midi command
--- -- -- -- ---- E-4 01 M1 00 0000 0000

In this scenario, should the M1 stay in line 1, without a note, only instr. num? so only stay, 1. if notes still left in line 1 + 2. a midi command was used in pan?

Could the devs give me some information/discussion on how to properly handle those cases? Are you planning to improve the midi command handling anyway?

How do I know which track fx column belongs to the midi command? Is it always the first one?

[Roppenzo (Rpnz)]

tried to downgrade this tool to 3.0 , but it gives me :

main.lua:467: unknown property or function ‘effect_number_value’ for an object of type ‘NoteColumn’
stack traceback:
[C]: in function ‘_error’
[string “do…”]:47: in function <[string “do…”]:35>
main.lua:467: in function ‘read_values’
main.lua:904: in function ‘GrooveTool’
main.lua:5: in function main.lua:4

someone can help me?

[ffx]

You need to use the old version for old Renoise, not my modified, since it accesses fx columns, which AFAIK were not available before?

[Roppenzo (Rpnz)]

does not work either

[joule]

Found this tool now! It’s a great concept and implementation, but seems a bit buggy…

• Have the tool opened. Enter pattern data. Move sliders. The newly entered pattern data will vanish. Most likely because the tool caches the pattern data in order to ‘remember’ out of bounds notes on the first line.

• Also there are some quirky GUI behaviors when changing cycle length. No biggie…

• Automatically extracting the groove settings from the selected patterntrack would be more sleek. It seems the tool tries to do that, but when you reopen the gui the groove is applied one more time?

• Also, when trying to extract the groove, use a rounding principle for delay values to determine what the original position (slider) was, instead of just using the line index of the note.

• Doesn’t seem to follow the selected track.

Further suggestions:

• Load midi as groove template. Parse beat (slice markers) as a groove template.

• Should imo have an option to retain delay values that are already present. (e g, first apply a “timing” groove… then apply a swing groove, for example)

• Strength slider (multiplier).

Mind if I have a look?

[ffx]

Sure, the author of the tool doesn’t even answer anymore, it seems…

[Roppenzo (Rpnz)]

Further suggestions:

• Load midi as groove template. Parse beat (slice markers) as a groove template.

that would be awesome!