The title says it all. Please post only stuff that you know is not possible at the moment and where you don’t know if it will be possible in a future release (don’t post realtime dsp stuff, for example)
Okay, I’ll start:
Attach custom events to view objects (e.g. clicking a text label, dragging a button, right-clicking a slider)
– +1 for rendering!! I was thinking about something that renders the song then generates a spectrogram… and if you really wanted to, I think you might eben able to create a track freezing plugin with that (!)
– Mouse input, in relation to the dialog, in screen coordinates and as raw movement (ie. if you move the cursor to the right screen edge but keep moving it still registers that movement, even though the cursos position doesn’t change)
– Hooks for keyboard input (like when you’re in a text field and press “up” or “down”, allow scripts to catch that and act on it)
– OpenGL, and I’m not joking. There is no contest between 2D and 3D drawing speed wise, 3D is about a billion times faster, and uses a lot less CPU, generally/crossplatform speaking. I realize that it would be overkill for most and would STILL require pixel perfect 2D drawing. However, if that could just be plugged in so to speak, I think it would be a really good idea. Let the scripts create their own helper functions, “just” provide access to the OpenGL API.
– A way for plugins to share scripts and data. Maybe that prefix could be used? blah.bluh.pluginname is the convention anyway, so blah.bluh could be the name of the folder where each plugin developer can put “their stuff” (common functions you use all the time, a logo for the about menu, whatever). Or would that invite sloppyness and accumulation of crud?
– Envelopes as a standardized GUI element. It doesn’t have to be extremely powerful, just what the current envelopes do, plus a vertical edition. If possible, make them all inherit from the same code, so that if they get be improved and all plugins and Renoise sections that use envelopes benefit from that automatically.
I don’t think that this would make drawing from a script faster. The bottleneck is not the Renoise software rendering engine, but Lua. C++ is orders of magnitude faster than Lua, and calling all those OpenGL functions directly from Lua would require a LOT of conversion from Lua types to C++ types (which is slooooow).
It turns out text input fields actually bypass the key handler completely. In a way this makes sense to not “bother” the dialog with it, but I still think it’s needed… and I’d also like the ability to register a keyboard handler for individual inputs without having to write a big function which handles them all… basically, everything that can have focus should have its own optional keyboard handler.
Well, as far as the discussion goes about input fields, there might be coming at least a trick to force focus on specific fields.
Based upon my nagging for having consequent input focus on the text-field in the chat script. (You can still type if the field has no focus and it ends up there, but try to make capitals or punctual signs that require a shift-key combo etc.)
No doubt it should probably come with a tab / shift-tab to browse through these controls.
(Rubberband has a --timemap feature which expects a text file with two frame numbers on each line to create a timestretch that varies over time… it sounds amazing haha… but it’s not possible to create such a file with a script )
Functions to copy parts of one samplebuffer to another.
yay! for some reason I thought we weren’t allowed that, because of the whole document/preferences comfort. rubberband, here I come!
- file dialog GUI element: a line with the file/foldername, and the common […] button next to it, in one package. with a bunch of options to only show/allow selection of folders or files with certain extensions.
permanent plugin data folders (that get deleted at uninstall) this is tricky though. I’m was thinking that it’s silly to have to download 6mb of rubberband every time 20k of script get updated, and if there is a clean way to avoid that we should find it… but then there would have to “full install” and “upgrade” versions of plugins so to speak. so yeah, it’s tricky and might be more complicated than useful, just wanted to throw it out there.
about the previously suggested functions that copy parts of one sample buffer to another: sample_buffer:copy_buffer(target_buffer, source_start, target_start, frames_to_copy(, source_channel, target_channel)) (ie. it would be nice to not have to think about mono vs. stereo samples and have it just work, as long as both sample buffers have the same number of channels and same bit depth (sample rate shouldn’t matter with this, strictly speaking) - but to also have the possibility to be more specific)
functions to replace on sample buffer with another (changing the length, sample rate, channels and bit depth, adjusting loop points so they’re in range, but keeping all other data including the name intact)