First of all, thanks a million for the scripting. This particular script, Custom Pattern Jump, solves a long time desire of mine to have pattern navigation based on LPB. However in its initial state the jumps were targeting the playback position whereas I needed jumps for the edit position. I easily modified the script to suit that need too, even though I had never coded in Lua (but I’m planning to become a seasoned Lua hacker pretty soon ). I added an option to let you choose whether you want to target the playback or edit position, and preserved the playback mode as default to honour Vincent’s original idea.
Here’s the script attached for all of you who need it. And Vincent, perhaps you could have a look as well, and see if I’ve done things properly and perhaps update the script in the Tools area.
Added the change to the tools site. I have added your author data to the description as the author field is linked to the forum account of the uploader unfortunately.
It would be rad to see this function take into account whether “move continuously between patterns” is enabled or disabled. I usually prefer to stay within the same pattern. Also, I find when reaching the end of a pattern and proceeding to the next with this function, it loses place and does not start from the first row of the following pattern. Most ideally, I would like to see an option to stay within the same pattern, and not flop back to the top if “pgdn” is pressed again.
It appears when jumping to the next pattern, it only fails to start from the correct position when “Length / Factor” is used. This is at lpb 12 with a factor of 8, which jumps 24 lines per keystroke. Rather than winding up on line 0 of the next pattern, it jumps to line 7.
The script ain’t perfect i know. There are definately problems when one is using variable sized patterns in the sequence and for some reason, i am not able to make the script anticipate on this even if i enumerate the pattern sizes upfront, there is something behind the scenes mocking my routines that attempt to correct the problem.
So i’m stuck with this half baked optimized version of the script that turned useless.
At the start when i designed this script, i actually did not even aimed for using this in live playing situations. Nevertheless there are a whole batchload of nice ideas i have made a start with that require realtime processing capabilities from within the Renoise Audio engine which is currently not supported and until then, we have to keep fumbling with half assed hacks or other ways to provide some solution or method to eventually get where we want to be.
But perhaps someone around here who has fooled around enough with the sequencer API functions, may see something that i have overlooked. The important bug is that the script works less correct when using different pattern sizes mangled up in the sequence.