@Syflom: That’s weird, I’ll look into it. If you can reproduce it, please let me know how. I thought about adding number values too, I’ll look into it when I have the time.
@smasha:
Just to be clear: you understand what the sliders do, right?
Cycle length works this way: if you set it to 1, you’ll see just one slider. Move it, and all notes in the column or pattern will be affected. If you set it to 2, you’ll see 2 sliders. Slider 1 will affect lines 0, 2, 4, 6…, slider 2 will affect lines 1, 3 , 5 ,… etc.
You can think of ‘range’ as a multiplier for the slider values. If it is set to 1, the maximum slider value will move the notes 1 line. If it is set to 2, it will move notes 2 lines.
Updated Groove Tool. It looks prettier now. I couldn’t find or reproduce Syflom’s problem, so that is probably still there. Also, I decided against showing values, I couldn’t find a way to not make it look messy. It’s more or less finished now, so I’ll submit it to the Tools page.
@It-Alien: If I understand you correctly, it is intended to work that way. But I think you’re right, it would be better if it didn’t do that, so I’ll change it.
@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
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.
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?
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
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)