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
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.
- 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
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
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
Seriously! This bugs me a lot with existing tools; that all controls must be square… I wish we could create switches like these:
I feel these are much more visually pleasing than square buttons everywhere, and I would expect them to not be very hard to expose to the Lua API 
1 Like
R3.2.1
The observable for .loop_block_enabled is not available:
renoise.song().transport.loop_block_enabled_observable
The observable for .loop_block_range_coeff is not available:
renoise.song().transport.loop_block_range_coeff_observable
renoise.song().transport.loop_pattern, _observable
→ [boolean]renoise.song().transport.loop_block_enabled
→ [boolean]
renoise.song().transport.loop_block_start_pos
→ [read-only, renoise.SongPos object]
renoise.song().transport.loop_block_range_coeff
→ [number, 2-16]
Apparently it’s the only missing transport states.
Access to the XYPad’s Auto Reset toggle and value parameters (as a device, not a GUI element).
1 Like