m0j0hn / editor-on-fire Goto Github PK

If all notes in a lyric phrase are moved outside of the defined phrase
marking, the phrase is not deleted (although the instrument solo/SP phrases
perform this cleanup).

Left clicking on a lyric entry doesn't play the lyric's pitch unless vocal
tones are on. It took me a moment to realize this, since this requirement
doesn't seem to be mentioned in keys.txt

This seems to be the behavior by design, so keys.txt just needs to be updated.

EOF's logic to reset the condition of whether notes are present during 
instrument changing seems a little uneven. I can use keyboard operations to 
change from tracks that have notes to tracks that don't and then invoke 
"Test in FOF" for an instrument difficulty that has no notes without EOF 
refusing to test it because it has no notes.

When moving a lyric pitch by an entire octave with CTRL+Up/Down, performing 
Undo shows that EOF performed the pitch change operation by performing 12 
individual pitch increments/decrements, with an undo state made after each. 
The problem with this is that there are not enough undo states to return the 
note to its original position.

EOF does not allow Beat>Add to be used when the very first beat marker is 
selected, even though EOF allows the operation when any other anchor is 
selected.

"Split Lyric" is always available in the Note menu (SHIFT+L seems to be 
properly suppressed), even when PART VOCALS isn't active, even when there 
are no lyric tokens in PART VOCALS. If there are no lyrics, and split lyric 
is activated, EOF displays gibberish in the Split Lyric dialog window (such 
as "g^^^^^^"). EOF allows the lyric token to be changed, and when undo is 
performed to reverse the effect of this, EOF crashes. It's possible that 
various other operations after the glitched lyric split occurs could cause a 
crash as well.

"Select All" is disabled in the Note menu in PART VOCALS unless the 
previously selected track (before switching to PART VOCALS) had one or more 
notes in it. Even when the menu item is disabled, CTRL-E can be used.

If the song title field in Song Properties is entered with a sufficient
amount of text (I have found 236 characters to be sufficient), EOF crashes
when OK is used to close the Song Properties window. I imagine that many of
the text input fields aren't capped to prevent a buffer overflow. Consider
capping all text input fields to a low number (except for Loading Text,
which should be allowed to have something higher, perhaps 200). Some extra
code to force a cap to prevent buffer overflow would be a good protection
as well as forcing a cap in the UI.

EOF allows the buffer size to be set lower than 1024, but when playback is 
attempted, EOF indicates it cannot play the song and gives no reason why. 
Consider rejecting any given buffer size that is lower than 1024.

When using Guitar Tap in PART DRUMS, if any of the configured guitar or
drum controller buttons are pressed, EOF places drum notes at a rapid rate
instead of the "place one gem and suppress others until the button is
released and repressed" behavior of other instrument tracks.

I found that the CTRL+click on the full piano changes the pitch of the last
clicked lyric. However, making a pitch change this way doesn't mark the
chart as modified so it cannot be undone. This feature is also affected by
the click, CTRL+click bug that will allow a note operation to affect a note
that was deselected.

In the edit lyric dialog window, I have found that the lowercase L key
produces a character that is almost completely indiscernable from how it
displays the number one. It is pixel-for-pixel the exact same, the only
difference I can find is that the one character is given more spacing. Does
EOF have a better character that can be used for the letter l (ie. the top
serif should be at the top and not lowered a couple pixels, the way that
the "1" character usually is).

This is a limitation of the font itself.  Either the font can be replaced,
or perhaps the PCX file for the font can be touched up.

If Beat>Anchor Beat is used and a timestamp is given that causes EOF to
prevent the operation (ie. if it would pass beyond another existing
anchor), EOF still marks the chart as modified even though no change was
carried out.

EOF indicates that MIDI import reaches 100% completion, even if it is doing
something else (parsing lyrics or building lyric structures).  On a
sufficiently-large MIDI with thousands of lyrics, I saw that after the
counter reached 100%, EOF continued processing for a couple minutes.  This
counter's logic might need to be altered to take lyric import into account.

