Wild assumptions ?
I made zero wild assumptions, I stated a fact, there have been no parity releases that have occurred at the same time, quoting myself “when Redux gets updated, Renoise then has to be updated for parity” that is neither wild or an assumption, it is a fact, that is what happened, nodiscussion, no argument, just FACT.
I still want to believe.
Wild assumptions ?
I made zero wild assumptions, I stated a fact, there have been no parity releases that have occurred at the same time, quoting myself “when Redux gets updated, Renoise then has to be updated for parity” that is neither wild or an assumption, it is a fact, that is what happened, nodiscussion, no argument, just FACT.
Maybe i wasn’t clear enough. You seem to assume that the long release cycle for the first Redux is a normal thing while i have expressed it isn’t. Renoise and Redux are on a similar level now, new features should be a lot easier to implement and not hinder each others development much. Now please continue with your agenda, i won’t disturb you further. It’s better to not read much in this forum anyway.
Maybe i wasn’t clear enough. You seem to assume that the long release cycle for the first Redux is a normal thing while i have expressed it isn’t. Renoise and Redux are on a similar level now, new features should be a lot easier to implement and not hinder each others development much. Now please continue with your agenda, i won’t disturb you further. It’s better to not read much in this forum anyway.
Actually the only person here with any assumptions is you, i never mentioned the long release cycle of the first Redux, you did, so please get over yourself and your nonsense, I have no ‘agenda’ as you put it, i stated facts, however it is clearly obvious that you do have an agenda when you misquote to try and further yours !!
I wouldn’t mind a simple piano-roll, something like Bitwig studio has.
I also think Renoise would get more people this way because people that are used to horizontal based DAWs can familiarize themselves more quickly in Renoise. and also the other way around.
A horizontal/vertical based DAW. or maybe they should call it a “+DAW” since the sequencer would go in both directions 
However i agree since this thread is very old, i don’t see it coming. But maybe someone can make a XRNS script for it, if that’s possible.
Well…Just having a piano roll ain’t gonna attract any more Renoise buyers. First things first is that the app needs to not use up so much FRIGGIN’ RAM! Easy to top out on just a basic tune that I can easily do in most other DAWs Sequencer-Tracker-Piano Roll in less than half the RAM & in some like Aodix 1/3-1/4th the RAM…Examples include-
EnergyXT versions 1 or 2
Bremmer’s MultiTrack Studio
Ioneo Aero Studio
Arguru Aodix
Tracktion
Cakewalk Project5 ANY VERSION
Cakewalk Sonar ANY OLDER VERSION
Synapse Audio Orion
Audio Simulation DreamStation 1 & 2
Psycle
BUZE
Jeskola BUZZ
Reason to version 5
Sony ACiD
FL Studio
MuLab
Zynewave Podium
Cubase ANY OLDER VERSION
ETc ETc
Just buy more ram, it’s cheep. 
Renoise itself uses the least amount of ram of them all, for sure. The reason you see an increase is because samples are loaded in ram at all times, not streamed from the hdd.
The advantage of the piano roll is that it clearly visualizes the intervals of chords. For people who know intervals like the back of their hand, without a visual aid, this is completely unnecessary. The advantage of the tracker interface is that you can see the notes of multiple instruments next to each other. Imagine you are playing a chord across 3 instruments, one note per instrument. With a piano roll, each instrument would have its own roll, and they would each visually indicate that they have 1 note in them. Great! that is not very useful at all. It would be far more useful if the piano roll were able to show multiple instruments at once, maybe with different colors, but they usually don’t. The tracker interface does allow you to see all the notes of the chord, across 3 instruments. What it doesn’t do is visually show you how far apart the notes are, aka the intervals. Anyone who actually already knows the intervals, just by reading the note names, will find the tracker interface actually provides a far greater advantage.
All that aside, I don’t think that there is anything wrong with having both. Why not? While I would prefer to edit in tracker mode, I would much rather show people my songs in a piano roll view. They would have an easier time seeing visually what is happening. So the advantage isn’t always about editing, but the total experience the program can provide. Of course, it is a tool for production, and not showing off, but I plan to stream myself using it on Twitch.
If the piano roll was able to accomplish the same thing that the tracker does, showing the notes of multiple instruments next to each other on a single roll, then I think it very well could be a strong selling point, because as far as I know, it is not something that exists in other DAWs. It is not even something that I think other DAW developers are aware of. It is the exact thing that attracted me to Renoise. The fact that Renoise was aware of the advantage gained by seeing the notes next to each other.
It would be very cool if you could just select some tracks, and those tracks are shown on the piano roll together. So you could choose if you wanted to see the roll with just one instrument, all the instruments, or a few at a time. I also realized there would be the issue of showing overlapping notes. The note cell itself could be divided into parts of different colors, one for each instrument. The instrument rolls could be overlaid with a slight offset, almost like a hand of playing cards, with the corners of notes peaking out from underneath other notes. Maybe notes can be somewhat transparent, and colors can combine? Maybe the reason this hasn’t been done before is because this part hasn’t been solved yet.
What would be even better isif the devs simplyfired upa full blown C++ “piano roll API”, leavingeverything(the GUI and features) open to third party coders to design and implement. That way we could have multiple ways ofhandling note data, and mimic the best pianorolls out there according to preference.Same thinking shouldapplyfor the audiotracksand linear arranger stuff.
If there’sone single thing thatno DAW makers seem to haveunderstood it is this:if you only give away the totalpower to the user to configure the behavior of the pianoroll editor and ways of editing notes, this mere possibility in itself is a huge selling point.
In fact, Renoise could win over lots of pianoroll users who’re right now sitting in front of Cubase, Logic, FL Studio, Bitwig Studio, Ableton Live, etc, etc… with such a move. Because such users (what could it be? 99.9% of all music producers in the world?) would immediately feel at home with the pianoroll and audiotracks stuff when trying out Renoise, leaving the headroom required to explore and experiment with the tracker’s unique audio mangling capabilities in alphanumeric mode.
It is my very strong conviction that adding such an “instant gratification” aspect into Renoise in the form of familiar pianoroll and audiotracks (and linear arranger)would also add a bridge over to the tracker way of handling note data. And that’s good news for both Renoise and Redux sales.
Add pianoroll, audiotracks and linear (non-pattern bound) arranger and you’ll see that the Renoise userbase will become 10 times bigger within a year, and the “tracker way” we all love so much will find a way intotheworkflows of many, many more music producers around the world.
Actually i would have to disagree, Reapers Piano Roll can be configured and modded heavily, i never ever hear “Oh Reapers Piano roll is the best” comments, the complete opposite, FLS Piano Roll is locked down, you ain’t modding nothing, most common comment, yep you got it “FLS has the best Piano roll in the business”
I don’t use FLS myself, but yes, they do actually have the most intuitive Piano Roll haha
If the piano roll was able to accomplish the same thing that the tracker does, showing the notes of multiple instruments next to each other on a single roll, then I think it very well could be a strong selling point, because as far as I know, it is not something that exists in other DAWs. It is not even something that I think other DAW developers are aware of. It is the exact thing that attracted me to Renoise. The fact that Renoise was aware of the advantage gained by seeing the notes next to each other.
Traditional piano rolls are very weird this way. Basically, you’re entering one clip at a time, or in some cases can have multiple tracks overlaid.
Why not have the piano roll being just one single view (like the pattern editor) where you zoom back and forward to navigate between tracks and in time? The whole song might as well be displayed in the same view, IMO, and ctrl-scrollwheel for navigating would be quite intuitive. Certainly an edge compared to the traditional clip based approach.
What’s possible is in FL Studio send different notes in one clip to different MIDI (VST) channels, visualized by color.
(JFR: https://www.image-line.com/support/FLHelp/html/pianoroll.htm @ Color Groups. It’s used for MIDI CH *and for sliding, kinda cool, but that wasn’t there in early versions or they should really write better manuals :d)
Traditional piano rolls are very weird this way. Basically, you’re entering one clip at a time, or in some cases can have multiple tracks overlaid.
Why not have the piano roll being just one single view (like the pattern editor) where you zoom back and forward to navigate between tracks and in time? The whole song might as well be displayed in the same view, IMO, and ctrl-scrollwheel for navigating would be quite intuitive. Certainly an edge compared to the traditional clip based approach.
Most of the piano rolls i use have item base/track base/project base viewing with selection and editing, clip/item views are just one thing, not everything
I’ve found out it wouldn’t be terribly difficult to script a piano roll. Moving buttons (notes) in the viewbuilder is possible, for example, and it’s easy to tie them to notes in the pattern editor. After some experimenting it seems to me that the code would even be surprisingly small and a lot less complex than some of the tools we’ve seen so far.
The bigger questionmarks to me are:
What scheme to use for note columns when interpreting/converting piano roll data to pattern data
Should fx be padded when resizing notes, and by what scheme?
and maybe the biggest question,
One API limitation would be the lack of context based mouse cursor, stupid things like changing the mouse cursor to a razor when split mode is enabled, but I don’t see any crippling limitations that would make it a bad idea trying to script it.
Any thoughts on how to proceed?
PS. A simple prototype to prove the mechanics: https://dl.dropboxusercontent.com/u/6812754/absolutely.gif
Funnily enough Joule point 1,2,3 that you make is the same thoughts that I had Taking point 3, why bother and really how much advantage is it for the tracker musician and not just a fancy lua script programming exercise? To be honest I always felt it to be slightly more of a programming exercise. Slightly interesting nevertheless, and that is why I messed around with MiniRoll as much as I did. What I was going to probably do (if I ever got any real motivation factor, I always feel that you are programming something that is…meh?) is expand MiniRoll to use say the GTK interface, and pump the message events from renoise lua into my separate C program:
Attachment 7229 not found.
Unfortunately cross platform is more tricky this way. Going purely lua you wouldn’t have this complication
Personally I think you would have to think of it more as a ‘tracker roll’ rather than a ‘piano roll’. Due to handling things like the fx column(s) and handling note movement/adding/deleting. I simplified it in my mind and I didn’t consider the fx column at all (for the moment). Just the algorithm for moving/adding/deleting notes and length (including the delay column) and calculating the position that that would be in the pattern (and what column.) As you know yourself Joule it is possible, it’s just getting the motivation and preferably a large continent of programmers 
Personally I think you would have to think of it more as a ‘tracker roll’ rather than a ‘piano roll’. Due to handling things like the fx column(s) and handling note movement/adding/deleting. I simplified it in my mind and I didn’t consider the fx column at all (for the moment). Just the algorithm for moving/adding/deleting notes and length (including the delay column) and calculating the position that that would be in the pattern (and what column.) As you know yourself Joule it is possible, it’s just getting the motivation and preferably a large continent of programmers
I’m thinking there could be a checkbox if you want to move fx along with notes or not. When enabled, we have to assume that the fx are moved as-is (relative to the note, with no fancy stretching or padding of effects). I’d be content with that solution. Perhaps stretching/padding if you hold a modifier key (say you want to maintain a vibrato thru the whole note duration, even after stretching the note).
The issue that gets me most confused is moving/deleting notes and how to do it non-destructively - e g. what note column to select when inserting a note. The basic problem is that it WILL break the previous note on the same column, if there is one. Maybe the simple solution is to always let notes occupy the first free note column - left to right. That would seem acceptable?
It also implies that the column allocation would ideally also require a “cut oldest note” routine, which unfortunately is relatively heavy.
I’m thinking there could be a checkbox if you want to move fx along with notes or not.
That was exactly what I was going to (eventually) do to be truthful Joule 
The issue that gets me most confused is moving/deleting notes and how to do it non-destructively - e g. what note column to select when inserting a note. The basic problem is that it WILL break the previous note on the same column, if there is one. Maybe the simple solution is to always let notes occupy the first free note column - left to right. That would seem acceptable?
Yup, it would be a tricky algorithm particularly if you want to preserve as much of the ‘structure’ that the user has already in the track. Personally I think it would be fine going with the ‘let notes occupy first free column’ approach. I wouldn’t mind because I would look at it from the programmers side and not so much from the musicians side. I’m of the mindset that whatever makes it easier (for the moment anyway, complexity could be considered later?) for the programmer
I would imagine Joule that most musicians initially just want a graphical way of picking a note, dragging/transposing, and adjusting length (with the delay/quantisation any note off calculated etc.) To be honest I simplified it down to initially be monophonic where it only considers 1 column at a time, then consider polyphonic/multiple columns later
What scheme to use for note columns when interpreting/converting piano roll data to pattern data
Should fx be padded when resizing notes, and by what scheme?
Even before this, I would consider how to interpret the pattern. You can have combinations of effects, notes, even multiple notes tied together with Gxx commands.
Would you not want certain effects to “belong” to the voice, and be able to visualize that gliding notes are in fact connected?
If you let it, all of this could automatically be picked up by xVoiceRunner(the class, not the tool). I’m using that class for note-sorting, but it can do a lot more than just that.
Even before this, I would consider how to interpret the pattern. You can have combinations of effects, notes, even multiple notes tied together with Gxx commands.
Would you not want certain effects to “belong” to the voice, and be able to visualize that gliding notes are in fact connected?
If you let it, all of this could automatically be picked up by xVoiceRunner(the class, not the tool). I’m using that class for note-sorting, but it can do a lot more than just that.
I pondered about exactly these issues/ideas (and your class) today.
Gxx should indeed make a note-pair (or more more) stay in the same column. And a handle is (eventually) a very nice idea as it will even let you drag the point of where the glide is completed (quite a novel visualization/control).
Another issue is what will happen when the user inserts a pattern. Any active notes will then be extended across that pattern. I think it’s important not to mess with any native behavior, so a custom “insert pattern” button in the piano roll could provide a way to do this task while keeping all note lengths.
PS. I did my own voicetable builder, as I also want it to be updated by line_notifiers in an optimized way. I wasn’t sure if your class/structure dealt with that, but anyway it wasn’t too difficult making a fast&cached voice scanner.
@joule, @4Tey and @Danoise… I do not know to what extent yourselves are able to build something that arrives somewhere with this theme of piano roll or the like, given the limitations of the API. I only want to indicate a couple of the details that I think so that you have them in mind, should you develop something serious.
The advantage of a simple piano roll, is not only the power to compose with it, that is, to place notes, to be able to drag them and to modify its length, etc. But also the ability to see the order of notes at the time of reproduction, once the piece is composed, after. I am more than convinced that a vertical piano roll is the best solution, which helps enormously to locate notes visually, and then modify them. It allows the mind to be released and the eyes to work at a different pace.
So the question I ask. Is it possible for the note blocks to light up, each time the note is played back in the pattern?I understand that with the current API is not possible. What you intend to build is only an editor, to include notes and modify them?
What I mean is that the piano roll would help a lot visually at the time of playing the notes. Let the blocks react to the notes as they are played or that there exist a moving marker, along with the lighting of the piano keys.
I think it has already been named in the forums, but I would ask Danoise to seriously consider adding the future API to an agile way of collecting information from the pattern editor during playback. For example, a button can not be lit when playing a note in the pattern. I think all this would be very useful for a possible piano roll.
A example… The other day I proposed another tool that was a sliding vertical bar to be able to modify the delay parameter of each note in real time, ranging from 00 to 255. Seen this, there were several bars, one for volume, another for panning, another For the delay (in reality this window would represent an enlarged cell, a quick way to manipulate numbers without typing any, but the parameters already written must be updated in the tool). But for this it is necessary that the API allows to collect the parameters writen in the pattern editor. In fact, many different and useful tools could be built if this were possible (to be able to read the parameters already written in the pattern editor).
I’ve found out it wouldn’t be terribly difficult to script a piano roll. Moving buttons (notes) in the viewbuilder is possible, for example, and it’s easy to tie them to notes in the pattern editor. After some experimenting it seems to me that the code would even be surprisingly small and a lot less complex than some of the tools we’ve seen so far.
The bigger questionmarks to me are:
What scheme to use for note columns when interpreting/converting piano roll data to pattern data
Should fx be padded when resizing notes, and by what scheme?
and maybe the biggest question,
- Who would undertake this project and why? I am guessing not many people would like to pay for this tool, so what would be the motivation? Ideally, I think it would be great if it was a community effort, possibly led by a “team” including a couple of scripters.
One API limitation would be the lack of context based mouse cursor, stupid things like changing the mouse cursor to a razor when split mode is enabled, but I don’t see any crippling limitations that would make it a bad idea trying to script it.
Any thoughts on how to proceed?
PS. A simple prototype to prove the mechanics: https://dl.dropboxusercontent.com/u/6812754/absolutely.gif
I am very curious about what you have built here joule, and the rest of ideas.Do not stop publishing things, please. If yourselves want to move forward with this theme, maybe it would be appropriate build a separate new forum, so that others can learn, and maybe contribute something.I mean, create a forum for this task, if in the end yourselves decides to do something.
Encourage everyone with this theme :rolleyes:!
By the way, I can not stop think about the use of the layers, merging the automation editor with a pianoroll, the fusion taking advantage of the area.What a rage that Taktik does not touch this subject :(.
