PLEASE, remove silence notes

feature requests
1

Silence notes make absolutely no sense in a modern arranger. They’re such a big obstacle. There’s a reason they just don’t exist in any modern software arranger.

Why not let us just create notes along the fixed “grid” of note subdivisions and move and drag them around freely? Why force us to insert awkward silent notes to create pauses, instead of assuming an empty space with no notes is, surprise, a silence?

As if right now: Want to change a note’s position? Better be ready to manually adjust 1, the note 2, the silence note before it 3. the silence note after it

Seriously, check it out. You have to insert a silence note before it, and then MANUALLY CHOOSE THE APPROPRIATE SUMS OF FIXED NOTE LENGTHS WITH YOUR MOUSE WHILE HOLDING SHIFT ON A DIFFERENT MENU ON THE PRECEDING SILENCE NOTE, AND THEN REPEAT THE WHOLE PROCESS ON THE TRAILING SILENCE NOTES until the note you wanted to move ahead or earlier offsets in the right place.

Alternative: drag the note ahead or back with your mouse.

It wouldn’t even need a major overhaul of Hookpad. Programatically it just seems so absurdly easy to just let us create, drag, and drop notes anywhere on Hookpad’s fixed grid and then just transparently add an appropiately sized, invisible silence note on the spaces that might remain between notes as soon as you let go of your mouse button.

