Hi, folks.

I'll be using this thread to maintain the latest versions of EOF in one place. To start, download and extract EOF 1.8RC13:
https://ignition4.customsforge.com/eof

You can keep that zip file handy to avoid downloading it more than once. When I release a new hotfix, all you have to do is replace the files from the above zip file with the ones from the hotfix.  The latest hotfixes get posted in the same place:
https://ignition4.customsforge.com/eof

*If you use a non QWERTY US English keyboard layout, and keyboard controls/shortcuts aren't working for you, please make a post describing what keyboard shortcuts aren't working, and what the Info panel says the "CODE" and "ASCII" values are after you use each of the keyboard controls in question.

I used to make Mac releases, but Apple dropped support for 32 bit applications so the user base dwindled away and I can't port the entire application to 64 bit at this time.  The latest Mac build (2-7-2025) is here:
https://ignition4.customsforge.com/eof/download/17
Unless you have oggenc and LAME installed (these don't come with the Mac build for licensing reasons), you won't be able to have EOF automatically convert from MP3 to OGG when you create a new chart. If you have trouble getting those set up on your system, here is a package that should get them installed and usable by EOF:
http://www.t3-i.com/apps/eof/downloads/eof_utilities.pkg

Please provide any and all feedback, including bugs and feature requests. If possible, also please review the included documentation (manual, tutorials) and let me know if you find any room for improvement there. Eventually I plan to add a Rocksmith authoring section to the pro guitar tutorial, but the community's knowledge of the Rocksmith songs' makeup changes pretty quickly so it's hard to know when particular features are considered fully known. For any features that ARE fully known (like anchors), please feel free to remind me if they aren't incorporated into EOF yet, in case I missed any information being passed around on this forum or the Google group.

Note: If you are reporting a bug, please specify which hotfix (date) you're using. I release hotfixes on a somewhat random schedule, sometimes more than once per day, so the issue being reported may have been fixed in a release you haven't tried yet.

 

 

2) I took a guess that if I applied "hi dens" status to the "Chordified" chord, that the tag would set high density = "1", thereby authoring the high-density box (i.e. goal posts for 2-stringed power chords) but this is not part of Hotfix 03-13-2016.

I don't think I'd allowed for manually overriding the density yet, but I'll work on this.

 

