Sure thing. I’ll try to set aside some time to work on this thing every couple of days or something like that. There’s still lots of room for improvement.
Very nice tool.
Is it possible to expand/shrink the patterns in the entire song with one click, or did I overlook this feature?
I don’t think this is too hard…
Simply an extra mechanism to scan the complete sequence and let the original program reprocess the supplied pattern. I haven’t peeked at the code though, but i suspect the pattern-size is looked up currently from the current cursor position and sequencer position. This would require a little change in that case.
The act of processing all patterns is of course very easy, but the main reason I did not add this yet is because your song may contain patterns that are different sizes, so it could be tricky for my tool to understand what it should do in those situations. Beatslaughter’s 4 LPB to 12 LPB tool could easily process the entire song because the conversion is always working with whole numbers. This tool is a bit more involved, because it’s potentially working with fractional conversions, and therefore extra care is required.
Let’s imagine you have a pattern that you want to convert from 32 lines to 57 lines - a silly example I know, but stick with me.
The conversion ratio for this would be: 57 / 32 = 1.78125
All the notes in the pattern, note delays, etc. are processed (expanded in this case) using this ratio of 1.78125
But what if the next pattern in your song is only 16 lines long, rather than 32? If we apply the same ratio to that 16 line pattern, then we end up with a new pattern length that needs to be: 16 * 1.78125 = 28.5 lines
Obviously we cannot have half of a pattern line, so what should happen in this case? The new pattern length could be rounded down to 28 or rounded up to 29, but in both cases you end up with some incorrect results: If we just use the same conversion ratio, then one of the notes will end up being positioned incorrectly, and possibly even delayed so much that it disappears off the bottom of the pattern itself and is never actually heard. But if we change the ratio to fit 28 or 29 lines, then that pattern will have slightly different timing to all the other patterns, which could dramatically alter how that particular pattern sounds.
So, I still need to do some thinking about the smartest way to handle these kind of situations. It probably won’t be a big problem most of the time, but I don’t want the tool to produce any really incorrect results that might give people a nasty surprise. Maybe I’ll allow the user to perform the ‘incorrect’ conversion anyway, but simply warn them about it first by analysing the pattern lengths and looking for potential problems.
awesome, that’s something i’ve been missing since i left ft2 behind.
It would be nice to have the new pattern lenght in HEX also
Yeah… I prefer hex in the pattern editor myself, but I just thought using decimal would be the smart choice for the tool. I’ll probably add an option for this somewhere. I wonder if it’s possible to read Renoise’s own preferences and then display whatever the user actually likes.
this is at the heart of the matter. same with leaving ST3/IT2 behind. you (dBlue) have done an amazingly good thing, and are to be commended (and hopefully properly rewarded) for your valiant effort.
v1.01 Update. Made some small improvements to how the automation points and pattern commands are processed. The repositioning of these values should now be a bit more sensible.
This calls for a Tools page. You will?
I certainly will when it’s a little more polished.
People don’t even understand how cool this tool is! Paradigm shift in programming grooves.
thanks for making this tool!
Thanks guys. I’m glad you’re enjoying the tool. I’ll try to spend some more time on it this weekend.
Found a bug.
- Launch the pattern resizer so that the GUI is on the screen
- Load a new song
- Click the red [3/4] button
*** std::logic_error: 'trying to access a nil object of type 'class RenoiseSong'. the object is not or no longer available.' *** stack traceback: *** [C]: ? *** [C]: in function '__index' *** [string "do..."]:36: in function *** main.lua:127: in function <126><br> <br>``` </126>
I also find it useful, thanks a lot!
I don’t know if this would be possible for a future update, but it would be nice if the tool could i[/i] somehow place tempo-patterncommands in the beginning line of the pattern editor. This to keep the perceivable speed the same as the pattern your converting.
Thanks, I’ll check it out. Looks like something pretty simple and n00bish on my part
I did actually think about this, funnily enough. In cases where setting the LPB doesn’t get you 100% to the correct new speed, I thought of adjusting the BPM as well until things matched perfectly. The only reason I didn’t yet is because it could obviously dramatically change how the song behaves, not to mention interfering with any tempo-based effects you might be using. But… yeah, it’s all just optional stuff anyway. I’ll look into it