if previousNote.end.position != newNote.start.position
{
AddSilence(position(previousNote.End), length(newNote.start.position - previousNote.end.position)
}

Please, PLEASE consider adding this.

1 Like
2

This entire post sums up my dislikes of the Hookpad editor perfectly.

It’s not fun trying to figure out how long a rest is when I could just drag the note to the proper starting position.

3

Because dragging a note while making sure the current note does not overlap any other note on the same track makes even less sense than inputting silence notes rests.

In fact it is more difficult for people with experience in scorewriters or music markup languages to use an interface that does not have rests. It is only easier for people who have been using other piano rolls, and about the same for audio tracker users.

An ability to drag notes / chords horizontally, up to the extent of the adjacent rests, should be sufficient without breaking the overall experience of Hookpad. The empty space at the end of a row may also be treated as one of these rests when dragging notes / chords.

4

So I understand you’re saying Hookpad should, over all things, be intuitive to use to people who ALREADY know how to make music and already have experience with the use of score editors?

Also, what “doesn’t make sense” about “dragging a note while making sure the current note does not overlap any other note on the same track”? It’s painfully obvious that the intended behaviour on that case would be to have the note you’re dragging over another note cut that second note by however much amount you overlapped it over. Every graphical MIDI sequencer has worked this way since the beggining of the 90s to this day. Not to mention that even if wasn’t that intuitive for some reason (which it is), you could just disallow overlapping notes.

And by the way, you ALREADY have to manually check for “overlaps”, since if you overextend a note and it “overlaps” the next one, with the current system you displace the whole composition ahead of you.

[quote=“HertzDevil, post:3, topic:984”]
In fact it is more difficult for people with experience in scorewriters or music markup languages to use an interface that does not have rests. It is only easier for people who have been using other piano rolls, and about the same for audio tracker users.[/quote]

So it’d only be easier for 90% of the people who use this site? Will the remaining 10% experienced musicians really have that much of a hard time imagining a rest on the absence of notes, which is the definition of a rest?

5

Hookpad is meant to accompany the books that teach music theory, thus must not be counterintuitive to an environment where the rest has its own identity rather than merely as a placeholder for the absence of note events. There is a reason rests can be tied or broken up arbitrarily as though they are true note events (they are also reflected in exported piano sheets).

The only thing painful here is the amount of lag undoing would induce if dragging a note is allowed to erase any other note event on its way. Almost all piano roll sequencers do not have the notion of monophonic tracks, and this kind of destructive editing should only apply to rests and not other notes.

The program does not need to do this if notes are stored in a list with only duration information but having the time accumulated during run-time.

[quote=“CDEFGAB, post:4, topic:984”]
So it’d only be easier for 90% of the people who use this site? Will the remaining 10% experienced musicians really have that much of a hard time imagining a rest on the absence of notes, which is the definition of a rest?
[/quote]It will be easier for about 20% of the people and harder for about 30% to learn using Hookpad, and harder for about 70% of the people to continue using Hookpad; this is especially true when using Hookpad with the keyboard. Much fewer monophonic sequencer users (e.g. PxTone Collage) exist on this site.

Removing rests is what the title means and is different from allowing a new control method to move notes horizontally. So “transparently [adding] an appropiately sized, invisible silence note on the spaces that might remain between notes” should not happen, but “[dragging] the note ahead or back with your mouse” should, best with keyboard shortcuts to nudge the currently selected notes (maybe Ctrl+Left/Right). If the notes are indeed stored in a list, the code for a single note might be like this instead:

if next note event exists and is a note:
  return
if note event will become out of bounds after moving:
  return
if next note event exists and is a rest:
  shorten next note event by a grid unit
  if next note event has zero duration:
    delete next note event
if previous note event exists and is a rest:
  lengthen previous note event by a grid unit
else
  insert before current note event a rest that lasts for one grid unit

This should also work for multiply selected notes by applying to each note event in order.

6

My last post came out too aggressive; it really wasn’t my intention.

I said modify as in modify the start position, not erase the note, and even if it would erase it (which wouldn’t make a lot of sense), pressing Ctrl+Z doesn’t really seem like a “painful amount of lag”.

I understand what you mean but I don’t see how it relates to what you quoted. I meant “manually” as in literally manually check; if you accidentally input a note length too big, all the content after it is displaced beyond the intended amount, and with tiny changes and rests in the way it might not be immediately obvious.

I’ve re-read this several times and still don’t really get it, especially the 20%-30% parts. The immense majority of people use piano-roll like sequencers as opposed to scoring software and especially old-school trackers. I also strongly disagree with the 70% argument, as I don’t see how removing rests would affect anyone deeply, even if using only your keyboard (I assume you mean regular computer keyboard). You are not removing the feature, you’re just making it transparent.

Right now, for example, you’d input a note & its length, you’d input a silence/rest & its length, then you’d input a note & its length; without rests you’d input a note & its length, move the caret ahead by X with your arrow keys, then you’d input the second note & its length.

Now say you want to move both notes closer together (offset the first one head, the second one backwards).

Right now you have to change the rest size, then go back before the first note, then change that note’s previous note/rest length, then go ahead to the second note again, and make sure you didn’t displace everything ahead of it by these changes; without graphical rests you’d just drag/arrow key both notes closer. The first one ahead, the second one backwards. The rest is there behind the scenes, it’s position and length are simply calculated for you based on the space you left between the notes.

In short, from a code perspective the rest is still there; from a user perspective even if you only use your keyboard for inputs you’ve probably even had to press less keys overall, let alone input the rest lengths and compensate the whole thing when you want to change something’s length in the middle of a composition. Doesn’t seem all that radical.

7

This means either I have to tap the arrow key 12/16/24 times to move the cursor exactly one measure to the front, or hold down the button until the cursor reaches one measure into the empty space; how this is easier than just placing a whole note rest is beyond my comprehension. It also becomes more difficult to change rests back into notes when they are hidden, since the editor has to assume a default tying pattern for the automatically inserted rests.

Alt+mouse dragging note boundaries already reduces this to twice the number of operations required for horizontally dragging notes directly, a bit more if the previous or next note event is not a rest.

This may or may not be true considering Hookpad still lacks keyboard shortcuts for many mouse operations over the piano roll. Nudging selected notes will save time, but nudging the current cursor often does not (even though it has to be somehow implemented if features like Slash + Mouse are to be given shortcuts)…

When you have over 5~7 full rows with two or three tracks, any and every undo operation becomes a painful amount of lag under Flash Player. Almost all operations are but undoing takes even longer.

8

[quote=“HertzDevil, post:7, topic:984”]
This means either I have to tap the arrow key 12/16/24 times to move the cursor exactly one measure to the front, or hold down the button until the cursor reaches one measure into the empty space[/quote]
Oh come on. When you’re writing a post here and you want to change something in the last paragraph do you press the left arrow 179 times or do you just put the caret in place with the mouse? When you want to start a new paragraph do you manually insert a 37 character-long whitespace until you reach your desired line?

Even with the smallest possible note divisions in Hookpad it takes literally a half second for the caret to advance a whole bar pressing the arrow keys, and you STILL have the mouse if you want to make a big jump somewhere else.

Fair point, but it’s still double the operations required in the “drag two notes closer to each other” example. Repetitive interactions which have the exact same end purpose should be automatized and made transparent, it’s a basic of interface design.

So we can’t improve on this because it’s already lacking? I find that astounding, by the way. The code is obviously already there for these operations and unless they’re extremely hacky XY mouse position implementations binding them to shortcuts would be so easy. So add that to the feature request, I guess.

You’re 100% right there, the whole application is laggy as hell in every aspect. Extremely unaccurate for mouse operations in Chrome, too, which drives me nuts (click on a note, drag one pixel down and the note jumps down 7 or 8 pitches, for example). With that said, every new feature will likely add to that lag, but that’s in my opinion not a reason not to improve on it.

9

It differs across implementations; the fastest way of course is to type 179l or 179h in vim, but this is only useful if the underlying text file has the same kind of rhythm as a piano roll (e.g. tables). Even for sentences 12w is still much faster than wwwwwwwwwwww.

It should be added because the horizontal note dragging complements the dragging operation on note event boundaries, not because it saves operations in some situations and not in others. In fact that should be added regardless of whether rests remain visible or not, but hiding them leaves the note duration options available only to notes but not rests, and that is also a violation of interface design, because this destroys the identity of rests as note events when it is already possible to manipulate them in the same way notes are operated on.

10

:^)