(I'm wondering if the status name "chord box" will see less questions asked by users ...)

We can see what everybody else thinks, but I think your "chordify" code name is perfectly suitable for it.

 

EoF Authoring

<handShape chordId="0" endTime="2.501" startTime="2" /><handShape chordId="1" endTime="3.501" startTime="3" />

Reference Modded XML Case

<handShape chordId="0" endTime="2.001" startTime="2" /><handShape chordId="0" endTime="2.501" startTime="2.5" /><handShape chordId="1" endTime="3.001" startTime="3" /><handShape chordId="1" endTime="3.501" startTime="3.5" />

Is this intended? Should EoF export as the reference modded XML case or do we not want that?

Was there a reason each chordified note needed its own handshape tag in this example?  The half second handshape covering both chords in each chord change seems consistent with normal EOF behavior, so I think it makes the best default behavior since it would be easily predictable.  Separate handshape tags for each could be achieved by either manually authoring a handshape tag or marking a chord with both "crazy" "hi dens" statuses, with the noted exception that EOF still pads handshape tags to a minimum length of 56ms.

 

Another thing I'd like to test tomorrow is if I can manage to author- from EoF, with chordify, a box with no notes inside

I guess it depends on specifically what you're wanting.  If it's just no notes in the box, EOF should export it that way unless any of the notes require sustain or if any of the notes are open?  If you also want no handshape tag, that's probably not something EOF can export.

 

I cannot seem to find that post you made about a year ago either to me or to someone else, where I thought I remembered some EoF limitation whereby you recommended to very slightly de-synch two notes of a chord to get a desired authoring.

This was probably my recommendation for authoring a chord whose notes had different lengths, since EOF cannot internally store this and any two notes at the same position in a track difficulty are combined into one note and share the same length, etc.  The crazy status would have allowed the two single notes to overlap each other and appear like they were a chord.  This was likely before the linknext note combination logic was added and before it was found that some limitation would still cause the game to still show those different chord note lengths with the same length some/all of the time.  Using the chordify and linknext method works around those EOF and Rocksmith limitations to get the same effect but also with a chord box so that it looks like a chord the way the author intends it to in-game.

 

For now I suppose the best documented need for "chordify" is indeed a chord with differently sustaining strings.

That's my take on it as well.

I just wanted to suggest a new feature if it's possible to implement: The ability to cut selected song parts out of the project.

 

Right now I'm working on a breakdown of Les Miserables, and it would be a MASSIVE time saver if the lenth of the song could be altered. Basically what I'm having to do is use Reaper to breakdown the original mp3 into the individual songs to be edited in EOF, then I'll have to copy/paste the notes from the original EOF file to the new one, then have to go through and get the notes synced properly. As you can see, this is going to to take a long time to accomplish. If the audio could be cut in EOF, this project that will take months of work could easily be reduced to hours.

I can see how it would be useful for an unusual project like that, but I'm not sure it would be a very frequently used feature. Are you looking more for it to save a separate EOF project of a specific portion of the chart? That may end up being easier for me to implement than a selective export for each supported game format, plus it makes it easier to fix up each individual song. It probably wouldn't even be difficult to have EOF split up the audio, since it would be pretty much the same logic as what is used to create a preview audio file for the specified range of the song. Let me know if this sounds close enough to what you're looking for.

 

A good, complimentary function would then be to be able to append a selected EOF file to the open project. People could then splice together parts of songs, to make things like solo compilations.

 

EoF Authoring

<handShape chordId="0" endTime="2.501" startTime="2" /><handShape chordId="1" endTime="3.501" startTime="3" />

Reference Modded XML Case

<handShape chordId="0" endTime="2.001" startTime="2" />
<handShape chordId="0" endTime="2.501" startTime="2.5" />
<handShape chordId="1" endTime="3.001" startTime="3" />
<handShape chordId="1" endTime="3.501" startTime="3.5" />

Is this intended? Should EoF export as the reference modded XML case or do we not want that?

Was there a reason each chordified note needed its own handshape tag in this example?  The half second handshape covering both chords in each chord change seems consistent with normal EOF behavior, so I think it makes the best default behavior since it would be easily predictable.  Separate handshape tags for each could be achieved by either manually authoring a handshape tag or marking a chord with both "crazy" "hi dens" statuses, with the noted exception that EOF still pads handshape tags to a minimum length of 56ms.

 

 

OK, perfect then. I didn't realize that handshape marking was normally an automatic for successive identical chords. Of course we should mimic normal game behaviour. When I tried 'crazy' and 'hi dens', it worked as you say, but note that just "crazy"  on both A5 power chords was enough to give each A5 power chord it's own 56ms handshape. Toggling high dens only played with the <chord time> tags' high density attribute (0 or 1).

 

 

Another thing I'd like to test tomorrow is if I can manage to author- from EoF, with chordify, a box with no notes inside

I guess it depends on specifically what you're wanting.  If it's just no notes in the box, EOF should export it that way unless any of the notes require sustain or if any of the notes are open?  If you also want no handshape tag, that's probably not something EOF can export.

 

 

 

OK, I suppose use of the "hi dens" status on a non-chordified chord will do the job of creating a chord box with no notes. Also a repeat regular chord as follows will do the trick as per the image below which reproduces Robustness Test 11a, as desired:

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Reproduce%20test%2011a_zpslxeyzy80.png

 

 

I did find a little unexpected behaviour though. See image below. Somehow the chordify logic is not working as expected here where the EoF authoring is for chordifying sustained notes in a handshape but the XML doesn't author the superimposing single notes. So in-game the chordify logic does author the dummy chord but without sustain (superimposed single notes). Here is the notes.eof file that includes the authoring below. Here is the exported XML in question.

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/No%20superimposed%20single%20notes%20on%20sustain%20chordify%20authoring_zpshvnej8wy.png

 

 

Regarding redoing Robustness Test Case 9 (dummy chords with techniqes), I ran out of time this morning. Gotta go to work now. :(  I'll try my best to get those tests done Friday morning.

 

Have a great day!

I can see how it would be useful for an unusual project like that, but I'm not sure it would be a very frequently used feature. Are you looking more for it to save a separate EOF project of a specific portion of the chart? That may end up being easier for me to implement than a selective export for each supported game format, plus it makes it easier to fix up each individual song. It probably wouldn't even be difficult to have EOF split up the audio, since it would be pretty much the same logic as what is used to create a preview audio file for the specified range of the song. Let me know if this sounds close enough to what you're looking for.

 

A good, complimentary function would then be to be able to append a selected EOF file to the open project. People could then splice together parts of songs, to make things like solo compilations.

 

 

 

 

Being able to save a specific portion of the chart would be good.  What makes this project difficult is that while I can copy/paste the notes over to the newly cut song I cut with Reaper, I can't copy/pate the beatmap, which has beat changes very frequently.  I guess that would have been an easier way of explaining what I'm trying to do :)

 

I didn't realize that handshape marking was normally an automatic for successive identical chords. Of course we should mimic normal game behaviour. When I tried 'crazy' and 'hi dens', it worked as you say, but note that just "crazy" on both A5 power chords was enough to give each A5 power chord it's own 56ms handshape. Toggling high dens only played with the tags' high density attribute (0 or 1).

This should be expected behavior. The method of using the "crazy" status to force a chord to be low density followed the older method of forcing a new handshape tag so that it became low density due to being the first chord in its handshape. I don't see any problem with leaving it this way for the time being. People can still author low density repeated chords in the middle of a manually authored handshape phrase if that's what they're going for.

 

I did find a little unexpected behaviour though. See image below. Somehow the chordify logic is not working as expected here where the EoF authoring is for chordifying sustained notes in a handshape but the XML doesn't author the superimposing single notes.

My first guess is that, since they're chords, the sustain isn't automatically kept because they have no techniques requiring sustain, and that applying sustain status would resolve this. If this doesn't get the result you're looking for, let me know.

 

Regarding redoing Robustness Test Case 9 (dummy chords with techniqes), I ran out of time this morning. Gotta go to work now. :( I'll try my best to get those tests done Friday morning.

No rush, this feature is free to evolve over time as needed.

 

Being able to save a specific portion of the chart would be good. What makes this project difficult is that while I can copy/paste the notes over to the newly cut song I cut with Reaper, I can't copy/pate the beatmap, which has beat changes very frequently.

I'll look into working on this soon.

I did find a little unexpected behaviour though. See image below. Somehow the chordify logic is not working as expected here where the EoF authoring is for chordifying sustained notes in a handshape but the XML doesn't author the superimposing single notes.

My first guess is that, since they're chords, the sustain isn't automatically kept because they have no techniques requiring sustain, and that applying sustain status would resolve this. If this doesn't get the result you're looking for, let me know.

 

 

 

Ah yes, of course, I forgot the "sustain" status. Works fine now.

 

 

 

OK, so I tested Robustness Test 9 with Techni ques on Dummy Chords with your Hotfix 03-13-2016 and I get the following. I have to rush to work so some of the conclusions are sparse and referring to follow-up checks I need to make tomorrow. Sorry. Limited time.... :)

 

Here is a PNG file will all the screenshots.

 

Here is the associated notes.eof file in case you want to look more closely.

 

Here is the associated XML export.

 

Have a great day!

RC has log file in it "oggenc.log" somethin about SmellyOrc issue ;D

anyway, gotta build my EOF devenv again :)

