Script Idea (Done): Pattern Divider & Juxtaposer

Renoise Tools
21

This is a rather personal request as not many see a use for it apparently, but I think there is some nice groove potential in this. Maybe I need to make a sound example, but I have no time now…

besides creating strange rhythmical grooves on a macro level it could be an excellent texture generating tool for sound-design / sculpting purposes on a more micro level; dividing the original pattern in lots of slices and joining/mixing these back in an uneven length pattern. Sort of like fractional overlapping / gating of pattern snipbits.

I use a texture tool in CDP to manipulate samples and this would apply a similar concept on events.

22

Maybe this works? If you get it to work, could you test if it produces the result pattern like you meant. I think I understood what you meant…

23

You are an absolute champion! :slight_smile:

Seems to work fine here :walkman: :guitar: :drummer: Can’t thank you enough man, I owe you one!

24

It is perfect for my initial wish to transform the note data, I was thinking about fractional results as well for stranger grooves, so having note events blocks having delay column values (sort a like dblue’s pattern resizer does, resizing to odd length patterns), but maybe this is hard to do real quick. Anyways I’m really happy with it! Cheers B)

25

Yay!

For the delay stuff you just tried to explain… Uhm. I think It’s back to MSPaint for you… meaning I didn’t quite understand that bit. Are you talking about offsetting the ‘chunks’ with a delay? That should be doable, at least to a degree.
But maybe I should first take a look at that pattern resizer thing. Anyway, now that I’ve got this gadget reportedly working, I can start polishing it a bit. Thankyou for your co-operation, sir. :)

26

yep, it would mean the ‘bend signature’ button is never invisible in your tool :), so that you can for example divide a 64 pattern in 6 chunks and adjust each with -2, this isn’t possible right now. In the dreamed update the first chunk should start without a delay, and I guess the last one has to be rounded at the end, as patterns can’t have a length like 64.3 or something.

Maybe Dblue’s pattern resizer tool can give you a hint on how this could be done?

27

Ok. As I thought, then. Sounds interesting… Yep - the pattern resizer shows quite well how to do some stuff. Mostly I’m worried about triyng to squish two notes in the space of one; the fractional chopping might require that… But there were some ideas in dblue’s tool for that too. I also kinda want to try something for ‘fractional pattern length’.

28

Now would be the perfect time to ask for this to be added to, i.e. expand / shrink, so you can take a set of 4 bars of material, set 1 bar to be the chopdown, then be able to set that at the start of every bar there is an expand on the selected pattern data - and then at the start of the next bar there’s another one. This’d be really sick.

(Well, *2 / *0.5 multiplication of selection content while … nm :D

29

to cryptic mate, need additional words and better explanation :) … am I right, you want to be able to define a portion of the pattern that would get added to every chunk at the beginning and/or end after bending timesig? How would you define this portion, through selection in the pattern I guess?

30

request:

right now the juxtaposed pattern is added into a new pattern above the ‘original’, would it be possible to have it optionally operate within the pattern that you’re dividing in chunks? So the operation replaces the ‘original’.

Cheers!

31

Hello.

Here’s a 0.20 version. I chose to go for the fractional chopping. The so-called-gui on the test version got a cleanup too.
This is an unfinished product. On some cases it will not be nice on your song data, so use at your own risk.

The fractional chopping is an early point version, still has some issues for me to resolve (hopefully in 0.2X). I thought I’d add this here anyway, because it shouldn’t break your stuff, if you chop & produce perfectly cut chunks, but the fractional stuff might get kinda weird. It’ll lose meaningful data (Just try to cut a 64 line pattern in 13 chunks, with no adjustments to lines (adjust=0), and you’ll see what I mean), It doesn’t account for existing delay values etc…

The gui still has some bugs that I should take care of. Things jump around and loose visibility. Jerk the chunks value around if you loose the button.

When things get too funky for even-line patterns, there’ll be a little checkbox next to the big button. When checked, the tool tries to go “fractional pattern hack” on you. So if you want it not done, check this off. This thing is very early also. Has many issues, some of which really cannot be ultimately solved because of the nature of this “hack”. So if this stays, it will always be optional. Anyway. Needs some work too, I’ve seen it produce odd things. For testing, try for example cutting a 64line pattern in 4, adjust each chunk by 0.125 lines. You’ll see the mess it makes. For best “I really hear the difference!” -results, loop the result pattern when listening. Also don’t store anything important in the Track 1 effect column 1.

