Brainstorming: Piano Roll

I’ve now started working on the piano roll (PR). It will naturally have some differences from the
piano rolls you’ve used in sequencers like sonar/cakewalk, cubase and logic, because of the underlying
structure is a trackerpattern with all advantages and limitations that comes with that. Among the
things it will have to deal with are allocating notecolumns for every note inserted, and varying speed
throughout a pattern. I think I’ve sorted most issues out now (it’s still mostly in my head and on
scetches), and will here give you an outline of my thoughts. Any comments, additions and bright
ideas are welcome. By writing this post I might even get new ideas myself :).

Like any PR, there will be a “ruler”, a “piano” and an open space with a grid where you view and
enter the notes, which I will mention as the “paper”. These three parts together form a piano roll.
Also, there will be scrollbars and a toolbar, and an envelope editor below.

A primary goal I’ve set for this PR is that everything should be accessible by your computer keyboard,
contrary to the common practice to force the user to use the mouse all the time. Entering notes will
be just as fast and easy, if not faster than in the pattern editor. Of course, full mouse support will
also be given for those who want that.

The PR will be zoomable and scrollable in both directions, independent of where the edit cursor is.
The edit cursor will be like the timeline in normal sequencers, with the addition of a marking (a cross
or something else) on the line for showing pitch position. This allows for (de)selection not unlike
in the pattern editor (ctrl+B/E).

The ruler will have marks for:

  • Ticks
  • Lines or rows in pattern editor (taking varying speed into account)
  • Beats (24 ticks)
    And of course line numbers.

There will be an editstep like in the pattern editor, and this will be selectable in both ticks or lines.
Ticks will also be selectable as note sizes (for those who can read scores).

In addition, there will be another setting; notelength, which is the length the following
inserted notes will have.

When inserting notes, the note column with space best fitting the selected notelength will be
chosen, and noteoffs will be inserted automatically if necressary to set the note lengths. If
there are no columns available with enough space, there are two options: shortening the note
to fit the best column, or rearranging the notecolumns if possible. The rearranging will be possible
to turn on/off, since it will modify the structure of the track. If rearranging is not possible, and the
columns are simply full, a status bar message will be shown.

When rearranging, moving a note will also move the contents of the volume- and panningcolumn
from the note position and to the next note in the column. Later, I might also implement some
sort of graphical editing of these columns. I’ve been thinking of some sort of popup note
envelopes for this purpose. But this will not be in the first stage anyway.

Selections will be completely flexible, allowing any notes to be (de)selected individually
and in groups by timerange, noterange or both.

There will be a range of operations working on the current selection:

  • Delete/cut/copy
  • Transpose up/down halfnote or octave
  • Move (in time)
  • Resizing
  • Anything else?

Selecting and deselecting can be done in the following ways:
By mouse (left button selects, right button deselects):

  • Dragging the ruler (de)selects all notes starting within the timerange.
  • Dragging the piano (de)selects all notes with pitch within the dragged range.
  • Pressing a piano key (de)selects all notes with this pitch.
  • Dragging over the paper selects the notes starting within this rectangle.
  • Clicking a note on the paper.
    By keyboard:
  • Ctrl+B begins selection, move cursor with regular keys, ctrl+E ends it.

Phew. Long post :)
Something I’ve forgotten?
Something you’d like to see different?
Other comments?
I will listen to all constructive criticism, but please don’t make any
“piano rolls sux” posts in this thread.

1 Like

I can only repeat what I already said : great. fantastic. cant wait to see this :)

1 Like

…piano rolls sux… hehe no just kidding :) :P

I like the idea very much but still I find it hard to grasp everything at once as I figure you Martinal have done much more thinking of this. One thing that springs to my mind right away though…

There has been much discussion about ticks not beeing enough accurate for note resolution. If a more precise resolution will be introduced in Renoise will the whole piano roll have to be rewritten? Maybe something to consider when implementing it at least…

The big challenge will be to actually see this WORK in a tracker, as an extension of the tracker itself rather than an alternative, which is the main reason why people say those infamous words I dear not repet about the roll of the piano…

So, the obvious thing that should be done, is to let the sequence KEEP going down, not like in those scetches previously done that gives some alternative screen for pianorolling, thus increasing such hatred made for given method.

Now, another thing that should be taken into concideration, is to let the rolls exist alongside the original track view somehow, have plans to make my own scetches but time will show the meaning of my words. For now, more ideas should follow first, Johan has a point in that perfection should come before implementation.

Sorry about the language, just saw Lord Of The Rings: Two Towers… Sweeeet!! B)

I’m not sure what you mean by “extension” rather than “alternative”. This piano roll will be an extension in the way that it’s only an editor of the pattern data, and thus you can switch between the PR and pattern editor. Nobody loses. And I think a lot of people hate PR’s because of the lack of keyboard support, the mouse editing can be quite tedious. Not so in this one.

You mean time going vertical instead of horizontal?
I’ve thought about it, and maybe I’ll try having it as an option. But I’m a bit sceptical.
It is really only a matter of swapping x and y axes everywhere, so theres not much brainwork involved to do that, only a bit of writing. Won’t do this in the first stage at least.

