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.
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 renoise.song().patterns[]:add_line_notifier(func[, obj])
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.
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.
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
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.
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.
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.
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 }
vb:envelope{
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
end
}
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 renoise.song().sequencer.pattern_slot_mutes_observable. It will work, but it’s a bit complex. If it would return an event table, that would be great.
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.
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.
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.
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.
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.
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.
A single, multiple or all columns at once, note and/or effect columns can be changed within one single operation and thus will result into one notifier call too. That’s why the notifier can’t provide that info.
I see where this suggestion comes from though. You need this for this tool here, don’t you? New Tool (3.1): FormulaOne
Then you’d actually need a different kind of notifier: One that only fires, when the user directly enters or records a new note or effect column value. Right now the notifier will also be called when cut/copy pasting, doing something in the advanced edit, on undo and redo and when other tools write into the pattern. Those are all scenarios where you don’t want to apply your formulas. If you do, you’ll actually will start breaking those other changes.