The slider in the gui will probably be off the next version. Thought it was a neat idea, but it doesn’t really work at all.

Yeah. So. I see this going in directions that might overcome the original purpose (courtesy of Jonas) I tried to resolve, which was to convert one time signature into another. While this still is one thing I’d like to properly implement with this tool, I think it could do more than just ‘bend time signatures’. So. The name might change. Or not. We’ll see.

Menee niin yli hilseen kyllä että… öööh… tuota… :blink: (Transl: don’t understand)

Agreed. This should be added…

32

:drummer: Cheers mate! Testing right now B)

Like what you did with the gui, don’t mind the slider really, what don’t you like about it? Through holding ctrl while dragging you can increment or decrement in smaller steps.

There seems to be something strange going on with the delay values, it looks like all of them are collected in the first track separated over multiple columns, instead of placed on every track in the song. At least, that’s what I expect it to do? Or am I doing something wrong?

ERR: edit: I didn’t have the delay columns expanded for the other tracks! Enabling them does show calculated values. I’m not sure if a minimized delay column is still taken into account. Still, the first track in my song is fully expanded after running the script, showing every column, while only the first one contains note events. Looks like a bug?

Anyways, cheers for your work, this is already a great tool for experimenting with strange grooves!

by the way, would an alternative to using the delay column be, using the bpm and/or lbp pattern commands? For example auto insert these in the master channel track after bending timesig.

I couldn’t help you with the math behind it, but maybe other scripting geniuses can help here!

33

Encountered a bug notice:

This seems to be because you are inserting bpm/lbp pattern commands when running the script. Would be cool, if the original speed was also inserted in the next pattern as now, switching to the next pattern could send Renoise to hyperspeed :)

34

It seems inaccurate to my taste. Also the max value on most cases is too big compared to the values that i could imagine using more often, so I end up using only a small portion of the slider. Thanks for the ctrl-drag -tip, didn’t know that. It seems to be cmd-drag on mac, but handy anyway!

Don’t know what is happening there… I have no idea why one track would expand. The expected behaviour (for this point in dev) would be: no columns expand, all are stuffed up to their necks with delays. Should investigate a bit on this. As to minimized delay columns, I’m pretty sure they are taken into account. Pretty sure. Hmmm.

Actually the “fractional pattern hack” tries to use this very technique (unsuccesfully, as noted below :lol: ). There are some specific problems in this method, but definitely should investigate further, because using tempo-changing to emulate fractional lines would mean a)getting rid of the delay-spam (which could be reduced by other means anyway) and more importantly b)solving the problem that arises when you have for example two consecutive notes that have delay values, say first:80 and second:00, and you need to shift these backwards by 10 ticks.

:o effect column values 0-255? Well whaddoyaknow? I thought lua counted from 1? <_< Or maybe I’m trying to stuff in a 257? …
Well, I’ve never encountered this here so thanks for the report! Will try to reproduce/squish. (EDIT: I think I got it. Happens when having high lpb, trying to apply fract pat hack with smallish “tick leftover”. ->FX value needs to be super high. Will prevent this somehow.)

As a fix, I’d recommend ticking the checkbox off for now.

EDIT:
And yeah. The hyperspeed thing. Annoying, isn’t it! I’ve envisioned a solution within the pattern, but haven’t really tested this. If it don’t work, as you said, got to add that lpb-fx on next pattern… Not cool to mess with other patterns than the one being edited though.

As a fix, I’d recommend ticking the checkbox off for now. :D

35

Did some Gui shuffling, added error catching for bug found couple of posts above, implemented insert/replace option.

36

I don’t know if it is possible through lua, but I remember Taktik adjusting the inertia characteristic for the transpose slider in the instrument settings so the slider has some weight at the more usable values. For me it isn’t to big of deal as you can still double click the value and enter it manually.

No problem, it is consistent behavior throughout all of Renoise, handy when you want to finetune a parameter.

