Do you want me to put the term “instant” in quotes? You could explain.
You could do, it might soften the blow a bit. The computer has got to run through instructions that take time to execute (even if the perception to the human is ‘instant’.)
@4tey. You are very gridded, but you’re right. But me too. Obviously I am speaking from perception when viewing a tool. That’s why there is a video above.
Any function, however slight, needs some time to execute, even if they are 0.00001ms. This is obvious.
What I meant is that there are “iteration functions” that can cause “a graphic delay”, because they must be executed before. And anyone can think that it is some delay of the viewbuilder (the API GUI), of the change of state of an object (change its appearance), as if that was a great job (change many objects at once). And no, these tasks are ultrafast. I am handling thousands of objects at the same time with this tool.
That said, what I show in the video is one of the things that caused me the most headache to solve. It is not easy to make everything work, when there are many states and you have to attend to them all. You change the switch somewhere and something fails. 
One does not realize these things until you do not schedule something complex in depth.
Edit: @4Tey. By the way, in my native language (Spanish language), the word “instantaneous” means a short duration. It is not a concept of something that has no duration. Does “instantaneous” mean something else in English? I ask because it is not the first time that happens with some English person. Something “instant” has never meant that it has no duration.
I usually interpret ‘instantaneous’ as no time has elapsed. That’s probably just my (incorrect) interpretation then.
Well at least I’ve learned that Raul 
This is like a contradiction. I guess it’s a “vice” of some programmers.
Take an instant coffee to my health! 
1 Like
In the following image, I share a screenshot of the Corsair iCUE program, for the Corsair Strafe RGB Cherry MX Silent mechanical keyboard (Corsair Strafe MK.2 RGB (Cherry MX Silent)):
This setting is useful for using the keyboard together with the PREv6 tool.
The illuminated keys of different colors help to quickly identify and remember the main keyboard commands. RGB LEDs are useful here. Take advantage of the LEDs to better control your USB keyboard!
New custom slide bar for Keyboard Commands panel:
API 5 does not have a native way to create a scrollable list of variable objects.
Here is a pretty good solution of a vertical scroll bar, using layers, a button and a minislider, with the “trick remove_child / add_child”. Unfortunately in API 5, sliders and minisliders do not have the property of “released”. This prevents easily building such solutions.
Thus, all the information is visible on smaller resolution screens, and will allow to add inside the list more keyboard commands more easily.
1 Like
PRE6 welcomes the slider to navigate between the lines of the pattern. In addition, it incorporates two buttons (up, down) to navigate between the patterns in the sequence.
The mouse pointer is getting a lot of muscle!
2 Likes
This looks fantastic. Does it work in Redux, as well?
Does Redux even support Tools?
Nope.
Nope.
OK - thanks.
Thought so.
PRE is only available for Renoise v3 64bit (does not work in 32bit). Currently, I am preparing a version for Renoise 3.2.0 that brings interesting things, in addition to HiDPI support. In fact, I just need to update the instruction manual integrated with all the news. In fact, this new version covers some of the most important requests of some users.
@Raul I would love this tool, if you added bars/note lengths to your editor, including sub-column lengths. A piano roll 
1 Like
This has already been discussed above the thread. The representation set for Renoise is more complicated to build blocks of notes (elongated rectangles). Technically it is possible and I know how to do it. But it would be a chaos in the superposition of layers in the TR mode, which allows to visualize the firing of the notes of up to 33 tracks (they are up to 16 + 1 + 16 superimposed layers). There is a lot of information there. If elongated rectangles were used, much of the information would be lost. For me, the important thing is to show where each note begins and its tone. Also, the note-OFF does not always stop a note and the jump between patterns is a bit “controversial”. It is better to be true to what Renoise shows in the pattern editor.
Instead, in NC mode, you can see up to 12 columns of notes, with their notes off, they are 12 overlapping layers.
I am using “color codes” in both display modes. If I wanted a simple single-layer, single-color Piano Roll, I could use the elongated rectangles for the notes and their duration, but I would only see one layer at a time, which I think is very limited, and would have problems with the note-OFFs.
What is the philosophy of this tool as an editor? Allow to locate and change those values shown in the pattern editor directly.
When building this tool, I have never intended to “copy” exactly what other Piano Rolls from other DAWs offer. In fact, this tool goes further with layering.
That said, a couple of adjustments in the API would be necessary for all this to work better, in case you want to use a single layer and notes with rectangles. In addition, it is wise to remember that we cannot do everything. The API has what it has and you, as programer, have to adjust to it.
In the next version of PRE, PRE6, it will be very easy to add a note with its note-OFF and modify the position of the note-OFF, all this with just two clicks, only two! It is even faster than dragging and dropping the corner of a rectangle, and note-OFF also has its own representation. You can eliminate it directly, you will not be fighting with an elongated rectangle.
It would be possible to make another smaller and simpler single layer pianoroll project, with rectangles for the notes. But it would be very limited and messy. It would be very nice and all that, but people would go crazy with the slowness to modify the rectangles. Think that you would be constantly fighting with the delay of each line, the “false” representation of the note-OFF, problems jumping between patterns, the overlapping layers (it seems that many forget this). There are too many things. No wonder no one has the guts to build and finish one. You do not dare to make one?
If you would do an object oriented abstraction layer of the notes and tracks, this would extremely simplify the complexity of this. I wanted to do that already, maybe I should actually try that. But I think danoise already did this, at least in a very basic way?
But I meant more something purely OO style, so you do not have to deal with the actual iterative pattern structure at all.
1 Like
@ffx. Of all the tools I have built, the most fun to program has been this.
At first everything seems very easy. As you progress, on the fly you find problems that stop you from doing certain things, especially in the visual section (how do you represent a thing without leaving the script, which is Renoise).
It would be interesting if you started your own project, even if it was a prototype and you didn’t even publish it. Simply, when you see it working, you compare it with all those tracks that Renoise has, with all its 12 columns of notes, observing the rectangles of the notes and the rest of the information. Let’s see if you are able to go to a specific value that is in the pattern editor and change it quickly. In any case, the project would be interesting simply because of the code itself. Building any piano roll is more fun than any other tool, because you put it all together.
For the record, making a visualizer (with standard piano roll notes, even colored for multiple tracks) isn’t very complicated when using OO. Editing them, relying on bg xypad, is quite complicated to wrap your head around and design properly (perhaps easy if you do programming as a profession). Doing something like multiple selection + multiple note-off drag a little more complicated, again.
And on top of it all you have to decide the mechanics of handling note columns.
I understand why nobody have done it, even though it’s possible.
The prospect is a bit more tempting now that we have access to key modifiers.
The complexity indeed comes with the note-on/note-off separated commands and the columns (and note delays). You need an abstraction like something which gives you a note object including note length, position, neighbour references (including offsets), or similar, and a two way converting from reality->oo model and oo model->reality. So you wouldn’t care about placing/interpreting columns and note-offs at all.