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.

Using SOX we can apply fade effect to some audio file.

From what I can remember, Sox is many times the size of EOF, so it's a bit overkill to bundle it just for a fade out. Audio editing is still something I consider outside the intended scope of EOF.

I create a lot of vocals part at the moment and i think EOF could really be upgraded on this part with one little tweak.

 

The fact the the phrases (the blue part that indicate a line in rocksmith) doesn't move with the actual text, so every time you move lyrics you have to remark every phrases which is really annoying. The solution i was thinking of is to attach the start and the end of a phrases to an actual text so that if the text move, the phrase move in the same way.

 

I don't know if it's easy to add in EOF but it will surely make vocals edit much easier.

Something like that is on the to-do list, but I haven't had time to mess with it yet.

Hi, folks. The latest hotfix (r1314) is in the first post. Changes are as follows:

*Fixed a bug with one of the fret hand position checks that wouldn't work correctly if a note was fret hand muted.

*Improved RS2 export so that string muted notes in a chord can be displayed their defined fingering.

*Improved RS exports so that each unique fingering for a chord will be exported appropriately.

*Improved the "Edit frets/fingering" dialog so that the fret value, finger and mute status can each be defined individually for each string in a note.

*Fixed a bug with the toggle string mute function that wouldn't set a correct value when removing string mute status from a string muted note with no defined fret value.

Nice. Keep up the great work!

r1314 seems to work nice raynebc, i deleted the manual edited xml files and used r1314 to generate fresh ones and in the game the frethand mutes are show now like with the manual  edited xml files. Big thanks.

 

different question, i remember that a few month ago Maveth was talking in the old EOF thread about the tapping technique. If i use in EOF the ctrl+T shortcut i can set a note as tap and thats fine but the game seems to support some sort of highlighting sections with tap techniques similar to arpeggios when marking chunks of chords as arpeggios. Was it discovered how chunks of notes with tap can be marked as tapped saction/phrase?

 

The discussion there is around post #2290 and at post #2293 there is a picture of what i mean, basically the chunk of notes is inside the two blue walls

