The Api Wishlist Thread

(ffx) #241

It should, yes, if the device you’ve targeted is a plugin.

Ok then AFAIS, is missing then!

Also the same for banks would be so l337. Also I would like to use save for the midi export tool, extending it, so it also automatically saves all dsp fxp into subdirs… Lot of scenarios where this would be l337.

(ffx) #242

Is it possible that you add an event for manipulating the song xml data, after loading a song, just before it will be converted to the internal binary song?

This because there are still annoying cross-compatibility plugin naming problems, Renoise matches by filename instead plugin id, so exchanging songs cross-platform, e.g. mac<->windows will lead into various “plugin not found” issues, and fixing them all the time manually is a workflow mess.

I can understand that you don’t want to change this for sake of backwards compatibility, but can you add such an event, so we can build a fixer tool by ourselves?

Plugin examples: rob papen, mda, melda, basically everything with “_x64” on Windows. Also sometimes vendors switch filenames in later versions, like melda, tal etc. etc.

(joule) #243

Add a line notifier that will also return the original line and the changed line. This line notifier could be separate from the current simple notifier that only returns the changed pos.

Point being that we can then do a comparison and know exactly what has been changed - and from what value.

So, a sibling to[]:add_line_notifier(func[, obj])

(joule) #244

If possible, the following addition would be quite invaluable for implementations relying on extending renoise classes with custom properties:

  1. Each object having a property that return its “parent” object

example: lines[12].note_columns[1].parent_line --> lines[12]

  1. Objects that are part of lists having a property returning its index in the list.

example: lines[12].index --> 12

This would expand the use of custom properties vastly. Trying to identify a specific note_column by iterating and searching (rawequal) is simply too ineffective. For track objects it’s OK, but not when going deeper into the song.

(ffx) #245
  • Get current shortcut key of a shortcut as text. So you could print the shortcut on a button or on mouse hover etc.

  • Define own keyboard focuses for tool windows, so you could reuse/overload existing shortcuts, only if the tool window is focused

(joule) #246

It would be super convenient if _AUTO_RELOAD_DEBUG also made the tool reload when included (required) files are being updated from an external editor. It only seems to work on main.lua in this scenario.

(danoise) #247

It would be super convenient if

I’ve probably spent a whole day moving my hand to the mouse, then moving the mouse to the Tools menu and then clicking “Reload all Tools”.

So yeah! It’s not trivial to implement, though.

(joule) #248

Here is a proposal for a “very simple” way to implement saving of custom data together with songs. E g, no need for weird pollution of native Renoise classes.

Let’s say that the song name is my_song.xrns

  1. Make it possible to store something in os.tmp() path as my_song.ID*.xml. Anyting matching that filename pattern will automatically get zipped and included when saving .xrns files. ID can be anything, but it’s advisable to use the tool name.

  2. Add renoise.tool().app_ saving _document_observable to allow the user to serialize and dump his/her data into os.tmp file right before saving the song.

  3. Whenever a song is loaded, any files within the xrns zip matching my_song.ID*.xml will get dumped into os.tmp. It’s now up to the user to load/reload and interpret it (app new document observable is the friend).

Simple and relatively straight forward? Also feels clean and consistent imo.

(taktik) unpinned #249

(Ledger) #250

A request for adding renoise envelopes, ready-to-go via viewbuilder.

It would be a secondary window, so in the script gui it would appear simply as a button with your own custom text. Press the button and you get a similar renoise ‘Ext.Editor’ envelope window ready to go, linked to your script.


All values are accessible via a table values with multiple fields { position, value }

  button_text = "My Envelope",
  length = 65,
  values = { {3,0.4},{15,0.03},{23,0.7},{26,0.4},{58,0.5}}
  notifier = function(values)
               --do stuff with values table here    


(joule) #251

One thing that is just lacking, is an observable for slot mute states.

I understand that you want to separate “slots” from “patterntracks”, and keep the mute states in the sequencer slots. But maybe you can provide some ad-hoc banger as renoise.PatternTrack.muted_observable ?

(I was about to make a tool that makes the mute state auto-collapse patterntracks, but it turns out I would have to observe all sequence slots with an idle notifier. No go…)