yep, it is strange as it has only happened in one of my tracks yet, now I’m starting to doubt if it wasn’t already fully expanded, but that doesn’t make sense for the few samples that are in it. Will investigate further!

Cool! Thanks for the update :)

37

In this update:
-delay spam management. Only columns with something in them are processed.
-existing delay values in delay columns are taken into account. Maybe even correctly!
-added (activated, rather) keybinding under Global:Tools:
-did a close_dialog()-function, which closes the dialog and releases notifiers when closing/switching documents
-fractional pattern hack now applies lpb effect on next pattern too. No hyperspeed annoyances.
-some optimization

Still a work-in-progress. Don’t expect flawless victory.

I’ve scheduled the “using lpb instead of delays” -thing to version 0.3 for now. But it seems very interesting. For 0.2, I’ll try to make the delay-stuff work as reliably as I possibly can, and might rearrange/optimize the gui code a bit for future additions.

EDIT:
Right after pushing this in: Noticed a stupid bug. Having the fract pat hack tickbox checked, and making a result that needs no hack, the button may get stuck thinking that you want to do it anyway, and not let you bend stuff, AND hide the checkbox. Bypass this by making an uneven result, untick checkbox. Sorry 'bout that, will be the first thing I fix for next one.

38

Thanks, will hopefully find some time to try it out soon and actually make some music with it! :drummer:

39

Just to bug you with more feature requests, considerations for future updates as that is what I do best:

a toggle to apply your tool onto a selection in the sequence editor and/or complete song! So if you want to try out a certain groove on a few patterns, ideas or complete song, you don’t have to individually bend sigs in every pattern B) .

(For a future, future version consider what I think esaruoho was hinting at somewhere in this thread (or maybe not :P );

… think about a way of optionally filling in the gaps, when you’re dividing and adding lines.

Let’s say you have a 64 length pattern made, you divide it by 4 and add 8 lines to every chunk. The newly made pattern will have a pattern length of 96. Because of the addition the new pattern will contain empty spots with no note-data.

What if you could define another chunk to continuously fill the empty spots? This could potentially create interesting results.

Maybe this could be implemented through being able to define beginning and end pattern-lines in your tool, to determine the chunk that’d get ctr+p’d (paste continuously) within the void. The range between the lines should be within the range of the amount of lines that are added)

Does it make sense? Maybe I’m scaring you away now, just thinking out loud :drummer:

40

Would be nice. There are some obstacles to cross, though. The splitting is now based on pattern length (lines/ticks) only. If all patterns are the same length, then there’s no problem. But patterns that have a different length, should get a different treatment. Recognizing those, and deciding what to do with them… well, I have some ideas.

Yes, I tried to wrap my head around what the actual idea was, but couldn’t fully grasp it. I think it was about scaling the stuff somehow…? But I’d be interested to get a more detailed explanation.

My thoughts exactly. Well. Not exactly but I already thought of having some option to fill the empty gaps. With something. Stuff. Maybe by repeating the chunk from start, maybe by filling it up from the end, don’t know yet. Got to try this at some point.

Yeah, it makes sense. Not scared. Yet. :lol:
There’s tons of stuff I’d like to try, but sadly I’ve got to make this fractional chopping thing work right first… The results it produces right now are sometimes unpredictable. Also I’m most of the time on the edge of my ability to understand what’s going on in the code, so the debugging gets kinda painful. But I like challenges, and I think this project has a lot of possibilities. I’m slowly cleaning things up & making it spiffy.

Here’s 0.23

-fixed gui bug: apply fract.pat.hack inconsistency/lock situation
-calc & display result pattern error in ticks
-fractional pattern fx -commands inserted on master channel by default. (to be refined later)
-column based copying, instead of line based. (tool can now add notes on extra columns, if needed for stuffing two notes into space of one. to be refined.)
-fixed a bug which caused fractional chunks lose the fractional line data at the end. (can now split for example a 64-line pattern in 13 chunks without losing data). (It’s still not perfect, as it doubles some notes, but it’s getting better.)

Also a gui redesign, not complete.

Getting better. But it’s still 0.23. Be warned.