here’s what im thinking:
a 16 row pattern
when notifier detects that you are at the 16th row, it mutes a specific (user-defined) channel for the next repeat of the pattern. when the notifier then returns to the 16th row on the “muted loop”, it unmutes the channel.
i seem to remember notifiers being fairly hairy (at least for me), so just thought to come here and ask if this is feasible?
if that is possible, is there then some way of counting how many times a notifier is hit, i.e., so i could say “only unmute this channel after 3 muted plays of the pattern” kind of thing?
You can hook something to the renoise.song().transport.play_pos_observable
There is no notifier for e.g. playback_pos in lines or in beats, so what you can do is renoise.tool():add_timer(func, cycle_ms) and have the function func lookup whether you’re at line 1. Then you only got to worry still about the possibility (dependent on the amount of ms between calls, your song bpm, lpb) that it gets called two times or more in line 1. So at this moment it probably wouldn’t be very precise, but this code should get you something:
local t
function track_mute_switch()
if t == nil or t < (os.clock() - (60/renoise.song().transport.bpm)) then
if renoise.song().transport.playback_pos.line == 1 then
print "YAY! Time to switch here"
-- switch track on/off
t = os.clock()
end
end
end
renoise.tool():add_timer(track_mute_switch, 50)
Now, you probably want to only do the “add_timer” under specific circumstances, namely if playing and a certain option is set to ‘on’. Of course where the commented line sits you gonna put code that actually does this muting, also you want the print statement out.
The t var keeps a os.clock value to guard that the track muting does not occur twice in passing line 1 once, that would quickly mute/unmute with just 50 ms in between.
DISCLAIMER I haven’t tested this code it was typed on my eee pc 701 which has a too low screen resolution to run renoise! That’s how much I care
You could try looking into the pattern notifiers. I think they retrigger when the pattern changes to itself (with pattern looping), but I can’t remember off the top of my head.
It would mean that the trigger occurs on line 1 though, and depending on how fast the script responds, a small piece of audio from the “to be muted” track may get through.
How did that Tool that played a pattern in reverse work then? I always assumed it was playback_pos_observable… Guess it could be done with timers and calculating the time for a line. Should maybe try search it our and actually have a look…