Sort of look at where we are with Renoise 3, remember how innovation and coolness drove the invention of the very first trackers and then think YES! LETS GO!
Just sayin.
Thatâs a damn nice idea!
(I donât even think it would have to be very âinnovativeâ. To me, just vst3 support, sidechaining and HiDPI would be enough for constituting 4.0)
I think they should remix version 1
only need audio tracks just that âŚ
I hope for fixing the vibrato, tremelo and autopan commands so that they cycle synchronized with BPM and TPL settings.
Also measuring things out by percentage of a beat in sampler modulation and LFOs is less useful than measuring by tick or lines sometimes, so it woud be nice to have envelopes and LFOs measurable by ticks and lines as well as by âpercentage of a beatâ.
Its quite perfect as a tracker already, just a few tweaks like that would be nice.
If internal C++ is spaghetti these days hand more of the load over to Lua:
-
Most vitally Improve scripting GUI capabilities
-
improve any features in renoise that will enable more ambitious scripts
i.e.
ânegative delay values in the pattern editor to make a Lua piano-roll/ sequencers output match up better
âSpline curves in the automation, replicatable in scripts GUI
etc. etc.
âBuild it and they will script!â
or just unleash the Sononym AI to start coding 4.0 immediately!!
I will only add some thoughts, strictly my current opinion:
Iâve been thinking for a long time that the best that could justify a new version (the number 4 I still see it very far here) is a drastic update of the Renoise GUI for high resolutions, based on vectors, abandoning the bitmaps. Externally, this would possibly only involve changing the icons of the tools, compatible with vector images. It would be the best current path and let Renoise prepared for the future. It is very likely that, if the GUI is vectorial, it will imply an increase in graphic performance, and lower CPU load, and also performance improvement for tools with heavier GUIs.This might involve paying a skilled programmer in this kind of graphics, and investing heavily in it, very convincingly, while Taktik is dedicated to improving other things related to audio, bugs, new features and internal codeâŚ
On the other hand, today I saw an âoldâ masterclass on Ableton 10 (in Spanish). I have handled Ableton 10, and I have compared it visually with Ableton 9. Apparently it seems that there are almost no changes, but this statement is very misleading. Ableton 10 has radically improved the GUI by changing it to vectorial image. In fact, it is the best of this update, and yet, it goes very unnoticed. Renoise seems the best software that would benefit most from a vectorial GUI, not a patch over the current bitmap-based GUI to zoom in a bit.
I just hope that this topic is well thought out by the Renoise Team and they take it very seriously.All the most important DAWs on the market are going to have GUIs based on vectors. I is convinced of it.I want to remember it, because everything else that Renoise brings will depend on this GUI.I hope that Taktik is contemplating this as a serious possibilityâŚ
On the other hand, remember the automation editor. To improve it would be a very good addition for a major update. I will not get tired of saying it. I have the feeling that some of those involved in the development of Ableton know very well everything that is asked in these Renoise forums. Many of the things demanded here are recently added in Ableton. It seems that the same thing happens with other DAWs (BitwigâŚ). Here are magnificent ideas and they seem to come from outside and take advantage. Itâs just an impression.
I have put Ableton 10 as an example, because it is just the kind of GUI that would be perfect for Renoise: clean, flat, without graphic watermarks and taking maximum advantage of flat colors. All this would be my point of view for a new version of Renoise.
1 Like
I am missing especially midi export as for example in Microtronic is possible
Would also like an extended Phrase Editor
From the principle like the small Window on the top left the âMagnifying Glassâ in Grooverider, there is duration possible (like in the Piano Roll in Cubase or FL) without leaving the Pattern Sequencer Principle
Sorry my English is unfortunately too bad to explain that understandable
I am missing especially midi export as for example in Microtronic is possible
Might help? â https://www.renoise.com/tools/midi-convert
I hope for fixing the vibrato, tremelo and autopan commands so that they cycle synchronized with BPM and TPL settings.
I think there is a synchronise dsp tool�
On the other hand, today I saw an âoldâ masterclass on Ableton 10 (in Spanish). I have handled Ableton 10, and I have compared it visually with Ableton 9. Apparently it seems that there are almost no changes, but this statement is very misleading. Ableton 10 has radically improved the GUI by changing it to vectorial image. In fact, it is the best of this update, and yet, it goes very unnoticed. Renoise seems the best software that would benefit most from a vectorial GUI, not a patch over the current bitmap-based GUI to zoom in a bit.
Programming and designing a good and also performant GUI that also runs fluent on modern resolutions like 4k seems to be a tough job these days. So even Ableton 10 has some problems on this area: If you use another zoom level than 50%, 100%, 150% and so on, the performance of the GUI will heavily drop to 10-15 fps (I guess it is then rendered thru CPU instead GPU) on macos. It runs perfectly smooth so at those mentioned zoom levels. So this vector GUI currently is pretty useless for a lot of users. And since Apple now even is about to drop opengl support (maybe this is the future) to only use their cross-ios, proprietary metal2 api, it became an even more tough job. Finally with Metal, there seems to be the real pendant to DirectX. So it seems to be essential these days, that a gui is fully drawn by GPU using either directx or metal, which is even more work for the programmers. See Bitwig or Tracktion, where 4k GUIs are fully drawn by CPU and cause heavy GUI lags and even audio drop outs. On the other hand, there are perfect examples in this regard, too, like StudioOne or Cubase. I guess, because these 2 implement directx and metal directly, without using a crossplatform lib also supporting Linux. A GUI crossplatform lib supporting directx and metal seems to be missing, too. So I do not expect any other complicated stuff to come in Renoise 4, e.g. VST3.
1 Like
Might help? â https://www.renoise.com/tools/midi-convert
thank you, is known
but I would prefer a simple copy paste.
With me itâs mainly so small details (to many Clicks, Save) that mess up my workflow
See Bitwig or Tracktion, where 4k GUIs are fully drawn by CPU
Worth mentioning (and just slightly expanding upon) with statements like this that even the current Renoise version is probably using the GPU on your video card as a helper to draw graphics into the video framebuffer. Renoise may not be calling OpenGL/Direct3D API directly/efficiently, but for example on Linux, it probably makes drawing calls through to the Xserver. Most (nowadays) Xservers have some GPU acceleration going on. You can see this if you run a âGPU utilization %â program and watch the GPU do more work when playing/scrolling a blank pattern. Moral to this story: you can be using the GPU to get graphics on the screen more than you thinkâŚindirectly. Just sayinâ
@ffx. It seems that the issue of improving the general GUI gives to talk.
I do not understand in depth the relationship that exists exactly between the graphic design of the program and the use of the hardware in particular (separate CPU from the GPU). In fact, I do not understand exactly how Renoise works in the current version, and I think Iâm not the only one. But the fact of using a complete vector GUI saves any zoom situation. Another thing is how it is implemented to use the CPU and the GPU.
You say it can go down 10 and 15%. I guess it will depend on the hardware that you use. Because with powerful machines I do not even think he finds out. The fact is that, honestly, I think that keeping the bitmaps is a big mistake. While the GUI is based on this, we will not have nice graphics at high resolutions. The main problem with the bitmap is that it is fixed resolution. If you extend that resolution the image looks pixelated, badly, something is missing visually. The vector breaks that barrier. Regardless of the use of CPU & GPU (separately) it is obvious that the vector is much better than the bitmap. Developers know this, and are fleeing from the bitmap as from the plague.
If there is something better than a vector GUI to implement, I would be happy to meet you. On the other hand, I understand that one thing is graphic design, and another thing is how you move that at the hardware level. That is, they are two different things.
You also say that for many users, the vector GUI is currently useless. I think this is not true. Many users do not even know what a vectorial GUI is. They are using software zoom parts without knowing what their design is. The visual result is optimal and they do not know why. They are not seeing bitmap GUI, but vector GUI and not even know how to differentiate it.
A very specific case is when an area is enlarged and the icons appear larger. They do not appear apixelados. Everything looks perfect. That is impossible to happen with the bitmap. Renoise is full of bitmap objects, include the skins. In other words, this is an âobsolete technologyâ.
Regardless of the problems that may currently exist between linking the software with the use of hardware (CPU + GPU + RAM âŚ), it is obvious that other programmers are facing this and are taking advantage of the vector design. There must be a reason.
I think itâs about finding the best solution. Another thing is that you choose to keep the bitmaps because the main programmer considers not getting too hot on the head. When I said about hiring an expert programmer in vector GUIs, It is for a reason.Or, if there is time, at least investigate it in depth.Everything else seems excuses not to implement it.
By the way, Ableton 10 came out. But the developers are still on top of it improving things. And another detail. In some cases, the graphic performance can drop drastically, and does not depend on the GUI, but on what is processing audio, or certain processes. All these things influence the graphic performance. What it can not be is that the audio works fluid (you hear it fluid), and the graphic goes to blows.
Finally, another thing that I have wanted to comment for some time and I never say it: currently, the way to reproduce patterns in vertical movement becomes somewhat illegible. It even becomes annoying. Here influences the speed of the monitor so that the pixels change color. But also of the graphic performance. If at certain speeds, the pattern makes small jumps, this is illegible. Maybe it would be nice to have another display mode (optional), that would move the bar vertically, and the pattern would remain fixed in the playback, updating in the sequence when necessary⌠I believe that even in the current version it would be easy to implement. I remember in another forum of Renoise that another different way of showing the pattern in vertical movement was discussed, more fluid and constant, so that the characters were legible at all times. There are so many details that can be discussed at a graphic level that we would swell the forums.
1 Like
As far as I can tell, Renoise GUI currently is fully drawn by CPU. Even the GUI scaling to 2x in 4k seems to quadruple the amount of CPU usage. I am also for vector gui, I only wrote that programming a modern GUI is a hard job and surely is a lot of effort.
Worth mentioning (and just slightly expanding upon) with statements like this that even the current Renoise version is probably using the GPU on your video card as a helper to draw graphics into the video framebuffer. Renoise may not be calling OpenGL/Direct3D API directly/efficiently, but for example on Linux, it probably makes drawing calls through to the Xserver. Most (nowadays) Xservers have some GPU acceleration going on. You can see this if you run a âGPU utilization %â program and watch the GPU do more work when playing/scrolling a blank pattern. Moral to this story: you can be using the GPU to get graphics on the screen more than you thinkâŚindirectly. Just sayinâ
Oh that is interesting. But there is one indicator that surely only very basic operations are used, or none at all: If you disable the macos videodriver, macos will boot with a software video driver (similar like windows safe mode). In this mode, Renoise still works as usual, even when no graphics driver is available. So I was thinking it actually uses almost only CPU for the GUI. And since I swiched to 4k, the analyzer opened now uses pretty much exactly 4x times more cpu than on fullhd.
So do you mean that kind of drawing thru the gpu framebuffer will already accelerate things? Maybe my description only matches for macos.
As far as I can tell, Renoise GUI currently is fully drawn by CPUâŚ
I think this is partially demonstrable with the use of specific tools. You can create a tool with thousands of objects. These objects will need a time to load into memory. Once they are in the memory, they seem to have little influence on the graphic performance (leaving aside the bitmap, which is a graphic ballast). That is, if the tool goes badly graphically, the main cause is that you are running a function that requires many CPU cycles. It is a poorly optimized function or it is simply very heavy (try to access a lot of data, as can happen with the famous iterations that cause so many headaches). This I have been able to experiment with my latest tool based on a pianoroll. For more objects that you add, as long as they remain in memory (you do not close Renoise), they will not be a problem of graphic performance. They are the functions that you shoot, and here are the CPU cycles.
Then everything seems to point out that the main problem, regardless of the aspect at different resolutions, is that Renoise does not take advantage of the GPU. Thatâs like walking with one leg.
But there is one indicator that surely only very basic operations are used, or none at all: If you disable the macos videodriver, macos will boot with a software video driver (similar like windows safe mode). In this mode, Renoise still works as usual, even when no graphics driver is available.
Yes, and you probably know that possibly (although btw Iâm no expert in this area, not many people are?) the XServer has CPU based fallback rendering when no GPU is present, hence why Renoise still works?
Look ffx, let me try and explain (as I know it.) If I write a program that displays a bitmap in a window at 60fps. I call say âDrawBitmapâ function. To me (as developer), I donât know if that is going to use the CPU or GPU or both when it gets down to the lower levels of completing said task. I just expect the function to work (and hopefully fast.) What the Xserver could possibly do is move (via the CPU) the graphic data onto the video card (takes time because the communication bus between CPU and GPU is slow, really really slow), and then âblittingâ the bitmap (via the GPU) onto the screen. This of course will have the effect of lowering CPU utilization on subsequent calls. Good. CPUâs do not like reading/writing to/from video ram. Period. They hate it with a white hot passion (it burns them upâŚerrâŚliterally :)) What you are talking about is Taktik rewriting his GUI framework going more directly via OpenGL/D3D API (or some helper library that uses OGL/D3D API) to âincrease performanceâ by unloading more CPU drawing/graphic operations more so on the GPU side (more efficient as the GPU electrically sits closer to video ram than the CPU does. The GPU can generally read/write to video ram faster than the CPU per clock. Also any manipulation of the bitmaps that sit in video ram should be done with GPU shaders, not the CPU.) This should lower CPU utilization. Good. However your GPU will probably now work harder and get warmer when you are running RenoiseâŚerrâŚ4âŚI mean version 2.9 
What Raul is also talking about is vector graphics. I.e. vectored rendered generated bitmaps (like in Inkscape/Corel Draw/Illustrator), so at any âzoom levelsâ the now calculated âbitmap graphicsâ stay good, donât go âblockyâ and hurt Raulâs sensitive eyes 
1 Like
What Raul is also talking about is vector graphics. I.e. vectored rendered generated bitmaps (like in Inkscape/Corel Draw/Illustrator), so at any âzoom levelsâ the now calculated âbitmap graphicsâ stay good, donât go âblockyâ and hurt Raulâs sensitive eyes
I believe that my eyes have nothing to do here 
. But yes, it is understood what you have wanted to say. And yes, performance is as important as that the graphics look good. I appreciate that both can be differentiated.In addition, a good appearance is a important matter for the sales!In fact, it is an attraction that many users see very often.
âŚ
GPU accelerated Renoise would be so cool. I always wanted various drawing modes for oscilloscopes, spectrogram etc. and maybe even actual sound indicators per track/column/group (kinda like the VU meters Protracker had). Maybe even allow scripts to create/modify the shaders for those.