ahh yes i found out,but it works well for what i need to do,so thank you so much for sharing this
EDIT:i just tried this on a track that has sync on samples enabled,and even if the results was a bit weird sounding,it was actually really cool,so i will make a remix of that track
nice way to get inspiration 
But if you’ve written triplets in 4lpb the second is still going to be 2/3rd (AA, or D8) I assume you deal with this correctly as it would move it to a later line. Already does need thinking about with the simple tripling used to go from 4 to 12 LPB.
A tip for a more efficient version: Calling track.lines[x] within the loop is a lot slower than calling track:line(x), because track.lines will query all lines of the track, but then only access one of them:
[luabox]
local rs = renoise.song()
rs.transport.lpb = rs.transport.lpb * 3
for _, pattern in ipairs(rs.patterns) do
local old_number_of_lines = pattern.number_of_lines
pattern.number_of_lines = pattern.number_of_lines * 3
for _, track in ipairs(pattern.tracks) do
for line_index = old_number_of_lines, 2, -1 do
local src_line = track:line(line_index)
if (not src_line.is_empty) then
local dest_line = track:line(line_index * 3 - 2)
dest_line:copy_from(src_line)
src_line:clear()
end
end
for _, automation in ipairs(track.automation) do
for _, point in ripairs(automation.points) do
if (point.time == old_number_of_lines) then
automation:add_point_at(point.time * 3, point.value)
automation:remove_point_at(point.time)
elseif (point.time > 1) then
automation:add_point_at(point.time * 3 - 2, point.value)
automation:remove_point_at(point.time)
end
end
end
end
end
[/luabox]
i just tried taktiks "tip"and it sure is alott faster
Well, if one would make it perfect i’d converted any LFO automations, any delays with line sync on and so on too. It get’s the job done quickly with only minor things to adjust afterwards for a specific case. This small script took me maybe 20 minutes to program which included reading the docs. Only a short pause and i was able to further work on the song, not focussing on boring corrections for lot’s of patterns because i’ve changed the LPB value. I’m really thankful for having scripting support now, which makes such small but time consuming tasks so easy to solve. 
That’s some massive speed improvement. Would’ve thought that the line implementation uses some sort of internal pointers to the correct line if it’s addressed with an index. Good tip in general to watch out for then.
Great snippet, I have a couple of songs in need. I changed the snippet into a tool for ease of access.
edit: Changed to taktiks improved code.
edit (16.11.2010): v 0.2 Added recalculation of beat synced instruments.
edit (19.03.2011): v 0.3 Improved error handling and updated for 2.7 beta (76 dl)
edit (23.04.2012): v 0.4 Version Notes:
Thanks, will be useful.
Cool. Please have a look at the optimized version (Post #8 in this thread), which avoids calls to lines and uses :line() instead. This makes a huge difference performance wise…
thanks for making this into a tool mogue but please implement taktiks snippet code,it makes it sooo much faster
Done! I updated the xrnx file in the post above.
awesome works great,thanks for making this a tool,will come in handy for sure
Yeah!! Great tool! Thanks!!
Added recalculation of beat synced instruments. (see post above for a new XRNX file)
for _, instrument in ipairs(rs.instruments) do
for _, sample in ipairs(instrument.samples) do
if (sample.beat_sync_enabled == true) then
sample.beat_sync_lines = sample.beat_sync_lines * multiplier
end
end
end
Had a crash in Moque’s LPB tool:
C:\Users\plugexpert\AppData\Roaming\Renoise\V2.6.0\Scripts\Tools\mogue.beatslayer.LPBx.xrnx\main.lua' failed in one of its notifiers.
Please contact the author (Beatslaughter) for assistance...
std::logic_error: 'automation.point: invalid point time. time must be >= 1 and <= ARenoiseLuaPattern::kMaxNumberOfLines'
stack traceback:
[C]: in function 'add_point_at'
main.lua:37: in function 'run'
main.lua:69: in function <69><br>```
</69>[quote=“Jonas, post:19, topic:30227”]
Had a crash in Moque’s LPB tool:
C:\Users\plugexpert\AppData\Roaming\Renoise\V2.6.0\Scripts\Tools\mogue.beatslayer.LPBx.xrnx\main.lua' failed in one of its notifiers.
Please contact the author (Beatslaughter) for assistance...
std::logic_error: 'automation.point: invalid point time. time must be >= 1 and <= ARenoiseLuaPattern::kMaxNumberOfLines'
stack traceback:
[C]: in function 'add_point_at'
main.lua:37: in function 'run'
main.lua:69: in function <69><br>```
<br>[/quote]<br>
<br>
This looks like you have automation data outside the pattern scope. So your pattern was longer you shortened it but didn't remove the excess data. You can solve this manually by lengthening your patterns and removing any extra automation or notes/effects before running LPBx.<br>
<br>
We could also strip out the out of scope notes and automation when using the tool. I'll check that out but you can fix this manually for now.</69>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.
thanks for the update, have used the original script a lot!
@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.