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:
Canvas … 
Each Renoise object should have :set_userdata() and :get_userdata() methods, where i can assign a table with my own values.
Enable and disable viewbuilder controls.
Listbox and treeview viebuilder controls.
That’s it mostly for now. 
– +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.
This already exists:Try the key_handler hook in the dialog creation mode…
app():show_custom_dialog(title, content_view, key_handler_func)
function key_handler_func(dialog, key)
key read… do stuff
end
yay!!
okay, make that “me actually knowing about what the API can do” 
Maybe the code that marks up {lua} forum tags could be used to make the documention a bit nicer? I’m not saying it’s the fault of the docs that I haven’t read them, but it would reeeeally help.
One thing that does kinda get me is the order though:
description description description description description description
the thing being described
Is there a reason for this? the other way around would be much more logical for me, easier to scan etc.
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).
+1 to that!
ability to access the automation curve context menu
no wait, that applies to the whole dialog… how would the dialog know I’m in textfield X when pressing cursor up/down?
so an optional key handler for all input fields would still be nice 
yeah okay you have a point there… how does LÖVE do it? I guess they have they provide high level functions written not in LUA, but accessible to LUA…
would it be feasible to just, uhm, stick LÖVE into Renoise haha?
Could be solved by supplying additionally the originating control id to the keyhandler function maybe.
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.
reading and setting the current position/zoom in the sample editor.
It would be cool if the selection in the sample editor could be observable.
Reading and writing text files!
(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.
renoise.app():prompt_for_filename_to_read({file_extensions}, dialog_title)
renoise.app():prompt_for_multiple_filenames_to_read({file_extensions}, dialog_title)
allow png for bitmaps (!)
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)