Based upon this topic Audio Track Recorder ? i simply was fumbling a bit with the sequencer notifier.
It got me this far that i can simply toggle the sample recorder function if the same index is being played again in the following round and the next round it is being turned off:
[phpbox]
renoise.tool():add_menu_entry {
name = “Sample Editor:Set auto Record…”,
invoke = function() set_notifier() end
}
local start_index = renoise.song().selected_sequence_index
function set_notifier()
print(“Setting notifier”)
print ("Edit mode = "…tostring(renoise.song().transport.edit_mode))
function toggle_sample_record()
print (“Notifier triggered”)
print (“current index:”…tostring(renoise.song().selected_sequence_index))
if renoise.song().selected_sequence_index == start_index then
print (“Restart recording”)
renoise.song().transport:start_stop_sample_recording()
end
end
[/phpbox]
It would be nice if the renoise.song().selected_sequence_index_observable also triggered an event of one sequence position is looped. Now i need at minimum two sequences to get this going. I can always add a little count-in pattern in front of it, but perhaps not always the purpose.
If renoise.song().selected_line_index was an observable you could trigger recording when the index becomes 0. This will be useful for other scripts too. And start/stop should also be observable. renoise.song().transport.playing will also be a good place to observe. This way we can have some pretty dynamic scripts.
I was toying with the idea of a grid based sequencer for live beat improvisation that would write note data in various tracks as the song plays along. Not being able to observe the things mentioned above makes it hard (or impossible?) to implement.
So yeah, having these in a future API version will be a blast.
Selected_line_index is i guess something that might cause a deadlock on the scripting engine… (try imagining someone playing a song with 600bpm and 64 lpb).
It could be useful, but the mere stuff is hard to get done realtime with scripting and most likely for real-time efficiency, selected_line_index as observable will probably has a very limited use.
I understand and CPU load was exactly why I thought this was left out in the first place. But still, having the opportunity would be nice. I assume this was tried during development though? Perhaps Taktik could shed some light why it was dropped?
P.S. Sorry if I’m hijacking the thread. Won’t happen again, promise.
The start/stop observable, because of laziness (are still in my TODO queue). The playback line_index because you actually can not do much with this in scripts. Scripts can not intercept the real playback position. Scripts are running the UI thread, not in the player, so the results are not reliable, are more like a “recent playback pos”.
This is also the reason why the record like VV wants it will never be reliable. You’d have to hack the player to do this, but we won’t have scripts in the player in 2.6.
