What would Renoise ‘rebooted’ look like?

General Discussion
1

So in the spirit of movie reboots (e.g. Star Trek) which are largely done to free future directions from previous concepts. What would a ‘reboot’ look like for Renoise?

Lets say Taktik and co decide to create a new version of Renoise that’s is (gasp!) incompatible with the old version (lets call this Renoise Classic). With a redesign from the ground up, what direction could it go in? What would could be done different in terms of the fundamental codebase and overall design?

Perhaps there is a logic to this when terms such as ‘old and bloated codebase’ are used when software has reached a certain age and further development loses its appeal.

Given trends in the audio world right now I think the following could possibly feature in some way and baked in at a core fundamental level.

  • Scripting / Customisability / Modularity – While already baked into Renoise with lua scripting it has limitations with refresh rates, lack of audio processing, GUI design etc. See also Reaktor, Max, VCV Rack, Max for Live, Bitwig, PD, Loomer Architect for inspiration.
  • Flexible audio and Midi routing – Route anything anywhere.
  • Granular sample playback / Time Stretching / FFT Processing – Trackers have always been about sample manipulation so this kind of functionality would be essential I think.
  • Live Performance and Hardware integration – See Ableton Push and updates to the MIDI specification such as MPE. Also things like the Elektron Machines and their integration into a DAW via Overbridge, also consider Renoise tools such as Guru.
  • UI / Workflow – Appealing to the musicians as well as the prosumers, but then maybe you can’t have it all and being niche is inevitable.
  • AI and Machine Learning – Only in here because its the current buzz, not sure how useful it could be… but then… Sononym…

Legacy concepts that could probably be left behind

  • Tick based timing in favour of Sample Rate processing
  • Sample based player commands in favour of Parameter Locking
  • Self contained modules in favour of folder based file structures

I’m not saying this is the direction Renoise should go in but simply curious about what a fundamental redesign could enable. What would you add to these lists?

2

The points about mixing and routing are obvious.

There are also some conceptual flaws with song editing in Renoise. These would be addressed on a fundamental design level. And there are some unexplored potentials/additions that maybe don’t fit 100% to how Renoise is currently laid out.

Some differences between today and what I think is optimal:

  1. The “stratification” of lines in the pattern editor is a relic from a very dated paradigm. It does not visually/practically correlate with how musical timing works.

  2. Patterns would be abandoned and a freeform arrangement timeline with a clip system would be used instead. It could quite easily allow 100% ‘backwards compatibility’ for those who still want to visualize their songs as patterns.

  3. Perhaps there is really no need to have Redux integrated into Renoise like it “is” today. Let Renoise just be a song editor and dsp/vst mixer/router. Pattern effects can be aliases for midi CC sent to Redux, making it behave exactly like it does today. (not sure if this is technically possible, but it seems to be the correct design if it is). This would allow Renoise to “easily” export an xrns as MIDI, with 100% correct playback in any modern DAW.

  4. Make song editing and arranging as object oriented as possible. I’m talking overlays/layers and clips - for example separating voices from chords, or notation from groove/micro-timing layers.

3

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…

4

I like the way Renoise is now, bug squashing aside. I’m not against progress, but the proclivity for “feature creep” in software usually puts me off at some point. Simple is good. Look at Reaper. Gads. 450+ page manual. No thanks. If Renoise ever went that way, I’d go back to using MilkyTracker … or working out a co-writer deal with Alexa. :slight_smile:

blackbox.jpg

5

IMOa “Renoise rebooted” would ideally boot itself up within the framework of the ARA2 technology, which was announced at NAMM almost a year ago. That way such a Renoise could focus on the tracker specific sequencing stuff and leave the rest to other DAWs such as Studio One or Logic.

6
  1. Perhaps there is really no need to have Redux integrated into Renoise like it “is” today. Let Renoise just be a song editor and dsp/vst mixer/router. Pattern effects can be aliases for midi CC sent to Redux, making it behave exactly like it does today. (not sure if this is technically possible, but it seems to be the correct design if it is). This would allow Renoise to “easily” export an xrns as MIDI, with 100% correct playback in any modern DAW.

For me is Renoise a comfortable stand a alone Version of Redux

with the view is also sadly that Sonyom is not somehow integrated into Renoise

7

Getting away from compatibility with other trackers, you could more strongly tie instruments to tracks. That is, not allow an instrument to be used in more than one track. Maybe even go as far as making instrument:track 1:1 and simplify things further. Then you could merge instrument and track FX into a single thing and do away with the instrument column and selection UI.

Also I think it’d be interesting to have the whole thing be more deterministic throughout, where the default for LFOs and whatnot would be to reset at the beginning of the song. Maybe not actually possible with VSTs. But if things were more deterministic it’d be possible to pre-render everything and play it back from cache. You could do complex work on cheap hardware.

8

IDK but I don’t think it would be proper for renoise to try being like a full fledged industry standard daw. I mean it is still a tracker, and tracker’s are peculiar beasts. I’d rather wish renoise to be the most dope tracker, than it trying to be somthing it just cannot be with confidence. Trying to be a complete daw would just make it loose the tracker feeling and put it as a feeble dwarf next to the real industry standard programs, while as a tracker it is already shining in unparalleled ways.

I do however think as a tracker it could well use some upgrades, so making music sound refined could get easier. On my personal wish list there are some things…like sidechaining/parallel processing, layering instruments and processing together, automation workflow upgrade so you can see all the automation next to each other and some waveforms and notes, and better audio track and freezing handling, like proper timestretch/pitchshift tools and waveform display in pattern or sequencer that would be essential when trying to work with vocals. Yeah and new gui…while I’d still wish the trackerish feel to be kept, and the possibility of a strong keyboard workflow be maintained.

Other than that and some minor details I’d rather like renoise not trying to become somthing that wouldn’t really fit its feet. It is already an unique piece of software like it is, if it were different it would probably loose many of its special properties. If you need industry standard daw to work professionally, then buy a proper one that is dedicated into fulfilling those needs. I’d rather not bet on this very small team even trying to do somthing that usually the big teams have to work on for years to be ripe.

10

@Zer0 Fly.I do not understand your reflection. Renoise could be re-programmed from scratch, and the result as a program would be very similar to the current one. Maybe there would be many people who would not know how to differentiate it. It would still be a tracker, but with better code and more compatible with current hardware and technologies. Nothing would be “another thing transformed.” It is not about comparing it with other DAWs. It is about improving what is already there. There’s no more.

That is, not allow an instrument to be used in more than one track

What? You can do that with Renoise. Use a single instrument within a single track. Why restrict it? The virtue of Renoise is precisely the opposite, to be more flexible. Use it as you want.

11

What? You can do that with Renoise. Use a single instrument within a single track. Why restrict it? The virtue of Renoise is precisely the opposite, to be more flexible. Use it as you want.

My understanding of the topic is that we’re not talking about incremental changes here, but things we’d change about the design if we were starting over. If I were designing a modern tracker from scratch, it wouldn’t have instrument selection like in most of the classic ones. Just to be clear: I am not suggesting that Renoise ought to scrap the instrument column.

12

Making a tracker from scratch now would have to result in somethinglike ReViSiT or HackeyTrackey that cross the bounds of tracking and “normal” DAWs.