You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Display the instrument notes in ascending order of pitch, with the instrument that tends to play notes closer to A1 on the left, the one that's closer to G5 (or whatever is the max) at the right, and the other instrument in between. There doesn't seem to be a standard for this, but most of the files I've tried have the main melody in blue (left), accompaniment in magenta (middle) and bass notes in red (right); whereas I'd prefer them to be in the opposite order. If this could be determined from the track data and kept stable for the duration of a track, that'd be ideal.
Provide the ability to toggle between a horizontal and vertical display for the notes, with the vertical one displaying low notes at the bottom.
Try to determine the key of the track (or track portion), and display ♭ rather than ♯ accordingly. As an example, the key of F contains one flat (B♭), but MiniGBS will currently display that as A♯ which just looks super weird!
Enable the ability to continue on to the next track upon reaching a repeat point, instead of repeating. It could be a one-hit thing, so only continues from the current track to the next, or could persist, so keeps on continuing past the repeat points of all tracks. ncmpcpp has "single mode" bound to y by default, which simply plays the current track and then stops, so it'd be a super smooth transition for me if MiniGBS were to use y for its one-hit continue thing, and maybe Y for the persistently continue.
Add a key binding for "replay" to Enter, to save me having to travel all the way to ↑! [edit: Not necessary, because we have r]
The text was updated successfully, but these errors were encountered:
For point 1: The order the notes display is currently to line up with the associated registers, but a mode that changes them based on pitch could be interesting. I imagine the only way of doing this in a stable manner would be to silently simulate the track and analyse the values being written to each channel's frequency register for a short time before playing the track proper.
Point 2: A vertical display could be fun, I imagine it could track the notes over time as a sort of "line" graph (within ncurses limitations).
Point 3: Currently each frequency is simply mapped to a single note string, using only sharps. This is similar to what I've seen in programs like milkytracker, but I imagine if some simulation was done beforehand like in Point 1, then the track's key could maybe be determined, and the note strings chosen accordingly. I'm not particularly knowledgeable of the music theory side of things, so don't exactly know what I would be looking for here :P
Point 4: It would be nice, but the files don't provide any metadata about repeat points, and since the songs are arbitrary programs with their own sound drivers, I don't think there would be a reliable way of determining when one is repeating. However, the end of a song can be found by seeing if no registers change or the volume is 0 for N seconds, at which point it could repeat or move on to the next song. I had implemented the first of these two checks, but I think I broke it recently.
y
by default, which simply plays the current track and then stops, so it'd be a super smooth transition for me if MiniGBS were to usey
for its one-hit continue thing, and maybeY
for the persistently continue.Add a key binding for "replay" to[edit: Not necessary, because we haveEnter
, to save me having to travel all the way to↑
!r
]The text was updated successfully, but these errors were encountered: