Many tabs use glitches to input 32nd notes. These tabs are hard to edit, as us editors do not want to break them.
It is sometimes hard to know what to do when seeing these 32nd notes. Currently, I am revamping literally all of Undertale’s soundtrack, so take my example for Bonetrousle. Do I notate it as best I can? Do I leave them out? Do I use glitches?
I would go with the 3rd transcription.
If we worry about visibility, this isn’t a problem when you realize 16th notes on tabs with 12 beats per bar are not visible at all. On default zoom, you can see 32nd notes perfectly fine both in tabs and in Hookpad as well.
And although the official workaround is to double the tempo, the transcription will show up big, and the instruments cannot be played at half the speed. We also want our tempos to be accurate as well.
I also want to say that glitches help make theorytabs better. Features you are not normally able to get such as slash chords make tabs more readable. 32nd notes would make tabs feel more real and be more accurate. I’d say the additional effort and detail is worth it.
How about this: we add a system for these small notes similar to how triplets currently work.
The default snapping is still 16th notes. This means that you drag and resize notes in intervals of 16th notes.
To get 32nd notes, use split on a 16th note. No matter where your mouse is at, as long as you target a 16th note, you will get two even 32nd notes.
Like triplets, they cannot be moved by dragging. They should also not be able to be resized by dragging. The only way to change their length is to use tie.
Which can also be used to make notes with lengths like 0.375, 1.125, etc.
Notes tied to a 32nd behave like a 32nd. No dragging them, as well as the other stuff further below.
This way, dealing with arbitrary places for notes shouldn’t be an issue. The default snap still works in terms of 16ths, so you will only ever deal with smaller note values exactly where you want them.
Deleting a 32nd note would turn it into a rest, much like triplets.
Like triplets and how 32nd notes work now, clicking on the staff will snap the blue line to the nearest 32nd note. If you decide to create a note in this offset, clicking the pitch you want will only change the pitch of the 32nd note after the line, and the note durations would be grayed out to reflect this.
This is different from how triplets would work now, as triplets will automatically be created if you create a note that demands being over one, however, 32nd notes would be too small to work with, and it can get out of hand quickly, so its best to just leave them where they have been created.
If you paste a selection over a beat offset by a 32nd note (or any arbitrary note length), the content will be offset to the nearest beat that is a multiple of 0.25, then pasted. If the selection is of a length that is not a multiple of 0.25, add a rest to cover that distance. If you paste content with 32nd notes, they should still pertain after pasting. The snapping is only for the beginning and the end.
16th note triplets would work much in the same way. You use split on an 8th note triplet.
But what if you decide to resize a note into a 32nd note? If it’s over a -3- that indicates a triplet, snap to the nearest multiple of 0.33. Otherwise, snap to the nearest 0.25.
64th notes, however, are too small and the demand for them isn’t high enough for them to be added. However, all arbitrary note lengths should still be unofficially supported through JSON editing, as to allow users who know how to use glitches be able to use them to make tabs more accurate. Irrational note lengths are evidently already supported.
Glitches should be embraced rather than discouraged. Glitches are fun, useful, and you have to purposefully cause most of them. Unless you can accidentally ruin your project with one, glitches should remain for those who want to take advantage of them.
One last thing, show the true length of the note if you click on it. As the note length when selecting a 32nd note currently just states “0”, and the exact note length is already stored in the JSON data.
Seeing as notes smaller than 16ths would be an anticipated feature, I would like lots of thoughts on this concept. Seeing as the main reason for not being supported is not knowing how they would work, I am confident they can finally be added if we make a great concept.
This post is also quite messy as well, feel free to reply if you want me to clarify anything or have some feedback on my idea.
1 post - 1 participant