If a lyric phrase is marked and then undone, EOF will not allow a lyric
phrase to be placed containing any notes that were in that undone phrase
until another lyric phrase marking is performed.

The lyric preview doesn't update properly when using Beat>All Events>Find.
Ie. when I'm on the first lyric of a song, the preview shows the first two
lines' worth, but seeking to a text event beyond the last defined lyric
line, EOF shows the chart's second lyric until I seek backward to the last
defined lyric phrase, and then EOF updates the lyric preview.

I don't recall if there are other seek operations (ie. seek to bookmark)
that similarly cause the lyric preview to not be updated.

In the default EOF display size of 640x480, the info panel isn't wide
enough to display the information for the selected lyric. The lyric text
gets cut off. I'm not sure what options there are besides displaying this
information on more than one line in the info panel or removing some of the
spacing.

If a Beat>Anchor Beat is attempted, EOF may prevent the beat from being
moved and instead anchors it at its current position, even if the timestamp
specified is valid. For example, create a new chart with default tempo,
anchor the beat at 4 seconds, select the beat at 3 seconds and use
Beat>Anchor beat to try to anchor it to 00:03:50. EOF anchors the beat at
00:03:00 instead, even though 00:03:50 should be valid, and can be done by
using the mouse.

EOF allows CTRL+# (non numpad) to toggle notes during playback.  Under
unknown conditions, perhaps such as after performing an undo and then
trying this, or causing a toggle that overlaps existing notes, I've been
able to crash EOF while performing this bug repeatedly during playback.  I
was not able to reproduce this in PART VOCALS or any instrument track
besides PART DRUMS.  Here's the stack trace:
#0 7D62BB15 ??() (??:??)
#1 7D684C0A ??() (??:??)
#2 7D6568BE ??() (??:??)
#3 7D62B846 ??() (??:??)
#4 77BBD08C msvcrt!malloc() (F:\WINDOWS\syswow64\msvcrt.dll:??)
#5 6169C4C1 uvszprintf(buf=0x22fad0 "\030?Œ\003ØŸ–\003…", size=512,
format=0x4aa3c0 "%02d:%02d", args=0x22fcfc "") (F:/allegro/src/unicode.c:3068)
#6 61695E8F textprintf_ex(bmp=0x38c3078, f=0x39bffe0, x=756, y=31,
color=16777215, bg=-1, format=0x4aa3c0 "%02d:%02d") (F:/allegro/src/text.c:155)
#7 0045C6D4 eof_render_editor_window()
(D:/downloads/FretsOnFire/eof-1.63beta6-src/src/editor.c:4323)
#8 0047B1FA eof_render()
(D:/downloads/FretsOnFire/eof-1.63beta6-src/src/main.c:2286)
#9 0047C8B7 _mangled_main(argc=1, argv=0x3f4650)
(D:/downloads/FretsOnFire/eof-1.63beta6-src/src/main.c:2833)
#10 616C5E7B _WinMain(_main=0x47c853, hInst=0x400000, hPrev=0x0,
Cmd=0x7d20a4 "", nShow=10) (F:/allegro/src/win/wsystem.c:541)
#11 0047CB35 WinMain(hInst=0x400000, hPrev=0x0, Cmd=0x7d20a4 "", nShow=10)
(D:/downloads/FretsOnFire/eof-1.63beta6-src/src/main.c:2941)
#12 0048DD16 main() (??:??)

The best fix would probably be to ensure that Toggle Notes is disabled for
PART DRUMS during playback, as I'm not aware of any way to invoke it when
the chart is paused unless notes are actually selected.

When I define a controller button, EOF displays the word "button" twice,
ie: Joy 0 Button Button 1. My guess is that the button name in the joy[]
array already includes the substring "button", so you might not have to add it.

If a chart is loaded and guitar.ogg in the wrong sample rate (ie. 22KHz),
EOF plays the song's audio correctly, but claps are sampled in the wrong
rate, and both ticks and claps play out of time with the chart.