Thougth of that one too, a bit more sceptical to that one. And I think it would be a lot more work…
However, to edit more than one track at a time, a feature I’d like to do for a later addition is multitrack editing, much like in Sonar. The idea is: you select a list of tracks to edit, and only one is active at a time. The others are drawn on the same paper, in a shaded color. This way you can edit chords and rythms across tracks in the piano roll too. But that’s another feature for the next stage.

At least for the time being, I will not allow pianoroll and patterneditor open at the same time. This would complicate things quite a bit, and to be honest I don’t see the point. Remember that the piano roll needs a lot of screen space to be useful.

Too true… Can’t wait for the last one. Imagine seeing all three, extended versions of course, in a row :)

You bet… I’ve thrown away quite a load of ideas.

I’ve thought about this. The wonders of Object Oriented programming come to rescue :)
I keep the timing parts encapsulated in the ruler, so it shouldn’t be a problem.
It might introduce the need for a couple more features, though. Like quantization :)

Actually, there is a problem I don’t think it’s possible to get around: <_<
You should be able to edit timing (noteon/offs) tick-accurate, and the piano roll will handle the delay commands. When the PR is opened, the speed changes through a pattern is read, and used as a base for timing. From the beginning of the pattern the default speed will be used. But when the pattern is played after other different patterns with speed changes, the speed may be different than the default one. So the viewed timingbase in the PR will be wrong. But this only happens if you do a lot of fancy speed changing, so I guess I’ll just let it go… And put a warning in the help file.

Hmm… I could at least read the last speed change from the previous pattern. Solves a bit of it.
Writing down your problems sure helps some times :lol:

The only things I can think of (and sorry if you covered any of these already)

1> Snap to grid feature with different values. This is where you can enable the snap to grid so that all your bars on the piano roll will start on the 4/4 lines , 1/16 lines etc. It is a good idea to allow this feature to be disabled so free form drawing of bars can occur, this is very useful when writing anything “off tune”.

2> Resizing feature. So when you have written in your bars you can go back in and make one bar play longer by simply selecting it and draging thge mouse from the right hand side of the bar to make it play longer/shorter.

I hope I explained that right but if not just let me know and I will go into as much detail as possible.

Both are good ideas, and are planned although I didn’t write them above.

To make all the wanted functionality available with keyboard shortcuts, I need quite a lot of keys…
The problem is that both ctrl and shift + arrows are already used by pattern and instrument navigation.
One solution is to redesign the whole standard hotkeys structure (which I’ll probably do for myself at least).
But an even better solution than using the arrows for moving might be using the numpad, which allows diagonal movement as well. The keys assigned here are not so widely used, I believe?

We need shortcuts for moving the cursor, zooming in/out in both directions and scrolling in all directions, (de)selecting, note inserting, actions on selections, as well as changing editstep (gridsize), notelength, and snap to grid (on/off).

A recent discussion with taktik resulted in that I will use lines as the time base, with delays 0-ff within each line for more accurate positioning. This will be implemented as a new column in the patterneditor, and be supported by the player. At least in the first version, I will ignore speed changes through the pattern. Later I might deal with that more detailed.

Another idea that popped into my head (for later versions) is drumtracks. This can easily be implemented using most of the piano roll code but using diamonds like in cubase (or another symbol) to draw noteons, just ignoring noteoffs and note lengths, as well as using a drummap to assign different instruments and pitches to each pianokey-number. The “piano” is drawed instead as a list with the names of the instruments. Or perhaps “Instrument: sample”, extracting the sample name according to the splits set up for the instrument. This won’t be a big deal I think, but quite useful?

Martinal look my example:

link are: Piano Roll

Piano Roll open New era in Tracker scene.

Good Work Man.

B)

I have to say the same ;) This sounds realy cool, can’t wait to see it :)

Seems intresting, this would be really cool. :) :)

Keep up the good work renoise team.

Best regards,

Jeroen B)

@Maurizio Giannelli → Cool!

this is FruityLoops PR, isnt it ? ;)

LOL yes, but the keys does look great, dont they? :rolleyes:

Ohh but actually this pianoroll will rule, i imagine composing a tune in the tracker (coz its fast), and then fine tweak things with the pianoroll, move notes around, make them a little out of sync to simulate a strum on a guitar for instance.

I am kinda getting excited of this pianoroll thing suddenly… hmmm spooky.

speaking of appearance: any ideas for which parts of the roll might be skinned? PR’s are a lot of lines, but backgrounds and piano keys can at least be bitmaps.

btw : have we already discussed if the timeline should scroll vertical or horizontal ? when scrolling vertical you could show more than one PR at once. This might be very usefull and kick all available PR’s :)

  1. Main reason for doing it the horizontal way :rolleyes: is that you have more workspace, and hence more overview. And PR people are used to this.

  2. I can see the logic in having it vertical though, since a keyboard is in front of you, and therefore should be placed on top. Maybe it works - maybe not, i think you have to try it to really get into this idea.

i’m a tracker, if you do it horizontal i’ll put my monitor sidelong.

i think i would be confused with a vertical view. although my keybords goes from left to right, the notes in my head go up and down…

and i think the overview is an important aspect here, with horizontal view one could maybe see a whole 64lines pattern at once, which would be a great thing.

on the other hand, with vertical PR and splitscreen, you could see your beats with pianoroll and trackerview at the same time… may be handy as well :)