Probably impossible due to limited resolution in the groove settings, maybe not available in the api, or it just doesn’t make sense , but would it technically be possible to make a selection in a track containing values in the delay column and from this calculate the most corresponding groove settings? Vice versa would be cool too
The envisioned tool would reset, cut away all delay values & enable and attenuate the groove settings accordingly after running it, so one gets replaced with the other…
Lets say I have an old funk breakbeat, I slice it and put all the slices in the pattern using Dblue’s slice to pattern script New Tool (2.7 & 2.8): Slices To Pattern .
I’d like to use the un-quantized groove of the particular break as a groove template for all the other tracks and currently there’s no way to (quickly?) do it. Maybe converting the selected delay column values of a track to bpm/lbp pattern commands is a better, more precise way to get a global groove?
So conversion from delay values to a combination of bpm and lbp pattern commands should be feasible, or is it hard to determine the math behind it?
Some programs let you save slice marker positions as groove templates, which you can use to align other events, using dblue’s script you can translate the slices into the patterns. Would be nice if the delay values in these patterns, which are onsets, could be used globally…
…maybe the easiest solution is to have a tool which copies a selection of delay values throughout and across all tracks?
This would be intriguing to say the least! A similar thing which I’d consider useful would be to be able to copy Note Offs across the whole length of the pattern on selected_track… I hope whoever does the delay-value-copier will also be able to do the note-off “spreader”, or however one wants to call it.
And yes, your LPB/BPM -setting on MasterTrack would be a functional solution - if someone can figure out how to convert Delay Column Values to LPB/BPM so that it makes sense. A simple example could probably be easily replicated.
That’s because it is called shuffle internally
codesnippet:
--------------------------------------------------------------------------------
-- renoise.Transport
--------------------------------------------------------------------------------
-------- Properties
-- Shuffle.
renoise.song().transport.shuffle_enabled, _observable
-> [boolean]
renoise.song().transport.shuffle_amounts[]
-> [array of floats, 0.0 - 1.0]
-- Attach notifiers that will be called as soon as any
-- shuffle value changed.
renoise.song().transport.shuffle_assignment_observable
-> [renoise.Observable object]
I’m not going to build the ReGroove(TM probably)-like functionality because i understand shit about groove settings I always have to make my own… maybe soon.
Bringing the shuffle settings to track(s) should be easy, even if you want to consider delay values that are already there. “Getting” groove from track will be a whole different function and difficulty level
This is one of those things that I just don’t understand. GUI says Groove, → logic says → grep the documentation for Groove. No Groove? No API function for Groove.
Instead, GUI says Groove → logic says search for Groove in documentation, then be told it’s Shuffle internally. the API documentation does not have a single mention of Groove, even tho if the GUI says Groove and it’s Shuffle internally, the documentation should mention the keyword Groove and not just expect someone to randomly come up with “oh, no groove? well, i’ll grep for shuffle” -type intuitive thinking.
i wonder what else is there that’s called something#1 in the GUI and something#2 in the API Documentation + function name.
API should use Groove really. It’s called Groove Settings within Renoise and within the manual/tutorials page. A mistake in the API terminology or is there really hidden Shuffle settings which are different to Groove?
Yeah I really think that the API should use the same matching terms as the GUI.
esaruoho@dsl-hkibrasgw4-fe4ddc00-9[~]$ sol groove
esaruoho@dsl-hkibrasgw4-fe4ddc00-9[~]$ sol shuffle
-- Shuffle.
renoise.song().transport.shuffle_enabled, _observable
renoise.song().transport.shuffle_amounts[]
-- shuffle value changed.
renoise.song().transport.shuffle_assignment_observable
esaruoho@dsl-hkibrasgw4-fe4ddc00-9[~]$ alias sol
alias sol='cat Solution.txt | grep -i --color=auto '
There are no mysterious hidden settings anywhere. The functionality is referred to as ‘shuffle’ internally within Renoise’s own code, so this was simply an oversight when adding the LUA functionality and documentation.
We’ll fix this to ‘groove’ for the next version if that keeps everyone happy? It will obviously break any scripts that are already using the shuffle properties, but I’m pretty sure I haven’t even seen a single tool that uses this stuff yet, so it shouldn’t be too much of a problem?
It’s been referred to publicly as ‘Groove’ for so long now, so I think it’s probably smarter to keep it this way and fix the LUA crap instead.
Better to avoid confusing a ton of regular users who already know and rely on this thing being called ‘Groove’ (and probably don’t give a shit about LUA), rather than slightly inconveniencing a few tool coders who can easily fix their code with a very quick search/replace operation.
, but would it technically be possible to make a selection in a track containing values in the delay column and from this calculate the most corresponding groove settings? Vice versa would be cool too 