One of the various chart files I tested with, that log file escaped me while I was putting RC11 together.  I replaced the zip file for RC11.

 

Coincidentally, I also set up my development environment again when I replaced my old computer.  The Windows build wiki has been updated pretty thoroughly, even covering the differences between using the TDM-GCC and MinGW releases of GCC.  I even tested the Linux build instructions in an Ubuntu VM and I was rather shocked at how much more simple and automated building applications is in *nix when you use the magic commands.

Is it possible to have a list (maybe 5) of recently loaded .eof files in the File menu?

 

People are so used to that now, with Office programs and what not.

 

Please take this as a suggestion for improvement rather than a complaint :D

I just wanted to suggest a new feature if it's possible to implement: The ability to cut selected song parts out of the project.

Keep an eye out for this in the next hotfix. It will basically be: Seek to where you want to begin an export, set a start marker from the Edit menu, similarly set an end marker and then use the new "Export time range" function from the File menu. EOF will build a new project file containing just the content within the defined time range, resynced so that the start marker becomes 0:00 and saved with the destination folder and name you specify. An OGG and WAV file of that portion of the audio is also created in the destination folder with a similar name.

 

Is it possible to have a list (maybe 5) of recently loaded .eof files in the File menu?

I'll consider it, but I'm not sure I'd make it store file history by default and instead make it something the user can enable.

