Closed GoogleCodeExporter closed 8 years ago
Typically, I see that RB "freestyle" lyrics (each of which have a # character
at the
end) do have a defined pitch. For example, all of the freestyle lyrics in
"Sabotage"
are pitch 72. Without checking other RB songs, I'm sure that it's fine to put
any
valid pitch with a "pitchless" lyric to ensure that it plays correctly in-game.
Lyrics that do have # at the end should be allowed to export, as this is the RB
way
to define freestyle, whereas defining a lyric with no Note On and Off to define
the
pitch is a nonstandard method. In order to make custom charts more ready to
work
with a hacked console, it may be best to have all lyrics that have no defined
pitch
be given a generic pitch in addition to having # appended during export.
To address Jrofl24's concern about an easier way to quickly mark several lyrics
as
freestyle, perhaps freestyle could become the next line flag status? That way,
a
user could mark an entire line phrase as freestyle. I think in most cases, if
people
have to mark several lyrics as freestyle all at once, it's because entire lyric
phrases need to be marked, so this would be an efficient way to do it.
Otherwise,
people would still have the ability to manually freestyle individual lyrics
with the
use of the pound character.
Original comment by raynebc
on 2 Jun 2010 at 4:42
Notes from issue 120 regarding pitchless lyrics:
We can either deal with them during export (appending a pound character and
assigning a pitch) or automatically append the pound character after the
pitchless lyric is placed. Since some users may place them as pitchless and
would assign the pitch later, it might annoy them if they had to remove the
pound character that was automatically added. One possible solution to this
would be to use a lyric status to track whether the lyric was automatically
made to be freestyle. If a lyric with this status had a pitch assigned later,
the pound character that was automatically appended to the lyric text could be
automatically removed.
Original comment by raynebc
on 15 Aug 2010 at 7:27
Completed in r323.
Original comment by raynebc
on 23 Aug 2010 at 10:17
There's a side effect in that if corrections are made, they are permanent and
persist after the save is completed. The only way to prevent this would
require calling eof_add_midi_lyric_event() with a corrected string and
eof_add_midi_event() with the corrected pitch, necessitating the duplication of
the lyric strings in memory, and their de-allocation at the end of the export.
I'll await your decision on whether we should implement it this way so the user
doesn't wonder why some of their lyrics were assigned a pitch when they saved.
Original comment by raynebc
on 23 Aug 2010 at 10:34
Pitchless corrections should be made to the MIDI only. The exported MIDI and
EOF's internal chart should be treated as separate entities. Changes to the EOF
chart should be made explicitly by the user and the export process should be
able to translate what the user has put in the chart into a correct MIDI that
works with the game(s).
I think there should also be a way to allow non-playable lyrics to be exported
since FoFiX supports them. The auto-correction makes sense for people making
playable lyrics so I think that should be the default. There should be some
kind of option but that is another issue.
Original comment by xander4j...@yahoo.com
on 2 Sep 2010 at 10:59
r345 applies the requested logic. The chart contents are not altered, only the
exported lyric and notes are affected by the freestyle correction. I can see
two ways to implement the option to export them as "non playable" lyrics:
1. Automatically determine whether correction should be used. For example, if
the user placed all lyrics as being pitchless, he/she obviously doesn't want it
to be playable, so the correction can be skipped. If the user has one or more
lyrics with a proper pitch, it could be assumed that it was intended to be
playable and the correction can be applied.
2. If there are one or more pitchless lyrics, prompt the user during save
operations about whether the freestyle should be corrected.
Both of these options involve pre-parsing the lyrics before building the PART
VOCALS track temp file, but the latter provides the most user control, so it
may be preferable.
Original comment by raynebc
on 3 Sep 2010 at 6:51
Completed in r357.
Original comment by raynebc
on 7 Sep 2010 at 9:57
Original issue reported on code.google.com by
xander4j...@yahoo.com
on 2 Jun 2010 at 3:47