(that’s not a violation of interface design)

What is the benefit of having separate customizable rests when rests are tied anyway to note starts and ends on any and all monophonic note tracks, and especially since note absences are already rests? The code to auto-fill gaps with rests is already there, too; it’s used when you record something (as in hitting the record button and all). The notes are quantized and rests are automatically added in between.

When you initialize a fixed-length array or list, and you want to store something on indexes 23 and 27, do you store them on indexes 0 and 1 and then manually write code to displace them separately until they reach your desired destination or do you just say “I want this thing at index 23 and 27” and everything is taken care of for you in the background?

Or hell, even put a checkbox to either show rests as notes or treat them as blank space.

11

The entire site in general is laggy as hell. My laptop is not the best, and another desktop computer I use is significantly more powerful than it. Even the desktop one with a great internet connection, it takes an unusually long time to load anything on the site when 25% of the page is just whitespace.

I would blame Flash, but I’ll wait until HTML5 Hookpad comes out to begin blaming things.

12
  • Uniform controls for notes and rests which streamlines the process of creating Hookpads. This is only possible because Hookpad uses monophonic tracks; they have to have been absent in the first place if it has a notion of true polyphonic tracks;
  • Deleting and resizing rests directly, instead of having to select everything else then moving them;
  • Changing between rests and notes, which permits a drum sequencer style workflow.

I stand corrected, since even Lilypad will merge/split rests on its own in a different manner than Hookpad.

They are not for the beats before the first measure’s pickup or after the last measure if it is incomplete (although the empty space after each row except the last is technically a rest).

Apart from the difference between overwriting and inserting elements, I think you mean calling functions instead of writing code because eventually your compiler will just do the same thing in the unlikely case the array is implemented as a linked list.

13

You can already control note ends and starts and thus rest ends and starts

The opposite argument can be made that you have to correct everything else’s position after resizing a rest

I agree, such a workflow is suited for…drum programming.

A difference which is exactly my point? One is a “concatenated” version of the other in most memory handling and allocation schemes. Hell, even in “modern” languages like C++ you have to manually delete old content in memory in lots of situations instead of plain overwriting or risk getting huge, steady, hard-to-debug memory leaks. Assignment operators for example.

I, too, love calling empty functions

That’s a brooooad assertion, but at any rate it’s exactly my point: you didn’t have to do it because the compiler did it for you. You CAN do it if you need or choose to, but you can also choose not to because it’s superfluous in many, many workflows and situations. Like rest notes! And right now, you can’t choose not to struggle with rest notes, and they get in the way of everyone not used to scoring software or oldschool trackers (most users).

I didn’t imply at all such an array implementation, how would you take that from what I said?

I enjoy discussing this with you but, please, let’s not turn this into a nerdism analogy-accuracy contest.

14

And not copying and pasting, so rests ought to be removed because there exists at least one user who cannot find a use case of copying and pasting rests.

Therefore it should be possible to drag note events horizontally, because both use cases occur equally often in Hookpad; besides dragging the ends of a rest (without Alt) does not alter the position of “everything” else on the same row. This is not an argument for rendering rests invisible to the eyes or transparent to the controls.

And editable drum tracks have been suggested (though not formally requested iirc), so this would be on the Hookpad to-do list.

What then happens to the existing elements on index 0 and 1? If you store them at index 23 and 27 directly, only these original entries will be erased; when you insert them in a fixed-length array, you decide to delete the first two entries before insertion:

std::array<int, /* large constant */> A;
// storing
A[27] = 0;
// inserting
A[1] = 0; for (int i = 2; i <= 27; ++i) std::swap(A[i], A[i - 1]);

It becomes slightly more complicated for variable-length arrays or vectors, but that might really be what you meant in this context.

C++ is not a truly modern language, but actual “modern” C++ code uses RAII and smart pointers to hide away many, many cases of manual memory deallocation.

virtual destructors : ) ) ) )

It is not; “manually write code to displace them separately until they reach your desired destination” means this:

// inserting "manually"
A[1] = 0;
std::swap(A[2], A[1]);
std::swap(A[3], A[2]);
std::swap(A[4], A[3]);
// ...
std::swap(A[27], A[26]);

It is rest notes that achieve this abstraction; instead of having to move the cursor by grid units to the target destination, you could now displace your cursor by the exact distance as desired. This is not superfluous, unrestrained cursor movement is superfluous in the context of single-track piano roll sequencers, and indeed will make it behave like an “old school” tracker more than a piano roll.

15

[quote=“HertzDevil, post:14, topic:984”]
And not copying and pasting, so rests ought to be removed because there exists at least one user who cannot find a use case of copying and pasting [/quote]
Look, I made the effort of taking your arguments seriously and try to argue for the opposite case, which I honestly believe in, without sarcasm towards you. With such replies it’s only fair for me to assume that you’re not willing to value my reasoning enough to not be sardonic, dismissive and almost mocking, which for whatever reason you found appropiate. So consider this argument “won”, I guess.