Hi, folks.  The latest hotfix (4-5-2016) is in the first post.  Changes are as follows:
*Fixed a GP import bug where if a note was at the absolute beginning of the first measure and had a before the beat grace note, the import of that note would malfunction.
*Fixed a GP import bug where if a tie note has a before-the-beat grace note, the duration wasn't correctly set.
*Fixed a RS2 export bug where single notes (or chords with split status) with linknext status that combined with other notes would result in the count attribute for the tag being higher than it should.
*Fixed a RS2 export bug where split chords inside a handshape tag would cause duplicate chord templates to be written to XML.
*Added a "Note>Pro guitar>Slide>Convert to pitched" function that will convert unpitched slides to pitched slides, provided they aren't already defined as having a pitched slide as well.
*Added a "Note>Pro guitar>Slide>Convert to unpitched" function that will convert pitched slides to unpitched slides, provided they aren't already defined as having an unpitched slide as well.  If the affected pitched slides don't have a defined end position, a 1 fret slide will be assumed.  If this is not possible (ie. would cause a slide to 0 or a slide above the track's fret limit), EOF will warn about and highlight such notes.
*Fixed bugs where if a note was both a pitched slide AND a bend note, removing either technique could remove the other technique's definition (end of slide position or bend strength).
*Adds initial logic for a new "chordify" RS2 authoring mechanism.  This status will cause a chord to export as a chord tag with no chordnote tags.  If the chord would have normally exported with sustain (due to "sustain" status or any of various techniques), the corresponding single notes are exported with note tags that have ignore status.  A major reason this mechanism is needed is to allow the authoring of what appears in-game to be a chord whose notes have different lengths (ie. a chord where one its strings continues to sustain while another of its strings play other notes).  This hasn't been found to be reliably doable any other way in Rocksmith 2014.  If a note is marked with both "split" and "chordify" status, the "split" status is ignored and it follows the chordify behavior instead (single notes only export if needed to represent sustain, and are exported with ignore status).
*Improved the slide up/down toggle functions so that notes that already have a pitched end of slide position have it reset to 0, so if a down slide is turned into an up slide, it can't retain a then incorrect end of slide position.
*Improved MIDI import to recognize the "T1 GEMS" track as the guitar track in Guitar Hero 1 MIDIs.
*Fixed a bug where if the last gem in a pro guitar note was toggled off when legacy view was in effect, the note would not be deleted.
*Corrected 2D rendering so that string tunings aren't drawn on the left edge of the piano roll when legacy view is in effect.
*Improved the handling of the temp folder so that when EOF runs in a non-Windows environment, the folder is created at /tmp/eof.
*Corrected the MIDI export, lyric import and project save functions to use the temp folder for their temporary files.
*Improved the highlighting feature so that if anything in one of the active track's difficulties is highlighted, the difficulty name or number in the difficulty tab is highlighted in yellow.  The tech notes indicator (*) will be individually highlighted where appropriate.
*Improved dynamic highlighting functions to process both normal and tech notes instead of just whichever note set is currently active.
*Added functions in Song>Seek to move to the position (if any) of the next or previous highlighted note in the active track difficulty, and have assigned the SHIFT+Y and CTRL+SHIFT+Y shortcuts to them, respectively.
*Fixed a bug where the Info panel wouldn't correctly indicate when no time signature was in effect.
*Fixed a bug where the seek selection (Feedback input mode) wasn't displayed in the Info panel if the vocal track was active.
*Added "Set start point" and "Set end point" functions to the edit menu that allows a portion of the chart to be defined for functions such as "Create preview audio" and "Export time range".  If Feedback input mode is in use and a seek selection is set, that selection will take precedence if start and end points are also defined.  To clear either the start or end point, set it again at the position it is already set to.
*Improved menu handling so that if Escape is used to close a function's dialog, it will more reliably close the menu system instead of dropping keyboard input until Escape is pressed again or the mouse is used.
*Moved the import functions into a File>Import menu to reduce the clutter in that menu.
*Added a "File>Export time range" feature that allows a user-defined portion of the active project to be saved as a new project file, with corresponding audio.  For best results, use the "Set start point" and "Set end point" functions to mark the part of the project you want to export.
*Improved GP import to handle invalid tuplets of 0 divisions that may be encoded by Guitar Pro in unknown scenarios.

There's been lots of code cleanup that isn't supposed to change program functionality, but mistakes can happen.  Let me know if you run into any odd behavior.

Hi, folks.  The latest hotfix (4-13-2016) is in the first post.  Changes are as follows:
*Added logic to prevent temp files from being written outside EOF's temp folder.
*Fixed a bug with the "Export time range" function where the exported project didn't correctly have its first beat position (MIDI delay) set to 0.
*Updated to FFTW 3.3.5, which should provide performance improvements with the time stretch and spectrogram features.  On my computer, this seemed to result in about a 3.5% improvement in render speed when the spectrogram is being displayed.
*Updated the makefiles to perform link time optimization, which should provide some performance improvements overall.  On my computer, this seemed to result in an additional 4.5% improvement in render speed when the spectrogram is being displayed.
*Added additional error checking during MIDI export.
*Improved cleanup logic so that if two pro guitar notes merge, they each retain their ghost statuses where appropriate, and if a ghost gem and a non ghost gem merge, the non ghost gem's data are kept.
*Improve Note>Resnap to not warn if fully ghosted notes will be merged by the operation.  This should reduce the annoyance of cleaning up charts where the base chord of an arpeggio/handshape was rebuilt after being moved.
*Fixed a crash that could occur when enabling the secondary piano roll.

Thanks as always raynebc!

 

Regarding: *Corrected note creation logic to force new tech notes to have a length of 1ms.

 

Can you elaborate a bit on this one, perhaps by way of an example, as to what this new feature allows. Not used to thinking of tech notes as sustained.

For some reason I noticed newly added tech notes were allowed to have a sustain. Even though this shouldn't have any effect it's not the way it's intended to work so I fixed that behavior.

Hi, folks.  The latest hotfix (4-14-2016) is in the first post.  Changes are as follows:
*Corrected oggenc error logging in leading silence functions.
*Fixed a GP import bug where quarter note length notes/chords could be incorrectly truncated if the preferences to truncate short notes/chords during GP import were enabled.
*Fixed a bug where "conditional deselect" didn't behave correctly when the cymbals criterion was used.
*Added an "Edit>Selection>Conditional select" function that behaves similarly to conditional deselect.

Since the 4-14-2016 hotfix, I've noticed that using the CTRL+Z undo function while the waveform graph is in view causes the waveform graph to disappear. Almost as if the "undo" is also being applied to the waveform itself.

It's happened in a couple of individual projects, so it should be quite easy to replicate. If not, just let me know and I'll provide a project for you to test with.

Able to reproduce this bug, you need to set waveform(i'm using f5) then do some changes, then undo > confirmed :)
if you don't do any changes it won't disappear ;)

I know the exact change I made that causes this, it was intended to only dismantle the graphs when the project was closed (ie. to open another project), but I didn't account for this happening as per the behavior of the undo/redo functions.  Next hotfix should have it sorted out.

@@raynebc - One song that I'm working on has one section where there are several slides between major and minor third handshapes. When I try to do it in EoF, I get a warning saying that the slide isn't defined correctly. This warning happened when the slides were defined as shown, and when both slides were defined using tech notes when the "main slide" was both absent and present. I don't really get what the program wants from me, as these slides seem very similar to what Berneer uses in the tech notes tutorial. This is using the most recent version of EoF. Edit: After thinking about it a tiny bit more, it  might think I'm trying to slide down to a note that's above the base position, i.e. for slide tech notes it's still considering the chord as a whole rather than each string individually.

 

On a related note, in another custom I remember having problems with how a slide somewhat similar to this displayed in another custom. The slide was from a major 7th to an octave (so only the one finger moves), which then sustains fora  long time. Rather than displaying as a short slide and then a long sustain, it displayed as a long slow slide with the sustained note overlaying it (i.e. there were two notes displaying on the same string simultaneously). I don't have screenshots of it and have since changed the project file, but I should be able to recreate it without too much trouble. I think this was using one of the versions that we had for a long time, shortly after the release candidate version.

 

 

On a different note, I've noticed there are some pretty standard chords that don't have fingerings automatically done in EoF. I realize that I can define the handshapes for new chords myself, but some of these I figure are universal enough that it makes more sense to fix on your end. I could try to come up with a more exhaustive list, but the most pressing one in my mind are octave chords that use the B or e strings, so there's a three fret gap instead of two. I think another pretty common one I noticed having to fill fingerings for was Em shape barre chords.

Edited April 16, 20169 yr by albatross213

It's beacuse there is a two note (fret) difference in the first double stop, and a one note difference in the second double stop.  It's impossible to chart correctly using current RS14  Maybe RS17 will allow it.  The EoF warning must be recent because RS14 actually allows this, it just looks like shit on screen.

 

I've used a few different solutions to this, and it depends on the context (the song).  I'd recommend biting the bullet and using double stops without any sustain/slides.  The end player will pick it up.

 

It happens a lot in my KOL customs, have a look what I did there (all them early opening slides were charted originally like you wanted to chart this).  It's the D String fingering I'm on about.

 

dsBXBO8VzdM

 

 

Edit - I can't work out how to set only a link (without a vid).  It is not my intention to post one of my play vids in the EoF thread.  Paste that into Youtube to see it :D

I'm having an issue on Windows 10 when I alt tab back to EOF it cycles through super, easy, medium, amazing, bre very fast multiple times until I can alt tab or do something to make it stop it again. Very annoying. I was also going to report the undo waveform but that's been reported :)

