The Api Wishlist Thread

R3.3.1 Win10 x64

The API also has no way of selecting the line within the selected phrase. Something like this:
renoise.song().selected_phrase_line_index This does not exist!
Perhaps this would also be possible:
renoise.song().instruments[].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.

2 Likes

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

renoise.song().instruments[].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:

renoise.Instrument.LAYER_NOTE_DISABLED
renoise.Instrument.LAYER_NOTE_ON
renoise.Instrument.LAYER_NOTE_OFF

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

-- Mapping's layer (triggered via Note-Ons or Note-Offs?).
renoise.song().instruments[].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:

renoise.song().instruments[].sample_mappings[].read_only
when this condition is true, the API disable these options:

  1. renoise.song().instruments[].sample_mappings[].base_note, _observable
  2. renoise.song().instruments[].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:

renoise.song().instruments[]:sample_mapping_overlap_mode, observable

Replace with this:

renoise.song().instruments[].sample_mapping_overlap_mode, observable

Issue with checking values

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

renoise.Instrument.OVERLAP_MODE_ALL
renoise.Instrument.OVERLAP_MODE_CYCLED
renoise.Instrument.OVERLAP_MODE_RANDOM

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:
renoise.song().selected_instrument.sample_mapping_overlap_mode=3

*** 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 “renoise.song().selected_instrument.sample_m…”]:1: in main chunk

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

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.

2 Likes

Access to the LFO’s custom envelope.

2 Likes

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

song.transport.loop_block_start_pos_observable
song.transport.loop_block_range_coeff_observable
song.transport.loop_block_enabled_observable

1 Like

13 posts were split to a new topic: Edit Step Questions

It’s possible to select automation and show it:
rna.window.active_lower_frame=renoise.ApplicationWindow.LOWER_FRAME_TRACK_AUTOMATION
rns.selected_automation_parameter = rns.tracks[i].devices[j].parameters[k]

Maybe i haven’t understand what you want to do…

Thank you very much for pointing this out specifically! I really didn’t see it. Rather I did not try it. This matter was one of the ones that bothered me the most. Turns out it’s already well covered. Thanks a lot!

In case I have more blunders, do you know if there is a solution for the following?

There is nothing that bothers me more than claiming something that is already included.

A post was split to a new topic: I have no idea how to follow quantization

  • I would like to request a “big mono” font style for the renoise.Views.text class. For nice grids (think pattern editor), we currently only have the mono style which is kind of small.
  • It would also be quite nice to have a color property for texts. Or at least access to a few more of the theme colors. (like having vol/pan/dly colors consistent with the pattern editor in a tool…)

Simplest would be to have a color property, but perhaps you really want to avoid third party rainbow guis.

2 Likes

@joule …and vertical text (counterclockwise)

image

Primitives Vector drawing and blitter operations. Or is it already possible?

I don’t think so. IMO viewbuilder should be consistent with Renoise. I don’t think there is a single place in Renoise where vertical text is being used.

Renoise uses vertical text in the name of the tracks when they are collapsed, or in the keyzones grid. Renoise already uses vertical text!
It would be perfectly doable to have vertical text in the API as well. Quite useful for certain tools, by the way!

1 Like

Ah, correct. I think it would be abused though.

It is one more feature that you can use or not. There is nothing inappropriate here. I don’t understand what the problem is with implementing a “orientation” feature for the text. Just as you allow to change the color of the text, its style, it seems obvious that you can also use vertical text, when necessary.

1 Like

@EatMe, I know. But that’s using an image, not text. One of the main characteristics of objects is the flexibility to be modified, such as changing the text (something very common in certain window tools).

Using an image to replace text is a poor trick. I am talking about this:

-- renoise.Views.Text

-- Get/set the text that should be displayed. Setting a new text will resize
-- the view in order to make the text fully visible (expanding only).
-- By default empty.
text.text
  -> [string]

-- Get/set the style that the text should be displayed with.
-- Available font styles are:
-- >  "normal"  
-- >  "big"  
-- >  "bold"
-- >  "italic"  
-- >  "mono"
--
-- By default "normal".
text.font
  -> [string]

-- Get/set the color style the text should be displayed with.
-- Available styles are:
-- >  "normal"
-- >  "strong"
-- >  "disabled"
--
-- By default "normal".
text.style
  -> [string]

-- Setup the text's alignment. Applies only when the view's size is larger than
-- the needed size to draw the text.
-- Available mode are:
-- >  "left"  
-- >  "right"  
-- >  "center"
--
-- By default "left".
text.align
  -> [string]

--NEW! (this not exist!)
-- Setup the text's orientation.
-- Available mode are:
-->  "horizontal"
-->  "vertical"
-- By default "horizontal"
text.orientation
 -> [string]

The same new feature (“orientation, or text-orientation”) for all other objects that accept text (including the button). I really don’t understand why this doesn’t exist. At the programming level, horizontal text has the same difficulty as vertical text.

Some items really can be improved. For example, the checkbox does not accept text or change the image. An API has to be designed to be flexible. Let tool developers use it however they want, without limitations. Don’t force the LUA programmer to do devious tricks. For this reason tools appear with strange things.

1 Like

A post was split to a new topic: How can I address in an InstrumentPhrase object

I would love to have these!! Hopefully someday X)

+1.000.000.

I think tool programmers would use this feature in the most design-friendly way possible for Renoise. The most striking example is the selection of a button.

Also, if we had more control over the “checkbox” it would be very good. Allow to change the icon, allow to change the text. Avoid tools having buttons emulating checkboxes. The buttons are square. The checboxes are with circular corners. They differ graphically. In the API it is not possible!

1 Like