Several note based operations will apply to the last clicked note/lyric
even if that click was a deselect that left 0 notes selected.  The deselect
note/lyric logic should probably be updated to check to see if 0 notes are
left in the selection, if so, perform the "Deselect All" logic to ensure
that note operations won't be allowed to carry out in this circumstance.

EOF can reach a state where it graphically stutters every time playback is
started and stopped after lowering the AV delay to something like 100 and
disabling vsync. Upping the delay to something like 300 removes the
stutter, but extracting EOF from zip to clear the config fixes it until the
settings are configured again to induce this. It seems to be related to the
condition where the documentation indicates that at the beginning of
playback, the chart scrolls fast and then it evens out to normal speed. If
vsync is disabled, this seems to be shown as a stutter.

After a lyric is added, the lyric is not properly selected. The info panel
shows the lyric's information, but indicates 0 lyrics are selected. This
requires a mouse click to fix the selection so that a change in lyric
duration or other operations can be performed. Oddly, in this state, a Save
operation corrects the selection to indicate that 1 lyric is selected.

Guitar tap places notes that are noticeably later than they should be,
regardless of grid snap. For example, using guitar tap to place notes on a
beat synced chart, all notes are found to be placed out of sync during
playback.

I can't remember if this same issue occurs in Guitar Strum input method.

When a lyric move is attempted with a small grid snap value (ie. 1/48), the
movement can be erratic. This seems to be caused on generally any lyric
shorter than an undetermined length. For example, on this chart:
http://www.sendspace.com/file/cwoa0h , set grid snap to 1/48 and drag any
of several lyrics left one snap position to see EOF move them one snap
position to the right instead. Set grid snap to 1/4 and drag the 9th lyric
("night") left one snap position to see EOF move it right to the next beat
marker.

EOF allows Edit Lyric, Split Lyric and possibly other PART VOCALS functions
to occur when more than one lyric is selected, seemingly performing the
operation on the last lyric that was added to the selection.

Doing a MIDI import for "I think I'm paranoid" loaded no lyric text, so I
used F8 and the lyrics loaded. I played for a bit with vocal tones. Then I
did a MIDI import for "White Wedding" and EOF terminated without error.

I'll need to work on the functions in the lc_import function, as plenty of
logic has been changed.

When a lyric is moved left so that it is on another lyric's tail, the
duration is not truncated, allowing the lyrics to overlap.