@@PC Plum - You definitely can (or at least could) do slides like that, see this example by Berneer. It's not exactly the same thing, but you should be able to do slides like that. My problem is that EoF is refusing to export it as a slide at all, because it probably thinks I'm using a slide down technique but not actually sliding down.

 

The second paragraph of my post relates to how these slides tend to interact with linknext. That may or may not be something that can be easily done in EoF, but my guess is it's something that Rocksmith can do, but might not be worth figuring out what needs to be done in the XML to enable it.

 

Put another way, EoF doesn't (I just checked) have a problem with the second chord slide in the image, though the resulting chord slide probably won't display correctly.

 

 

One song that I'm working on has one section where there are several slides between major and minor third handshapes. When I try to do it in EoF, I get a warning saying that the slide isn't defined correctly.

EOF is supposed to allow this sort of thing to be authored, I'll check it out soon.

 

I'm having an issue on Windows 10 when I alt tab back to EOF it cycles through super, easy, medium, amazing, bre very fast multiple times until I can alt tab or do something to make it stop it again.

I've seen this happen, and have tried to add logic to prevent it (there's a callback function EOF hooks into when the program regains foreground focus), but I haven't been able to ever fully get rid of this phenomenon.  It's probably an Allegro bug because they've written in the patch notes about having fixed this before, but it doesn't seem like they did in all cases.

EOF may have been warning about that slide, but it does appear to export it correctly (the E string slides to fret 7 and the B string slides to fret 9), but the logic that generates the warning needs fixing.