Hey Taktik,
great additions and fixes. Will check Beta 6 out ASAP. Regarding 2.6 in general: so far I could implement almost everything (including support for bidirectional fader automation read/write etc.) as I’ve planned by using the scripting framework. It’s absolutely useable, awesome and quick. Really great job man 
. I love it and I promise there are good things to come.
Also good to hear that the editor got improvements. I used it quite intensively during the last weeks and it really does the job very well for me. Only thing I missed was an outline-view for functions/properties. For bigger files/classes that would be a killer feature. Anyway: I love that the editor it is so tightly integrated in Renoise 
A really urgent thing to clarify for me was the explicit creation of undo/redo-data. I have an important design question here
and I want to discuss this by example of my current FaderPort code (hope it’s not too realtime-related):
I handle incoming fader values from the FaderPort right now in two ways:
- I set the device parameter values (prefx_volume etc.) directly
- I record the values into an automation envelope
In first case there’s the problem that it just doesn’t make sense to create undo-data for all intermediate fader positions.
Only for the final release position after all movement. But that’s exactly the problem: this can not be detected automatically, right ?
An explicit event like “mouse button released” or “fader untouched/released” is necessary to trigger the creation of the undo-data.
But I couldn’t find a function for explicit undo-data creation in the framework. Is there maybe a function planed for another beta release ?
Another design question: how to handle undo-data creation of controllers if the controller doesn’t support an explicit “released”-event.
(e.g. a fader without touch-functionality) ? How to detect the that undo-data shall be created ? Using time measurement, maybe ? How does e.g. duplex handle this ?
UPDATE 13.9: checked out B6 and now the Undo works as expected. BUT: now are all intermediate fader positions are implicitly stored in undo-Queue as mentioned above. This means: every time I move my fader the undo-Queue is polluted by lots (and I mean lots !!) of entries. I really think an explicit function is necessary.
Suggestion for a function to switch on/off undo data creation:
set_undo_data_creation(UNDO_ON) -- default
set_undo_data_creation(UNDO_OFF) -- if needed for realtime / faders
-- example pseudo code
while movement do
if fader_touched do
set_undo_data_creation(UNDO_OFF)
deviceparameter.value = myvalue
else
set_undo_data_creation(UNDO_ON)
deviceparameter.value = myvalue
end
end