That could be partly to blame, but it’s also because the tool does not perform any real error/bounds checking beforehand. You can make the tool fail even when there is no automation at all, just by trying to expand something that would result in a pattern that is longer than the maximum length of 512 lines.
For example:
Pattern that is 256 lines (100 hex) + Expand by 2 = 512 lines ok
Pattern that is 257 lines (101 hex) + Expand by 2 = 514 lines fail
Pattern that is 128 lines (80 hex) + Expand by 4 = 512 lines ok
Pattern that is 129 lines (81 hex) + Expand by 4 = 516 lines fail
The tool also allows the user to set LPB values that are invalid, exceeding the maximum possible value of 256 LPB.
For example:
8 LPB + Expand by 32 = LPB 256 ok
8 LPB + Expand by 33 = LPB 264 fail
So… to improve things here, the tool should not just blindly try to expand by whatever factor the user has chosen. It should check things first to make sure the results will actually be valid, and should clamp the values to be within valid ranges, etc.
I added some error handling. I implemented skipping instead of clamping. I guess handling these failure cases can be dealt with in a couple of ways so I’ll leave it up to the user for now. But the errors and warning are now informative and will not crash the execution.
Thanks for the tip and feel free to comment on the update.
@mogue: hi, was looking for a script that could convert all patterns in a song to a new pattern length value. this sorta does that, but only allows you to multiply by a certain factor. is it possible for you to make it so that you can input a new value (say, 96’) and all patterns in the song are given that new pattern length?
This is hard as the pattern length needs to have an integer division to it’s original pattern length. If not some lines can not convert to their correct locations or might even be lost. So the script has to make quite a lot of educated guesses of where you want to place your values.
But this is not impossible, I want to try something out where the script will let you know what lines will be lost and quantized. Adding settings might also help handle extreme cases of realignment. I’ll try to find time to make something nice.
love this tool to bring old tracks to the new millennium and increase the resolution, however, would love it even more if it would translate the EXX retrigger commands/values during conversion as well!
Right now, track can sound funny because of retrigger quirks, would this be possible to fix?
There is a really really new version right now. It is updated for 2.8 and has some new parsing for delay column and pattern effects.
Effect Commands processed and scaled:
ZL : Lines Per Beat is multiplied by factor.
ZD : Pause Pattern for Lines is multiplied by factor.
ZQ : Ticks Per Line are stored for tick related calculations. Value is not affected.
0U, 0D : Pitch slide is divided by factor and copied to added lines. Remainder is added to the first line.
0G : Glide is divided by factor and copied to added lines. Remainder is added to the first line.
0I and 0O : Volume Fade is divided by factor and copied to added lines. Remainder is added to the first line.
0Q : Delay by Ticks value is multiplied by factor and moves all line content down if out of bounds.
0C : Cut Note’s tick delay value is multiplied by factor and moved down a line if out of bounds.
The volume and panning column are also parsed if they have Ix, Ox, Jx, Kx, Cx or Qx.
I updated the XRNX of the original post:
Please post if you encounter any problems with the new version.