Hi there,
I want to reset the FaderPort controller (reset light states and so on) whenever Renoise is quit by the user.
Unfortunately I couldn’t find any observable for that.
Or could I use a deconstructor ? Since there is an __init() function for object instantiation is there some standard method for destroying / cleanup the object ? I know LUA has the garbage collection, but maybe there’s something called implicitly ?
For Duplex you should overload “MidiDevice:release” , just like the launchpad does:
function Launchpad:release()
TRACE("Launchpad:release()")
self:send_cc_message(0,0)
MidiDevice.release(self)
end
This will reset the controller when duplex closes, but also when stopping the controller within duplex.
thanks Taktik 
,
but unfortunately I’ve to admit that I don’t integrate into Duplex at the moment. Right now it’s a standalone tool.
It’s not that I don’t like Duplex, but for different important reasons it just didn’t make much sense for me to integrate.
I’ll release the FaderPort soon, and I guess then you will see what I mean.
So what exists aside Duplex for Release/Destruction ?
Hi,
setup:
for my FaderPort driver I open a midi I/o device, in __init()
Moreover I listen to various events from the currently opened song (various observables.
Now, if the song changes (new song/load song), the song object is in a transition state, and the old song object gets invalid.
The problem:
During those transition midi events can be received, which lead to actions which access the old invalid song.
And this leads to unwanted errors.
right now it seems that it’s only possible to observe the creation of new songs via renoise.tool().app_new_document_observable.
But I need to know the moment when the old song is beeing released and gets invalid.
I would ignore midi messages or close the midi device in this case in order to avoid problems.
So, is there already support that I have overseen ? otherwise this would be a feature request.
Theres no such thing yet, there only is:
renoise.tool().app_new_document_observable
but when the notifier is called, renoise.song() already is the new song and the previous song already is dead, invalid.
To allow scripts to release themselves from a song, something like:
renoise.tool().app_release_document_observable
could work.
renoise.song() would here still point to the old, but still valid, about to be trashed song.
I don’t like the name “app_release_document_observable”. Has anyone a better idea?
Hey, nice 
IMHO “app_release_document” is not too bad. It’s a good counterpart to app_new_document
But since you’re observing the application for events “new document”, “pre-release document”:
What about combining that to: app_document_state_observable ?
E.g. events could be: