Fixed Lua API issues are marked with [Fixed B6] in this forum.
Beside of the fixes there is:
[added b6] renoise.song():describe_undo(description)
Add a custom description for Renoises undo/redo (e.g: Undo “my tool did something”)
[added b6] renoise.song():render([options,] filename, rendering_done_callback) and friends
interactively render sections or the whole song from scripts/tools
[added b6] renoise.song().tracks[].devices[].parameters[].is_automatable
check if renoise.song().patterns[].tracks[]:create_automation is possible for this parameter
[added b6] renoise.song().instruments[].midi_properties -> [renoise.InstrumentMidiProperties object]
complete interface to what Renoise uses as “MIDI instrument”
[added b6] renoise.song().instruments[].plugin_properties -> [renoise.InstrumentPluginProperties object]
nearly (alias handling missing right now) complete interface to what Renoise uses as “Plugin instrument”. Includes changing plugin parameters, opening/closing external editors and so on
[added b6] renoise.Views.Control and control.active
which lets you deactivate (make read-only without removing) views which change something (Sliders, Number Boxes and so on)
[changed b6] texts next to a vb:checkbox will now automatically toggle the value of the checkbox:
So far you had to click with the mouse directly on the checkbox in views like: vb:row{ vb:checkbox{}, vb:text{text=“Click me!”} }
“Click me!” will now also control the checkbox. If you don’t want that (for whatever reason), then add something else between the checkbox and the text in the row (a space, another row, …)
tools: menu entries from tools are no longer separated by extra divider lines in context menus, which saves a bit of space in the menus
scripting editor: will try to autodetect UTF-8 files now (always saves in UTF8)
scripting editor: find and replace options moved to the find panel. Added a new find/replace “whole words only” option
Please have a look at the updated documentation files (in the Renoise XRNX repositories or the ones that are installed with Renoise) for more details.
I think API wise we are now more or less done for this release. Well, what this release focuses on: offline data manipulation & custom UIs & MIDI controller stuff.
Some more finetuning will be done in the next betas, but I think we should slowly come to an end. 2.6 will for sure not be the last Renoise and thus also not be the last Lua API update. If you miss some non real-time things urgently in the API, let us know soon please and let’s discuss…
[added b6] renoise.song().instruments[].plugin_properties.external_editor_visible
-> [boolean, set to true to show the editor, false to close it]
-------------aswell?---------------------->
renoise.song().devices[].plugin_properties.external_editor_visible
-> [boolean, set to true to show the editor, false to close it]
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
. I love it and I promise there are good things to come