New Tool (2.8, 3.0): Flexible Pattern Resizer

Renoise Tools
1

Pattern Resizer

5141 dblue-pattern-resizer-tool.png

Brief description:

  • This tool allows you to resize (expand or shrink) a pattern to any arbitrary length ranging from 1 to 512 lines.
    Usage:
  • Context menu: Pattern Editor > Pattern > Resize
  • Key binding : Preferences > Keys > Pattern Editor > Pattern > Resize
    Notes:
  • Note delays will be calculated and adjusted automatically. Effect commands and automations will also be repositioned to match as closely as possible, but the effect values themselves are not recalculated or interpolated in any way, so if you use any time-based effects then you may need to be readjust these after you resize the pattern. It’s also possible that a note may be delayed/shifted to a new line, causing certain effect commands (sample reverse, sample offset, pitch, etc) to be positioned on the wrong line, so you may need to do some readjustment there as well.
  • I’ve improved the GUI a little bit and have added a few handy buttons. The ‘1/1’ button will reset the length value so that it matches the current pattern. The other buttons just let you quickly jump to some (hopefully) useful fractions/variations of the pattern length. I’m open to suggestions here for what might be more useful in the long run.
  • In certain situations - especially when shrinking or when your pattern already contains a lot of existing note delays - you may experience some notes being dropped. This is sort of unavoidable due to the nature of the process, as there will inevitably be certain notes that get shifted around, delayed a bit more, etc., and would then try to occupy the exact same pattern line. I have implemented a very basic system to help prioritise which notes are more ‘important’, which mainly comes into play when shrinking the pattern. I have a few ideas for how to handle this better in the future, but it’s still quite basic at the moment. Please let me know if you experience any quirky behaviour, and I’ll try to tweak it.
  • Still very much a work in progress! Use at your own risk, etc. Make sure your song is backed up before you go experimenting with this thing smile.gif
    Changelog:
  • 2010-12-11 - v1.00 - Release.
  • 2010-12-12 - v1.01 - Small improvements to automation and pattern command processing.
  • 2010-12-19 - v1.02 - Fixed this bug. Made some small performance tweaks when processing note and effect columns.
  • 2010-12-20 - v1.03 - Fixed this bug.
  • 2011-03-14 - v1.04 - Updated for Renoise 2.7
  • 2012-03-05 - v1.05 - Updated for Renoise 2.8
  • 2015-02-24 - v1.06 - Fixed this bug.
    Credits:
  • This tool was inspired by Syflom’s post (and possibly others I’ve read in the past).
  • Some of my early code was partly based on the work of Beatslaughter.

org.illformed.PatternResizer300.xrnx (3.6 KB)

3 Likes
2

thank you.

3

Big thanks dblue! I’ll check it out.

4

Great! Thx!

5

dblue for world president.

6

sexeh :]/

7

thank you so much dBlue. this is way better than merely getting someone to implement advanced.edit.parameters keyboardshortcuts for Expand and Shrink - because that would still mess up the note-delays.

here’s to hoping that the Flexible Pattern Expander will be implemented in Renoise. could there also be a Flexible Pattern Shrinker?

MMD: agreed, dBlue for president

everyone: support this guy. World LUA Scripting President woo! :panic:

8

One of the problems here is how to deal with data that will overlap after being processed. This currently affects my expander in certain cases, especially when there are already a lot of note delays contained in the original pattern that need to be shifted even further.

Here’s an example to demonstrate. I’ve used alternating C-4 and D#4 notes to more easily show what happens. After expanding, we would expect the result to contain exactly same sequence of alternating C-4 and D#4 notes, but due to the additional note delays necessary some of those notes will end up occupying the same line, therefore some data will be lost.

Before expanding:

After expanding from 16 lines to 19 lines:

In the first track, we can see that a sequence with no existing note delays expands correctly, and nothing is lost.

In the second track, we have the same sequence of notes contained in a single note column with some note delays applied as well. We can see that after expanding + adding extra note delays, there isn’t enough room for everything to occupy a single note column anymore, and some notes are lost.

In the third track, after separating the C-4 and D#4 notes into their own columns, we can see that expanding works correctly again because there is enough free space to fit in all the delayed/repositioned notes, even though some of them end up occupying the same pattern line.

So… to improve this expander, I will try to add some kind of logic that looks for empty space in the note columns, in order to automatically move overlapping notes there so that nothing is lost. In cases where the pattern is really packed with a lot of notes, then a method to prioritise which data ‘survives’ may also be necessary. As you can imagine, this has the potential to get pretty weird, and it will be difficult to take things like note-off’s into account, to make sure that it doesn’t actually ruin your patterns instead of help them!

A shrinking function will suffer even more from this problem of notes being lost due to overlapping data. Will it simply be acceptable to drop stuff that doesn’t fit into the new smaller size, or will it be necessary to keep as much of the original data as possible by automatically separating it into new note columns? Etc. There are certainly a few interesting problems to overcome :)

9

it was acceptable to drop the lost-in-between-notes for most trackers. i guess it’d be really confusing if the script switched from track#1 having one column of notes to two or four, after shrinking. could be a nightmare to handle?

10

You’re quite right. Nobody really questions the fact that in order to shrink the pattern you will inevitably lose some data. This is just me thinking about ways to improve upon that process. At the end of the day, it’s all just checkboxes in a dialog to enable and disable various things. I certainly wouldn’t enforce any particular method on people when the results would be so experimental. I’ll see what I can come up with :)

11

Thanks for this dblue will check it out!

Good to see you having some time for a bit of Lua :)

12

Really cool stuff! Thanks

13

Bump.

A new and improved tool is now available in the original post above.

Expanding and shrinking is now possible.

If you tried the old version of this tool - org.illformed.PatternExpander.xrnx - then please just delete that and use org.illformed.PatternResizer.xrnx instead.

Cheers!

14

cheers!

Overwriting doesn’t work?

15

They’re both different tools, so you could have them both installed if you want, although it’d be rather pointless.

It should have been ‘Pattern Resizer’ from the start. My mistake. Sorry for the confusion. Just ditch the old one. :)

16

No worries! Great tool for trying strange grooves, I like this a lot :)

If you ever update this tool in the future, consider implementing an option for running the script on pattern selection as well, with a checkbox to keep pattern-length or not. Nice for offsetting rhythmical patterns on separate tracks.

17

woop woop … always wanted a time sig tool… sweet

thanks

18

For sure. I’m still just figuring out the core logic and trying to optimise things. But I’m definitely thinking about how this could apply to a wider range of selections. Making a selection of 16th notes within the pattern, and then transforming those to triplets or something like that, without affecting anything outside your selection, etc. At the moment I’m mainly using it on a temporary pattern within my song, so that I can experiment with ideas and then copy bits and pieces into other patterns.

I should clarify things, just in case. Those buttons in the GUI don’t really relate to time signatures in the way you might think. They’re just handy shortcuts for quickly setting the pattern length to half, or double, or three quarters, etc. You can definitely use this to help you convert stuff to different time signatures, but my tool doesn’t do anything really clever (yet).

19

I like how this tool stretches ‘regular’ sounding groove over an arbitrary pattern length using delay values where necessary and so have the quantized note input on a newly programmed track sound groovish :) .

Heh, was thinking about time signatures as well, and a previous pattern conversion request of mine:

20

dBlue: just tried the new version, and its great! resized a 64 row pattern to 32 and then to 31 and the delays are there. wonnerful work!

i know this is asking a bit much: but do you think it’ll eventually be possible to run this on an individual track or a selection? ;)