EOF 1.8RC13 - Now with Immerrock support

[Oddbrother]

I've never seen that Harmonix has done so with any of their charts.

On the contrary, they've done this since the beginning of DLC. Take the first break section to Metallica's "...And Justice for All" for example.

While the tempo complies depending on the set of notes closest together, it immediately changes from the first and last note in each.

Despite ignoring the guidelines to change tempo on, it helps to better signal the player to take a short break in between sets of notes.

[raynebc]

Looks like Harmonix does do that after all. I suppose I can see why they might do it to affect beat lines to help players with note rhythm, but it still feels sloppy to me. That song in particular is more unusual than most of the DLC, considering the number of TS changes it uses. It might be awkward to allow mid-beat tempo/TS changes/text events in EOF, since it's designed for those changes to be on beat markers for simplified beat syncing. If such support was implemented, it might just have to show up in a list (similar to how "all events" lists the text events, but perhaps there could be a way to make them show up in the editor window as well. This would probably be a low priority item on my list, although it would probably be easier for me to add the ability to import a MIDI's tempo map and BEAT track, so people can make pro guitar upgrades for Rock Band/RBN songs that do have mid beat changes. Let me know what you think.

[Oddbrother]

It might be awkward to allow mid-beat tempo/TS changes/text events in EOF, since it's designed for those changes to be on beat markers for simplified beat syncing. If such support was implemented, it might just have to show up in a list (similar to how "all events" lists the text events, but perhaps there could be a way to make them show up in the editor window as well. This would probably be a low priority item on my list, although it would probably be easier for me to add the ability to import a MIDI's tempo map and BEAT track, so people can make pro guitar upgrades for Rock Band/RBN songs that do have mid beat changes. Let me know what you think.

If you have more than one way of implementing this (hopefully), I'd love to test them on your next revisions to see how they will work out.

[davidsevenfold]

If there's a possibility, I'm all for it.

I'll even build from source as soon as you get a new revision up. :P

I agree with everything and anything that oddbro says

[raynebc]

It's time for another beta release. Changes since 1.8b31:

*Added logic so that GH import will make a backup of song.ini in the imported chart's folder if the backup (song.ini.backup) doesn't exist.
*Fixed a bug where song.ini wasn't imported during GH import.
*Improved song.ini import so that difficulty tags with a value of -1 are discarded, as they are created automatically during save if they are relevant.
*Improved song.ini import to discard Sysex marker related entries, as they are created automatically during save if they are relevant.
*Improved GH import so that the open strum bass option is enabled automatically if any lane 6 bass guitar gems are imported.
*Added logic allowing lane 1 (snare) drum notes to be marked with hi hat statuses, as this may be necessary for special uses such as when disco flip is in effect and hi hat notes are authored as snares.
*Fixed a bug where the user-defined song path is replaced by the path to EOF's program folder.
*Added support for importing section names from "NOTE" format Guitar Hero files. Section import for QB files is not yet completed.

If you have more than one way of implementing this (hopefully), I'd love to test them on your next revisions to see how they will work out.

I'll probably have to start with allowing track 0 (the tempo track) to be stored into the project and used during MIDI export instead of using the project's own tempo mapping. This should be sufficient for modifying an existing RB/RBN track to include pro guitar, keys, etc. How about I have EOF offer to store the original tempo mapping (and BEAT track if it exists) in this way if the imported MIDI has any mid-beat tempo or TS changes? This should be much less complicated than making all the changes necessary for allowing changes to be applied and not assigned to beat markers.

I will be out most of next week, so if anybody needs to revert back to beta 31, they can get it here.

[Oddbrother]

I'll probably have to start with allowing track 0 (the tempo track) to be stored into the project and used during MIDI export instead of using the project's own tempo mapping. This should be sufficient for modifying an existing RB/RBN track to include pro guitar, keys, etc. How about I have EOF offer to store the original tempo mapping (and BEAT track if it exists) in this way if the imported MIDI has any mid-beat tempo or TS changes? This should be much less complicated than making all the changes necessary for allowing changes to be applied and not assigned to beat markers.

This I'm definitely all for, especially since it will be easy to clean up thereafter. It would be extremely helpful.

[davidsevenfold]

feature request:
enable the search for notes that have a tail length of 1, and edit them all simultaneously, as a GH3 charter, theres huge compatibility issues with notes with a tail length of 1, it gets all messy in-game, it would save a lot of time, also, a feature to choose minimum tail lenght, or a lock on the tail lenght throughout charting the song regardless of the bpm unless manually making the tail lengths longer, this would be a great add in :D!! love your work btw

this is what happens when the tail lengths are at 1, as you can see, this is a bot failing, therefore its unplayable

[raynebc]

This I'm definitely all for, especially since it will be easy to clean up thereafter. It would be extremely helpful.

I'll try to get it working for the next beta.

