The Api Wishlist Thread

Yup, just like the panning slider.

Edit: Centered rotary dials would be great too. :man_scientist:t2:

1 Like

Please, please, please implement this hook. Or allow custom data to be attached to each song. This would make so many things possible that are currently either impossible or super kludgy to implement.

Pretty please. :smiley:

This indeed would be the cleanest solution for many other tools as well. I’ll see what I can do here, but unfortunately can’t promise anything.

Until then you also could, as a workaround, memorize the song’s state in the tool preferences, using the song’s abs path ( as “key”. This of course binds the tool’s song state to the local tool preferences and thus can’t be transferred when moving or sharing a song, but this could be a wanted behaviour too.


Talking about easy modifications in the API: Is it possible that you also will connect the .fxp/.aupreset export to the api? Then I could add that to the midi export tool, so you would get all the presets automatically.

Also if the render-song dialogue had a “after-action-done-trigger”, you could add some actions like encoding m4as/mp3s, without rebuilding the whole damn render dialogue.

Thanks for consideration.

Its currently not possible to get the current cursor position in sample buffer: image

I tried these, but it doesn’t work (only works with a selection):

Maybe something like this would help:

Other topic about this:

Addition of favorite/ short name name to loaded device properties:

Currently for plugin infos you can access:

[favorite_name]=> Driver
[is_bridged] => false
[is_favorite] => false
[name] => Native Instruments GmbH: Driver
[path] => Audio/Effects/VST/Driver
[short_name] => Driver

From a loaded device you can only get:

[name]=> VST: Native Instruments GmbH: Driver
[display_name]=> VST: Native Instruments GmbH: Driver
[device_path]=> Audio/Effects/VST/Driver

Would be great to have [short_name] at least for a loaded device. The main reason being that even though it is fairly simple to strip out the “/” or “:” to get the short name, I ran into a situation with the tool linked below, where cross platrorm you can have differences in name format. Just running into this again with a tool I’m working on and it creates some guessing + what seems like unneccesary extra formatting mess.

Audio Units seem to have the different formatting:


Edit: although having short_name for loaded device would be great, there is also a bug with device_path:

Turns out to be not-a-bug, but leaving link as useful:


New widget for tool GUIs. It’s already present in renoise sampler so a consistant addition and would be a great place to store options/ lesser used functions.


menu button

Ability to switch ‘Only’ button on and off in the automation list. Would fix an annoyance in my Automation Single Slider tool.

only button

Also, we can select the middle view to be modulation with: =

But would be great to be able to select the lane underneath too:

Vol Pitch Pan

R3.2.4 Win10 x64. (Renoise.Song.API.lua)
The following property is not available: .is_maximized

Need to add:[].sample_modulation_sets[].devices[].is_maximized, _observable

Edit: This has been fixed in R3.3.0.

-- Maximize state in modulation chain.[].sample_modulation_sets[].devices[].is_maximized, _observable
  -> [boolean]

R3.2.4 Win10 x64. (Renoise.Song.API.lua)
The following property is not available: .display_name

Need to add:[].plugin_properties.plugin_device.display_name, _observable

Edit: It has not yet been added in R3.3.0.

R3.2.4 Win10 x64. (Renoise.Song.API.lua)

An _observable property is required to indicate that a new instrument VST plugin has been loaded.[].plugin_properties... ...

Edit: This has been fixed in R3.3.0.[].plugin_properties.plugin_device, _observable
 -> [renoise.InstrumentPluginDevice object or renoise.AudioDevice object or nil]

R3.2.4 Win10 x64. (Renoise.Song.API.lua)
The following property is not available: .target_value ((it’s a proposal, or “target_input”))[].sample_modulation_sets[].target_value, _observable, _observable

Currently there is no way to select tabs: Volume, Panning, Pitch, Cutoff, Resonance, Drive

Doc related


– Where the modulation gets applied (Volume, Pan, Pitch, Cutoff, Resonance).[].sample_modulation_sets[].devices[].target
-> [read-only, enum = TARGET]

Related issue:

Edit: It has not yet been added in R3.3.0. In fact, this matter is quite important. It makes the previous selection of the target impossible to later insert a device from the tool, as well as the navigation between the targets.

R3.2.4 Win10 x64. (Renoise.Song.API.lua)
The following property is not available: .mode[].sample_modulation_sets[].devices[].mode, _observable

The property appears in the documentation, but it is not available internally in the API.

Doc related

– renoise.SampleVelocityTrackingModulationDevice (inherits from renoise.SampleModulationDevice)

--------- Constants


-------- Properties

– Mode.[].sample_modulation_sets[].devices[].mode, _observable
-> [enum = MODE]

– Min/Max velocity.[].sample_modulation_sets[].devices[].min
-> [renoise.DeviceParameter object, 0-127][].sample_modulation_sets[].devices[].max
-> [renoise.DeviceParameter object, 0-127]

Edit: This has been fixed in R3.3.0.

-- Mode.[].sample_modulation_sets[].devices[].mode, _observable 
  -> [enum = MODE]

R3.2.4 Win10 x64. (Renoise.Song.API.lua)
The following parameter is not available: .model

The track devices Analog Filter and Digital Filter return 5 parameters, including the filter type. But the filter model is missing (do not confuse “type” with “model”). It is necessary to be able to change the model parameter from the API to have full control of these two devices.

Doc Related[].devices[].parameters[] (for Analog Filter and Digital Filter)

Note: a parameter does not need to be automatable to be controllable from the API, even from MIDI routing. At least it would be nice to be able to access and change the value of this parameter on both devices.

Edit: It has not yet been added in R3.3.0.

Access to the instrument parameter on the meta instrument devices would be nice here[].devices[].parameters[].

Also registering, unregistering and reading midi mappings that bypass the traditional renoise midi-mapping dialog would be handy. Currently there’s just that bool return for is_midi_mapped. Even with duplex there is still the ‘manual’ mapping part. There could be some pretty clever dynamic mappings as a result of rapid unmapping, mapping.

R3.2.4 Win10 x64. (Renoise.Song.API.lua)
The API has no way to select the automatable parameter in the automation editor to display the envelope window. It would be great to have this function: :open_envelope_automation()[].devices[].parameters[]:open_envelope_automation()

Doc related

    -- Set a new value and write automation when the MIDI mapping
    -- "record to automation" option is set. Only works for parameters
    -- of track devices, not for instrument devices.[].devices[].parameters[]:record_value(value)

    -- Not valid for parameters of instrument devices. Returns true if creating
    -- envelope automation is possible for the parameter (see also
      -> [read-only, boolean]

    -- Is automated. Not valid for parameters of instrument devices.[].devices[].parameters[].is_automated, _observable
      -> [read-only, boolean]

    -- Returns the automation for the given device parameter or nil when there is
    -- none.[].tracks[]:find_automation(parameter)
      -> [renoise.PatternTrackAutomation or nil]

For example, the action of this function would be exactly the same as pressing the button marked in the screenshot, for the associated parameter. In this case it would be the first parameter of the device.

Or, at least select the parameter in the automation editor (without opening the automation editor), so that it displays the associated envelope: :select_envelope_automation()[].devices[].parameters[]:select_envelope_automation()

The latter would be better.

Edit: This is already covered

– Selected parameter in the automation editor. Can be nil.
– When setting a new parameter, parameter must be automateable and
– must be one of the currently selected track device chain., _observable
– Example:

Thanks to @KanetonKiller for reporting on this!


R3.3.1 Win10 x64

The API also has no way of selecting the line within the selected phrase. Something like this: This does not exist!
Perhaps this would also be possible:[].phrase_playback_pos (with “phrase index” and “line index”) This does not exist!

This matter has been highly demanded by various forum members in recent years.

1 Like

R3.3.1 Win10 x64

I’m not sure about this but the API also not has a way to switch between Note-On Layer and Note-OFF Layer. Something like this[].layer_note This not exist!

It is not possible to change both panels, but it is possible to detect which layer the selected sample belongs to:


-- Access to a sample mapping by index. Use property 'sample_mappings' to
-- iterate over all sample mappings and to query the sample (mapping) count.[]:sample_mapping(layer, index)
  -> [renoise.SampleMapping object]

-- Mapping's layer (triggered via Note-Ons or Note-Offs?).[].sample_mappings[].layer, _observable
  -> [enum = renoise.Instrument.LAYER]

Most of the entries I add in this thread have to do with visual access to the panels.
In general, if the API does not allow the visual change of a specific panel, it is not possible later to select any element that is inside it, losing control from the tool. There are the Note-On Layer & Note-Off Layer panels within the Keyzones or the selection of Vol-Pan-Ptc-Cut-Res-Drv within the Modulation.

On the other hand, if the API does not allow the selection of an object, parameter or member of a list, control is also lost from the tool. There is the lack of selection of the parameters in the list of the automation editor, or the selection of the current line within the phrase editor

Sorry to insist on it, but it does not make much sense to have access to the change of a multitude of parameters from the API, if you do not previously allow the quoted selections or similar.

In general, almost everything is covered. But there are some details that “are not wishes” to fill this forum, they are things that are really lacking for consistency within the API. They are not new features. They are things that really should be available. Since they are not available, there are other things in the API that are available that cannot be used because they depend on the above to really have control.

R3.3.1 Win10 x64

Inconsistency in the API:[].sample_mappings[].read_only
when this condition is true, the API disable these options:

  1.[].sample_mappings[].base_note, _observable
  2.[].sample_mappings[].note_range, _observable

This should not happen. base_note and note_range should still be available to be able to create distribution functions (as custom Drum Kits) within keyzones when slices exist.

Switches activated

On the other hand, these two switches should appear deactivated:

Documentation error:[]:sample_mapping_overlap_mode, observable

Replace with this:[].sample_mapping_overlap_mode, observable

Issue with checking values

Also, I think the API wrongly checks the values of:


The values are compared with 1, 2 and 3, when it should be 0, 1 and 2.

You can check it in the terminal by printing:

*** std::logic_error: ‘invalid overlap_mode enumeration value ‘3’. valid values are {OVERLAP_MODE_ALL = 1, OVERLAP_MODE_CYCLED = 2, OVERLAP_MODE_RANDOM = 3}.’
*** stack traceback:
*** [C]: ?
*** [C]: in function ‘__newindex’
*** [string “do…”]:22: in function <[string “do…”]:9>
*** [string “…”]:1: in main chunk

It would be nice, when you could create simple menus like this for own tools:

As far as i can seen, i need to create an extra dialog for this. Which is kind of complicated. I just need something like “vb:menu” :slight_smile:

Also please add a “vb:scrollbar” so we don’t need to use a slider for this.

1 Like

Access to the LFO’s custom envelope.


Missing observable for loop block variables. I currently use a simple compare in idle function as workaround:


1 Like