I’m not doing something really smart here with the track notifiers (removing and then recreating one and after that calling a routine that recalls the track index updater).
But aside from that, this does cause Renoise to freeze.
In the attached tool-example, simply rename a track and see what i mean.
Perhaps we also need some mechanism to prevent deadlocking the notifier routines.
I attach a notifier to each existing track for name changes, including the master.
Hey,
what happens is:
“get_track_index” is the notifier that is called on track name changes, but get_track_index also removes itself as notifier, then adds itself as notifier again. Basically it adds itself again and again to the notifier chain while getting notified. This is where it freezes.
The current script freeze checks are not clever enough to handle this. In general they do check notifiers a well. I’ll try to somehow catch such problems a well.
A quick fix would be to change:
if song.tracks[t].name_observable:has_notifier(update_track_names) then
song.tracks[t].name_observable:remove_notifier(update_track_names)
end
song.tracks[t].name_observable:add_notifier(update_track_names)
to
if not song.tracks[t].name_observable:has_notifier(update_track_names) then
song.tracks[t].name_observable:add_notifier(update_track_names)
end
or doing the notifier attaching somewhere else, outside the notifier.
also stumbled upon a small bug (main.lua:376):
if not table.is_empty(device_table) then
should be
if (#device_table > 1) then
The “none” entry seems always present in device_table, so having no device entries will fire an error with “note_map_dialog_vb.views.device_list.value = 2”
I knew this happened, but considered Renoise should not hang so therefore decided to report it anyway.
Thanks for the find, i forgot to change this indeed.
I hope i get this thing finished next week…