local rns = renoise.song
local a = rns().transport.loop_sequence_range[1]
rns().transport.loop_sequence_range = {rns().transport.edit_pos.sequence, rns().transport.loop_sequence_range[2]}
print (a)
if rns().transport.loop_sequence_range[1] == a and rns().transport.loop_sequence_range[1] == rns().transport.loop_sequence_range[2] then
print (rns().transport.loop_sequence_range[1])
rns().transport.loop_sequence_range = {0, 0}
print (rns().transport.loop_sequence_range[1])
else
end
Run that in a Testpad where you have only a single pattern set to loop within the Sequence.
What do I expect to happen? Say you have the 5th pattern currently set to loop and are in the 2nd pattern when you execute it.
Patterns 2-5 set to loop.
Terminal prints: 5 | 2 | 2
What actually happens?
Patterns all removed from loop status.
Terminal prints: 5 | 5 | 5
That clearly makes no sense!
I can bodge it using os.clock and a While Loop but feel that is very bad practice. Sorry for kinda cross posting but I felt this deserved it’s own thread in the API area, rather than the thread in Ideas and Suggestions that brought life to the tool snippet.
Heh, it gets really weird too… Don’t know what’s up with this:
--SETUP
local rns = renoise.song
local function clear_loop()
rns().transport.loop_sequence_range = {}
end
local function print_array()
rprint(rns().transport.loop_sequence_range)
end
local function print_values()
print(rns().transport.loop_sequence_range[1])
print(rns().transport.loop_sequence_range[2])
end
local function delay(delay_sec)
local now = os.clock()
while now > (os.clock() - delay_sec) do end
return true
end
--"MAIN"
--clear
clear_loop()
--DELAY A
--delay(1)
--set
rns().transport.loop_sequence_range = {1, 2}
--print_values()
print_array()
--DELAY B
--delay(1)
if rns().transport.loop_sequence_range[1] == 1 then
print("SUCCESS")
else
print("fail")
end
This clears the loop sequence range, sets it again at {1,2} and then tests for the start value. If it’s 1, the output is “SUCCESS”. If it’s something else (meaning the loop values weren’t set properly), the output is “fail”).
Ok. When I try commenting and uncommenting delays A and B I get:
neither active = SUCCESS
delay B active = SUCCESS
delay A active = fail
both active = SUCCESS
The weirdness is that both cases 1) and 4) produce SUCCESS. And that the results seemed fully consistent.
–EDIT
The second weirdness is that the print_array() output will be INCONSISTENT with the “SUCCESS”/“fail” output. Wow.
–EDIT
INCONSISTENT in the above meaning that sometimes the print_array() output will match the SUCCESS/fail output, and sometimes it won’t.
You get the SUCCESS on both Active as it’s not reading the clear_loop() function in time either, so it’s taking the values from the end of the last round. If you physically selected a different sequence loop selection you should find that one fails also.
Glad I’m not the only one to think this very strange! This is what I’ve gone for currently, using a value as small as possible to still seem to give me consistent results.
local rns = renoise.song
local timer = os.clock()
local a = rns().transport.loop_sequence_range[1]
if a == 0 then rns().transport.loop_sequence_range = {rns().transport.edit_pos.sequence, rns().transport.edit_pos.sequence}
else rns().transport.loop_sequence_range = {rns().transport.edit_pos.sequence, rns().transport.loop_sequence_range[2]}
while timer > (os.clock() - 0.01) do end -- BODGE THAT SHOULDN'T BE NEEDED!!!
if rns().transport.loop_sequence_range[1] == a and rns().transport.loop_sequence_range[1] == rns().transport.loop_sequence_range[2] then
rns().transport.loop_sequence_range = {0, 0}
else
end
end
Assume it can be nothing to do with the GUI thread tool run in??? Change the values in the timer bodge to around 0.006 and you will find it sometimes gets it correct, sometimes doesn’t, and that is far faster than refresh rate! Hopefully somebody can spread some light…