feature request:
enable the search for notes that have a tail length of 1, and edit them all simultaneously, as a GH3 charter, theres huge compatibility issues with notes with a tail length of 1, it gets all messy in-game, it would save a lot of time, also, a feature to choose minimum tail lenght, or a lock on the tail lenght throughout charting the song regardless of the bpm unless manually making the tail lengths longer, this would be a great add in :D!! love your work btw

I could do a couple of different things, but I don't know if it would be useful to have both of them:
1. The ability to select all notes in the current track difficulty that are shorter than a specified length in milliseconds.
2. A preference defining the minimum length for all exported notes.

this is what happens when the tail lengths are at 1, as you can see, this is a bot failing, therefore its unplayable

Does this happen for drum tracks also? EOF has been hard coded to write 1ms drum notes due to problems in FoF/FoFiX, so I might have to go with option 2 above to override this behavior.

[davidsevenfold]

this is what happens when the tail lengths are at 1, as you can see, this is a bot failing, therefore its unplayable

Does this happen for drum tracks also? EOF has been hard coded to write 1ms drum notes due to problems in FoF/FoFiX, so I might have to go with option 2 above to override this behavior.

drum tracks cant be imported to GH3 silly :)

anyways. the 1ms length is only an issue in compatibility for GH3, so theres no need to change the ms on drums at all, although I'll accept anything that can make mine (and possible others) life easier :D?

[Bigjoe5]

For some weird reason, EOF is exporting some (but not all) notes in the drums track as ending on the beat rather than starting on it. These notes are showing up in Reaper as 2ms-long notes that end exactly on the beat on which they're supposed to begin. Doesn't seem like a big deal, I know, but Magma was giving me some errors about drum fills not lining up with gems, and changing all the relevant notes to start on the beat fixed the issue. Oddly, the drum fills themselves are often 2 ms early as well, but Magma wouldn't let me pass until the fill ended exactly on the beat, and the note started exactly on the beat, even if the end of the fill was technically lining up with the start of the note.

This may or may not be related to another issue I'm having where the note right before a drum fill (which should really be the first beat of the fill and be hidden) is being shown, and it looks kinda silly to have the note right at the start of the fill like that...

Thirdly, EOF allows the user to write the [end] event into the events track, and will write it into the events track in the rbn midi, but the beat track will keep going afterwards, which causes Magma errors.

And lastly, when using midi directly exported from EOF, Magma gives a ton of ridiculous errors about "double notes" or some such... Just opening the midi with Reaper and re-exporting it is enough to get rid of those errors.

[raynebc]

Could you provide any sample files that produce these problems?

[Bigjoe5]

http://www.sendspace.com/file/opk118

The above project has all the maladies I mentioned (and some unrelated errors about practice sections).

[raynebc]

For some weird reason, EOF is exporting some (but not all) notes in the drums track as ending on the beat rather than starting on it. These notes are showing up in Reaper as 2ms-long notes that end exactly on the beat on which they're supposed to begin.

Could you give some sample time stamps for where this occurs?

Thirdly, EOF allows the user to write the [end] event into the events track, and will write it into the events track in the rbn midi, but the beat track will keep going afterwards, which causes Magma errors.

I'll have to add logic to look for a user-defined end event and skip writing any MIDI items that occur after it.

And lastly, when using midi directly exported from EOF, Magma gives a ton of ridiculous errors about "double notes" or some such... Just opening the midi with Reaper and re-exporting it is enough to get rid of those errors.

I have fixed this issue.

Regarding the practice section errors, I think you just have to replace them with ones from the allowed list:
http://creators.rockband.com/docs/All_Practice_Sections

[Bigjoe5]

For some weird reason, EOF is exporting some (but not all) notes in the drums track as ending on the beat rather than starting on it. These notes are showing up in Reaper as 2ms-long notes that end exactly on the beat on which they're supposed to begin.

Could you give some sample time stamps for where this occurs?

The drum notes at measure 59.3 in the midi I provided are like this. The beat before is also like this, and it shouldn't take too much searching in that general vicinity to find several more.

[raynebc]

For some weird reason, EOF is exporting some (but not all) notes in the drums track as ending on the beat rather than starting on it. These notes are showing up in Reaper as 2ms-long notes that end exactly on the beat on which they're supposed to begin.

This is a timing conversion issue, but I added some special logic so that if a MIDI event is only 1 delta tick away from a beat, that event is moved to line up with the beat. This resolved the errors regarding the drum fills.

Thirdly, EOF allows the user to write the [end] event into the events track, and will write it into the events track in the rbn midi, but the beat track will keep going afterwards, which causes Magma errors.

I've added logic so that events that follow a user-defined [end] event are omitted. I'm going to leave it up to the user to ensure that notes are not made long enough to surpass the [end] event.

After those adjustments and removing the invalid practice section names, Magma happily accepted the MIDI. Please let me know if you find any other problems where EOF's MIDIs won't compile in Magma.