Well OK! I understand that it must be overwhelming to face this situation. That is, make the decision to rewrite the entire code to create something much better and current, with clear visions of the future.
I think that such a decision would be motivated by something very specific. Because attending to a multitude of questions, that is, making many changes would be a little incongruous. Surely there would be very few things to remove, some things to add, and other things to improve, but there would always be something of a lot of weight that would force you to make that decision.
From my point of view, looking at the current and future needs, the size of the Renoise team, and the current version 3.1.1, I think it would be necessary to restructure the software, abandoning the three 32bit versions and focusing all the resources on the 64bit versions, so that these are the best possible. Nowadays it is difficult to imagine people using the 32bit version, because we all have more than 3GB of RAM and processors compatible with 64bit. Why waste time on 32bit versions? These are things of the past.
The main reason to put the focus is on the graphic interface, based on vector technology. That is, I would have full control of the size of the text sources in both Renoise and the API for LUA tools. In addition, the images would no longer be based on bitmap (obsolete resources, such as images bmp, png, or jpg) but on vectors, which allow the rescaling of images. But the roadmap would be thinking about the future, to be compatible even with 8K monitors or higher. I’m not talking about current 2K or 4K, but the programmer has to have a vision of the future. Design it well now, and you will guarantee it for the rest of your life.
Another issue is the use of hardware. Here is the CPU, the RAM and the GPU. For some reason, if you have a minimally powerful graphics card, you will not get virtually any performance improvement by installing the most modern and expensive graphics card for the consumer, simply because Renoise does not take advantage of these graphical resources. All this is necessary to be able to implement several layers on the pattern editor, with audio tracks for example, and for everything to work fluidly.
Another key point is to drastically improve the automation editor. I’m talking about very important things, not small details, like adding an X filter or adding an X feature for sample editing. These bigger things are what motivate you to make such an important decision as to re-program all the code with a roadmap starting from the beginning.
Having said all this, I believe that this will never happen. Renoise, apparently, is a software based on “old” and “already inflated” code with small optimizations here and there that depends on a single person , a single programmer, with very limited resources. Running this new roadmap requires hiring more programmers and putting money on the table. And also know how to delegate and listen.
Finally, if Renoise was born today, I am convinced that the bases would be different. I am convinced that the vector-based GUI would be the most dependable roadmap , in addition to getting the maximum resources of the CPU and the GPU to be extracted , in order to free up more resources from the CPU and that it only dedicates itself to move the audio engine.
Starting to make a list of small details that could be improved could be a very long list. For example, only with the AP I I can think of many things:
-
Control of the size and color of text sources and turn 90º.
2.
Redimensioned images (if they are still used, for example, semitransparent PNG images).
3.
Location of the window (when you open the window again, it will open in the last position).
4.
Release of notes for keyboard keys on the keyhandler. Currently only allows the pressed.
5.
Direct audio control (without using OSC?). This is perhaps something delicate.
6.
Of course, separate control of the left button, right button and middle button of the mouse.
7.
Allow the combination of CTRL, ALT, or SHIFT keys together with the mouse buttons.
8.
And the list goes on…
If you look closely, most improvements to the API are related to the hardware (the size of the monitor, the alphanumeric keyboard, the mouse). There are many things that have to do with control.Of course, adding support for the API and LUA has been a great decision , and of course I would continue on this path.And of course, LUA should update to the latest version. Currently, it is compatible with the old 5.1.5 (Renoise 3.1.1), which is not the most secure version if you want to protect it.
There are so many things … What about the VST 3 compatibility?Renoise 3 is strongly prepared for the treatment of samples. But I would prefer many resources to improve the whole VST / VSTi management section. There are some annoying details. For example, the volume column of note tracks does not work with all VSTi. Why? Why should it be necessary to use a specific effect in the effects column, if the instrument used is a VST instead of a sample? Is it not possible to detect what it is for the volume parameter to act accordingly? There are many details …
This thread is very interesting. We could be arguing to the infinite, but I think there would be many important things in common and these things would be what would mark a road map starting from the beginning…