When playing with the Guitar Tap drum glitch (see issue #13), I was able to
cause EOF to crash multiple times, by causing the repeating trail of notes
to run over notes that were already placed. This can be reproduced by
trying to make different trails of notes overlap others:
http://i15.photobucket.com/albums/a354/raynebc/eof163b6guitartapdrumcrash.jpg

I deleted all lyrics, and EOF replaced them with strange text such as 
"4u^^g^" repeating in the lyric preview in the 3d panel.

When using Guitar Strum in PART DRUMS, if any of the configured drum
controller buttons are pressed, EOF places notes without requiring a strum.
However, the note is forced to sustain until either another note is placed
(and subsequently forced to sustain) or playback is stopped.

If a beat (let's say #x) has a time signature and a text event, and the
beat is deleted, the time signature is deleted, but the text event gets
re-assigned to beat #x-1.

Song>Track still refers to "PART DRUM" instead of the correct track name
(PART DRUMS).

"Split Lyric" is able to be used when more than one lyric is selected. When 
I did a select all and activated "Split Lyric" from the menu (SHIFT+L was 
suppressed), EOF crashed. SHIFT+L was not suppressed if I selected the first 
lyric and used SHIFT+End. Presumably, this is because no lyric token has to 
be initially selected to use CTRL-E.

I find that guitar tap and strum do work in PART VOCALS, but this does not
trigger EOF to mark the chart as modified. I found the modified status is
not set regardless of which track I edit with either of these input methods.

If a short lyric phrase (such as one syllable) is marked, during playback
EOF will remove that phrase from the lyric preview before the lyric is ever
reached and highlighted green.

By exploiting the lyric paste overlap bug (see issue #15), I did a select
all, copy, and then just held the CTRL key and alternated hitting right
arrow and B to paste over the chart until EOF had into tens of thousands of
lyrics. By the time EOF got somewhere around 32523 lyrics total, it crashed
on the next paste operation. Besides preventing paste if it overlaps
lyrics, EOF should prevent any lyric adding operation that would cause an
overflow.

When adjusting lyric durations in my vocal chart, I came to find that even
though I used 1/16 grid snap for almost all lyrics, EOF had made the
lyrics' durations shorter than 1/16, so extending them to 1/8 measure
length required two wheel scroll up operations (to bring it to 1/16 length,
and then 2/16). It seems that when placing lyrics, EOF doesn't make them
the expected length no matter what grid snap value is used.

After selecting the first lyric phrase in a chart and using Note>Lyric
Lines>Erase All, EOF removed the top of the two lines of lyrics that were
rendered in the full piano panel, but left the second line rendered. The
stuck line of lyrics was not removed despite seeking/playback and despite
there being no lines defined. At this point, EOF had trouble marking lyric
phrases in general unless I tried to mark one with lyrics that were beyond
those that were originally in the first lyric phrase.

Right clicking on a lyric entry (after the first two?) on the piano roll
causes EOF to crash (RexMundi input mode, possibly others as well).

Using Old Paste in PART VOCALS causes the pasted notes to be missing their
pitches.

This is a two part bug:

1. EOF prevents a lyric's duration from being increased to extend beyond
the end of the piano roll, but it does not prevent a lyric to be moved to
the edge of the piano roll so that its duration is depicted as displaying
past the edge of the piano roll.  This is similar to issue #40, where
lyrics aren't truncated if they overlap each other after a move operation.

2. If multiple lyrics are selected at once, and they are moved to the right
end of the piano roll, EOF prevents the lyrics from starting beyond the end
of the piano roll, but allows them to all overlap:
http://i15.photobucket.com/albums/a354/raynebc/eof163b6lyricedgemoveglitch.jpg

A good workaround is to prevent lyric movement if any of the selected
lyric's durations would run beyond the end of the piano roll. If it's
preferred to have the duration truncate instead, the movement should at
least be prevented if one of the selected lyrics is at the end of the piano
roll.

EOF doesn't seem to allow "Test in FOF" to be used for PART VOCALS.
Granted, I don't think FoFiX's devs fixed this functionality yet, but it
would be cool to be able to test a vocal chart this way when they do fix it.

If I have unsaved edits on a chart, try to load a chart that is missing
guitar.ogg, and cancel when it asks me to locate guitar.ogg, EOF closes the
chart that is open. However the chart modified status is not cleared, so
going to open a chart when none is open causes EOF to prompt for saving
changes. If I opt to save the changes, EOF crashes because no chart is open.

When editing a lyric's text, it seems EOF changes the lyric's duration
unexpectedly.

Keys.txt indicates that using insert when mousing over the full piano can
recenter the piano roll. This works in all input methods except RexMundi.

If a note already extends completely to the next note to the point where it
cannot be made longer, EOF marks the chart as modified if a note lengthen
operation (mouse scroll up or ']') is attempted, even though EOF prevents
the operation from being performed.

I haven't tested if attempting to shorten a note that is already the
minimum length causes the chart to be marked as modified, but it might.

EOF allows lyrics to be pasted (new paste) on top of other lyrics so that
they overlap:
http://i15.photobucket.com/albums/a354/raynebc/eof163b6pasteoverlapglitch.jpg

Old paste also overlaps, but it truncates lyric durations as a side effect.

After placing a pitched lyric, EOF sounds the lyric's tone every time I
start playback when the seek bar is after that note. I find that the same
tone sounds again each time I use the keyboard to change instruments and
instrument difficulties during playback. This doesn't occur if I begin
playback from a timestamp before the last placed note.