That post seems to describe pretty much what I remember about that topic:  It's a handshape tag used without the presence of any chords.  Does anybody remember if the "_tapping" suffix was necessary on the chord template's display name?  The template in post 2293 (http://forums.smithyanvil.com/viewtopic.php?pid=97692#p97692) shows no fingering, but a fret number is defined even though that number isn't used in the tapping section.  Would it work if the chord template defined -1 for all fingers and fret values?

 

If all that's needed is a generic chord template (no specific suffix needed in the name or display name) and a corresponding handshape, I may be able to add the ability to mark a generic handshape phrase.

that fret3="1" is really strange

 

i sadly dont understand what part of the xml i would need to modify to try it out. If you want i can send you an eof file with a long tapping saction and you can then modify the xml or tell me what i need to change.

I think you'd just need to define a chord template with no name/fingering/etc. and place a handshape covering the span (start and stop time) of the tapping section.  If you post a project file I can give you example XML.

How do i create an arpegio without dsplaying the entire chord at the start of the arpegios like the way it is on this screenshot :

http://uppix.net/WXGtsGl.png

The handshape is displayed, but at the start of the arpegio the actual chord isn't displayed and the name isn't too and i can't find a way to recreate this under EOF.

 

For the tapping section i was actually positiong the FHP to the lower fret and EOF or Rocksmith (i don't know which one change it) automatically do the rest, but this way it doesn't add the biggest blue bar at each end.

Here is the .eof file http://www.sendspace.com/file/euejw7 the tapping sections are in BASS_22 and Guitar_22 and start at bar 107

 

i also started to manual edit the xml of Bass_22 but you can see the result in the screenshot in the archive that i uploaded. I also added the edited xml file, i think the problem is the anchor part because the blue wall is already there.

 

the problem is that the frethand does anchor at 12 but the first tap starts already at 15, too bad that the code snippet from Maveth is sadly incomplete.

How do i create an arpegio without dsplaying the entire chord at the start of the arpegios like the way it is on this screenshot

This would probably be the same type of thing MadMaxx is asking about: A handshape with no actual chord. 

Here is the .eof file

You could try adding this to the end of the chord template section:

<chordTemplate chordName="" displayName="Yipee" finger0="-1" finger1="-1" finger2="-1" finger3="-1" finger4="-1" finger5="-1" fret0="-1" fret1="-1" fret2="-1" fret3="-1" fret4="-1" fret5="-1"/>

Make sure to change the chordTemplates count value from "18" to "19". And then insert this into the right place (chronologically) in the handShapes:

 <handShape chordId="18" endTime="198.452" startTime="172.747"/>

already did something similar just take a look at the modified xml or the picture in the folder, thats how it looks in the game. chord ID 17 is the chordshape from the xml snippet from maveth.

 

but ill give it again a try

 

do we have access to those lessons xml files?

 

edit:

tried it again now like you said but still the same result as the picture that i added in the folder that i uploaded.

<anchor time="172.542" fret="15" width="4.000"/>

this is basically what you see on the picture, starting from fret 15 a width of 4 frets, the problem is that the blue walls should start from 12 with a width of 4 that would include the 15

The problem looks like it's because of all of the fret hand positions, ie:

I had EOF auto-generate positions for that part of the PART REAL_BASS_22 track and it didn't place as many positions as your modified XML did. In any case, you'll probably have to manually place fret hand positions or generate them and edit them to your liking. What you want is to have long stretches of the tapped notes where the position stays the same. This will cause the number of highlighted lanes to increase as appropriate.

i actually let EOF always auto-generate frethand position but i have a self made chordshapes.xml

 

hm not sure why you get less frethand positions, those are all single notes.

 

edit:

if i use ctrl+shift+f i get 702 positions.

 

edit2:

tried it with the default chordshapes.xml and i get 321 positions hmmmm

The only reason I can think of for that to happen would be if you customized chord shape definitions that use the index finger, which could cause more fret hand positions to get placed. I don't see how it would affect single notes unless you defined a chord shape that only had one note in it, which would cause all sorts of un-needed position changes.

i edited now the frethand positions manually in EOF, so far the blue walls work but only till seek position 175.988 of the guitar_22 arr

 

the green notes have the blue walls but the orange dont have the walls. Maybe we need a new chordshape when the frethand position does change?

did a new test and added a second chord template like the one you posted, after editing the xml file now the next part till the next frethand position change does have blue walls.

 

it looks like the game needs for every frethand position a chord template

 

This one that you posted above does work only partially till the the first frethand position ends

 <handShape chordId="18" endTime="198.452" startTime="172.747"/>

 i had to plit it based on the frethand position change

	<handShape chordId="18" endTime="175.804" startTime="172.542"/>	<handShape chordId="19" endTime="179.079" startTime="175.872"/>

Alex posted in the Toolkit thread a link with the xml files for the lessons and there is on youtube probably a video of the lesson too. Overall it looks similar to what we discussed only with a few additional details.

 

besides that my chordshapes.xml does definetly produce a lot of not needed frethand positions, still the default chordshapes.xml does also cause during the tapping section trouble and needs from me to manually cleaned up.

 

maybe it can implemented similar to tremolo picking, the user selects the notes that have the same note that gets fretted with the fret hand and this selection gets marked similar to when marking a selection as tremolo. To override the issue that the chordshapes.xml can produce you can maybe look if the frethand positions are generated automatically and there is in the track a section marked as tap section to only take the note with the lowest value and use that for the frethand position and force only one frethand position.

 

not sure at all, and all that only to get those two closing blue walls :shock:

The chordshapes.xml file only changes fret hand placement for chords, not single notes (unless you edited it to do so, which I don't recommend). Tapping sections often span more than 4 frets which causes EOF to place more changes, and which is why you'll have to manually edit the fret hand positions for tapping sections.

the issue with  my chordshapes.xml is that EOF does generate for every note in the tapping part a new position thats why it does generate nearly 300 more positions. The problem is that most of those notes are in the range of 4 frets.

 

edit: double checked it, tap section in my song can go up to 5 frets.

 

I think that you said that also chords with only one note fretted can cause issues but an E5 does in its smallest incarnation only have one note fretted 0/2 on the EA strings same thing if you move both one fret down to the AD strings. Do i need the smaller incarnation if i have already the bigger version of it in the xml file (0/2/2)?

 

Ill see if i can tomorrow track down what chords in the chordshapes.xml do cause problems.

 

here is my chordshapes.xml btw. http://www.sendspace.com/file/x2kja4

 

Its trained mostly for heavy metal songs

did a short test with my song

 

321 positions without chordshapes.xml

321 positions with your/default chordshapes.xml

702 with my chordshapes.xml

ok did one more test and removed every chord shape except one from my chordshapes.xml. I only left the E5 shape inside 0/2 on the EA string and it looks like that one does cause havok. Only with that shape i get 702 positions.

 

This shape

<chordTemplate chordName="E5" 		displayName="E5" 	finger0="-1" finger1= "1" finger2="-1" finger3="-1" finger4="-1" finger5="-1" fret0= "0" fret1= "2" fret2="-1" fret3="-1" fret4="-1" fret5="-1"/>

Edit: i edited the xml and change it to 0/2/2 and eof generated only 321 positions

 

Edit2: yep i used now my whole chordshapes.xml file and changed that E5 shape from 0/2 to 0/2/2 and it does create with my xml file 321 positions now.

oh well i removed the old fingerings using EOF to see if EOF does ask me after saving to enter the fingerings for the E5 0/2 chord and sadly it asks me to enter the fingerings for it.

Your chord shape entry is similar to the standard "Em7" entry:

The reason I defined the finger used for this as the middle finger is because if it uses the index finger, it would force the hand shape to agree with the index finger usage every time this chord shape was matched (ie. any double stop where one string was played open). However, defining the chord shape this way specifically also causes an issue where EOF will try to apply that chord shape to single notes (since the chord shape only has one fretted note). I'm going to alter the automated fret hand position generation to avoid doing this. Until then, using the original chord shapes should avoid this problem.

 

Edit: Fixed. Now even with your example chord shape entry, it doesn't force a FHP change at each single note.