EDIT: Found a workaround using It will work, but it’s a bit complex. If it would return an event table, that would be great.

(Achenar) #252

Would be nice if the ViewBuilder could create progress bars and also allowed certain text to be set brighter (like in the Render dialog).

(joule) #253

Do you mean the bolder text in headlines? (only different text i can find there)

If so, that’s done with vb:text { font = “bold”, text = “My text” }

Yeah, regarding progress bars, there is no native class available and you can’t reconstruct the native one 100%. But it’s quite easy to make your own, that perhaps will look even nicer. For the progress indicator I’d use a button and alter its width dynamically.

(Achenar) #254

Nope, I just meant turning the text from grey to white (or whatever the equivalent is in the current theme) regardless of whether it’s bold or not.

(joule) #255

Ah I see it…

+1 for text colors. I’ve been missing this as well.

(Raul (ulneiz)) #256

The font color has been requested on many occasions. In addition, I would also ask for the orientation of the text, horizontal or vertical. In the end, the needs are very similar to the CSS3 capabilities. It could be something like that:

text.font_color= {xxx,yyy,zzz} (if this is not defined, it will take the default color).
text.font_orientation= “horizontal” (default) or “vertical” (vertical is turning 90º counterclockwise).

font_color could be applied to multiple objects of the ViewBuilder, in addition to the “text”.
font_orientation should be available at least for the buttons, text, multiline_text, textfield…

Ideally, both would be available in all objects where you can enter text.

Maybe these characteristics are to deepen a lot. Before this, I would request other more urgent compatibilities, such as differentiating between the right, left and middle buttons of the mouse, the possibility of combining these clicks with the CTRL, ALT, SHIFT and its compound variants, the sliders / minisliders for panning and things like that.

Really the list would not be very long. Basically it is to complete what is already missing. For me, the most serious thing is that there is no “released” for the keys of the USB alphanumeric keyboard (why?) And that the OSC does not send note editing messages (note_on, note_off) with the window of the instrument editor unpacked (It’s a behavior that does not make sense). Most of all these requests have to do directly with peripheral control.

(Raul (ulneiz)) #257

Regarding this, you can do pretty attractive things with the layer overlay (row with spacing = -xx) and the visible property. In this way, it is possible to add superimposed text when the horizontal progress bar (the button) reaches a minimum width value (or things like that), or manipulate the text itself of the button according to the width, change its color, etc., overlay buttons so that the superior can also move (or even transform a slider into buttons superimposed with their own colors) … All this can be done, but it is good to comment because there are no instructions anywhere.

(joule) #258

My own stance is that devs should keep ViewBuilder visually compatible with the rest of the Renoise GUI. Other than the extra dev time for special features (guessing that viewbuilder classes are somewhat easily recreated from native gui classes), it’s also a good point that users aren’t encouraged to do christmas tree GUIs that don’t really make sense UX wise. I’m a firm believer that restrictions are good in that way.

But some native things are missing indeed.

(Raul (ulneiz)) #259

Yes, in fact I would request direct access to the colors of the themes, in order to better integrate the most creative tools to the colors used in the theme that the user is using. For example, if you create your own checkbox, it will have a different color to the theme used. Things like that.

Currently, it is necessary to juggle to read these data from xml files and at the same time they are multiplatform, that is, compatible with windows, mac, linux, because the reference xml file is in a different route. And if the user changes the theme, the colors will not be updated until Renoise is restarted.

I think the issue here is to allow broad creativity to the programmer. He will already adjust what is necessary, but that is direct to do with the API, not inventing strange functions.

But I am aware that there are priority things, such as those I have described before. So I hope they get better this characteristics before tackling these more secondary things.

(joule) #260

There is currently no way of knowing what note was entered in a pattern with the line_notifier (without comparing the pattern to a constantly updated cache).

It would be very nice if the line_notifier event would include some kind of column index. I suppose that sub_column_type and column_index would suffice (column_index being either of a note_column or effect column index).

Using selected_note_column_index doesn’t work, since it will not be correct if the pattern was edited by cut&paste of track/pattern, or from a script.