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.

Thanks raynebc for the quick reply.  It turned out to be a bad RS tool kit version, but I was able to see the tuning and I made another song last night ensuring the tuning as correct when using the EoF program.

I see I was too slow :(

 

There are tuning issues in some of the newer toolkits.  You can post problems in the toolkit thread

 

 

http://customsforge.com/forum/56-rocksmith-custom-tool-kit/

 

 

and try to quote the version number you used.

Hi, folks.

 

The latest hotfix (r1396) is in the first post. Changes are as follows:

*Improved Rocksmith import to be usable even when no project is currently open. EOF will prompt which pro guitar/bass track to import the content to.

*Improved GP import to keep the notes that follow a legato slide and link it to sliding note, to more accurately display how to play it in Rocksmith.

*Corrected GP import logic for slides in GP4 and older formats.

*Improved fret hand position generation to place FHP changes at the end of note slides if applicable.

*Improved GP import to support triplet feel notation.

Hi. I have a song that I have charted with Reaper for Phase Shift/Rock Band which has pro guitar/bass, I'm trying to find a way to import it without messing up the tempo map, the problem is that song has no regular time signature, it changes almost every bars and are often in x/16, which seems to be the source of the problem. I can see EoF fixing x/8 bars by making them twice as fast, I'm wondering why it doesn't do the same with x/16 time signatures, it kind of mess up the whole thing right away.. Is there any workaround?

Maybe not at this time. If you wanted, you could try opening the MIDI back up in Reaper and playing with the time signatures to put it back in #/4 or something. Are the note positions importing incorrectly?

@@raynebc,

 

  I have an issue in DDC due to duplicated notes in the XML file generated by EOF (r1396) :

 

 

  <levels count="1">
    <level difficulty="0">
      <notes count="344">
        <note time="6.225" linkNext="0" accent="0" bend="0" fret="4" hammerOn="0" harmonic="0" hopo="0" ignore="0" leftHand="-1" mute="0" palmMute="0" pluck="-1" pullOff="0" slap="-1" slideTo="-1" string="1" sustain="0.000" tremolo="0" harmonicPinch="0" pickDirection="0" rightHand="-1" slideUnpitchTo="-1" tap="0" vibrato="0"/>
        <note time="6.469" linkNext="0" accent="0" bend="0" fret="6" hammerOn="0" harmonic="0" hopo="0" ignore="0" leftHand="-1" mute="0" palmMute="0" pluck="-1" pullOff="0" slap="-1" slideTo="-1" string="2" sustain="0.000" tremolo="0" harmonicPinch="0" pickDirection="0" rightHand="-1" slideUnpitchTo="-1" tap="0" vibrato="0"/>
        <note time="6.713" linkNext="0" accent="0" bend="0" fret="6" hammerOn="0" harmonic="0" hopo="0" ignore="0" leftHand="-1" mute="0" palmMute="0" pluck="-1" pullOff="0" slap="-1" slideTo="-1" string="3" sustain="0.000" tremolo="0" harmonicPinch="0" pickDirection="0" rightHand="-1" slideUnpitchTo="-1" tap="0" vibrato="0"/>
        <note time="6.713" linkNext="0" accent="0" bend="0" fret="6" hammerOn="0" harmonic="0" hopo="0" ignore="0" leftHand="-1" mute="0" palmMute="0" pluck="-1" pullOff="0" slap="-1" slideTo="-1" string="3" sustain="0.000" tremolo="0" harmonicPinch="0" pickDirection="0" rightHand="-1" slideUnpitchTo="-1" tap="0" vibrato="0"/>
        <note time="6.713" linkNext="0" accent="0" bend="0" fret="5" hammerOn="0" harmonic="0" hopo="0" ignore="0" leftHand="-1" mute="0" palmMute="0" pluck="-1" pullOff="0" slap="-1" slideTo="-1" string="4" sustain="0.000" tremolo="0" harmonicPinch="0" pickDirection="0" rightHand="-1" slideUnpitchTo="-1" tap="0" vibrato="0"/>
        <note time="6.713" linkNext="0" accent="0" bend="0" fret="5" hammerOn="0" harmonic="0" hopo="0" ignore="0" leftHand="-1" mute="0" palmMute="0" pluck="-1" pullOff="0" slap="-1" slideTo="-1" string="4" sustain="0.000" tremolo="0" harmonicPinch="0" pickDirection="0" rightHand="-1" slideUnpitchTo="-1" tap="0" vibrato="0"/>

 

 At time "6.713", there are two occurences of (fret = 6 ; string = 3) and two occurrences of (fret = 5 ; string = 4).

 Is it the expected behaviour ?

 

 Here is the EOF Project.

 

Thanks

For some reason, there are overlapping arpeggio phrases there. This isn't supposed to be doable, so EOF doesn't check for this during RS export. I'm working on fixing the logic that would prevent this from happening, but I think if you manually removed and recreated that arpeggio it would export normally.

I think if you manually removed and recreated that arpeggio it would export normally.

 

 Sure it should work, but this is not my CDLC.

 I was trying to understand why DDC didn't work for this one.

The next hotfix changes the RS export logic to handle this, but if you could have the user send me details about how this chart was created I could try to fix it so that overlapping arpeggios don't happen.

The next hotfix changes the RS export logic to handle this, but if you could have the user send me details about how this chart was created I could try to fix it so that overlapping arpeggios don't happen.

 

The CDLC owner is @@manchot66

 

Here is the associated post in the DDC topic

It's probably not a problem anymore, I added cleanup logic to look for overlapping arpeggios and merge them. Even if this were to ever happen again, all overlaps would be resolved before the XML files get written. And even if they didn't get resolved, RS2 still won't export duplicate notes.

Hi,

 

I was wondering if it was possible to change some logic/rules on bends with no tech notes.  At present the bend "tech" is set to 1/3 of the way into the bend if no tech notes are present?

 

I was wondering if this could be modified for shorter bends, specifically bends less than one beat long?

 

I've been thinking that for short bends that setting the bend point actually 2/3rds into the length of the bend would be both visually more attractive and probably aid in recognition, especially during fast soloing.

 

The way it is at present makes it pretty messy on fast solo sections with an almost vertical face on the bend and a pointless lengthy bend tail.  Musically, the information for bends of that length is in the bend itself, not holding that bend for 0.05 seconds.

 

I don't know how easily it is to put logic like that into EoF and I have actually been thinking of separating it out to bends of length >1 beat, between half a beat and a full beat, and less than half a beat.  But I thought I would start off with this easy one first and see how you react :D

 

Personally though, I would tech note any bend that's lasting almost a full beat and I am really only concerned with lightning fast bends that are a part of a fast scale run/solo.

 

 

 

Thanks :D

Maybe not at this time. If you wanted, you could try opening the MIDI back up in Reaper and playing with the time signatures to put it back in #/4 or something. Are the note positions importing incorrectly?

 

They don't, they skip some bars, they are importing about twice the lenght (ex: a 16th exports as a 8th), possibly other strange things, I haven't really looked at all the chart once I saw the mess it did. I can upload the MIDI file if you want to look at it.

 

I'll try playing with the time signature but it's gonna be a real challenge... XD

I've been thinking that for short bends that setting the bend point actually 2/3rds into the length of the bend

It would be easy for me to change all bends with no tech notes to put it 2/3 through the note's length, but making it different based on how many beats long the note is adds more complexity. Any other folks have thoughts on this?

 

They don't, they skip some bars, they are importing about twice the lenght (ex: a 16th exports as a 8th), possibly other strange things, I haven't really looked at all the chart once I saw the mess it did. I can upload the MIDI file if you want to look at it.

If you could make a small, simple MIDI demonstrating this for my testing, it would help.

 

I've been thinking that for short bends that setting the bend point actually 2/3rds into the length of the bend

It would be easy for me to change all bends with no tech notes to put it 2/3 through the note's length, but making it different based on how many beats long the note is adds more complexity. Any other folks have thoughts on this?

 

Yes. Use tech notes. -_-

I was gonna say the same thing: To use Tech Notes. To be honest I consider non-tech note bend as sort of obsolete since the music should dictate exactly where you should put the bend. What are the odds that 1/3 or 2/3 of the sustain are the ratios the music calls for?

 

I agree with Plum's logic of the normal tendencies in music but I wouldn't risk confusing new charters with a two-tiered placement system. If 1/3 is more often wrong than 2/3 then it can't hurt to set the default to

2/3, I guess.

I think people are missing my point.  ALL charts now have tech notes on bends, this will effect no one unless you choose to manuaily erase tech notes from import.  So it will not effect new charters in the slightest.

 

I choose to manually erase tech notes on short bends in fast soloing because it is a royal pain in the ass setting tech notes on sustain lengths as short as I am talking about, and so I let EoF set the bend definitions for me.  I am talking about bends which last a fraction of a second and the 1/3rd rule makes shorter bends horrible to look at and difficult to register.

 

I bet everyone has played a chart with a fast section coming at them and thought "I'm never gonna register those bloody bends".  Hurting your fingers, making the guitar sound awful just to try and hit that score...

 

The 1/3rd rule is a historical requirement that still exists which no one knows about or cares for.  I am asking for it to be made extremely useful (well, to me :) ).

 

If any charts happen to end up with a long bend with a 2/3rd bend marker in them, then the charter hasn't paid much attention and probably wouldn't know the difference anyway.

 

Can anyone post a legitimate reason, backed up by argument, why the 1/3 rule should stay?

Got it. Why not then make a user preference in EoF what fraction of a sustain tail a regular bend will be authored at. Like this one can play with the setting to zero in on an optimal value for a CDLC chart. Any different minority ratio for given chart would require TechNotes. Like this the position is at the user's discretion. Like any setting you need a default so it could become 2/3 if you agree with the proposed change.

I have a feeling that changing the auto-set code is changing one sum, adding more preferences is more work and risks breaking other stuff.

 

 

Actually, after some testing there I think a happy compromise of a half length would be best :D

 

 

Is that possible and fair, setting the bend point to 1/2 way through the bend note if no tech notes are present?  It would probably look logical even on longer bends if it ever turned up accidentally.

 

 

And sorry Berneer I didn't really read your last post I just got red eyes from smelly orc's comment.  But then I realise I am the king of sarcasm :D

It would almost be easier for me to make a user preference for what percentage into the note's duration the default bend placement is made. This should be relatively easy for me to add, and I think it strikes a decent balance for user customization. Then it's just a matter of whether this value is defaulted to anything other than 33%. Allowing for 3 digits (##.#%) would allow for more accuracy, but I think the difference would usually be pretty negligible as far as what the user sees, and it makes the naming of the user preference much more complicated than just "%". Let me know what you guys think.

Two digit user preference sounds dandy-oh :D

 

If you could make a small, simple MIDI demonstrating this for my testing, it would help.

 

This the first bars of the song, here you go: http://www.mediafire.com/download/axchkgc0co37623/synapticsample.mid

 

I hope this get somewhat fixed some day, even if it's just when importing MIDIs, alot of the stuff I like have irregular time signatures :|

 

Nonetheless, good job on EoF all around, you've been at it for quite a while now!

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

*Altered RS2 export to prevent duplicate single notes from exporting in the event of overlapping arpeggio phrases.

*Added logic to remove the possibility of overlapping arpeggio phrases.

*Changed the handling of time signatures so that the denominator (beat unit) alters the length of a beat as it does in music theory. To prevent unwanted alteration for existing projects' beat timings, this is not enabled by default for existing projects, but can be enabled or disabled by going into Song>Properties and toggling the "Use accurate time signatures" option.

 

This makes a major change with how time signatures are treated in EOF. To prevent breaking anybody's tempo mapping, this song property is not enabled by default for existing projects, however it is enabled by default for new projects/imports.

 

@@Alternity

Give this a try, it looked like it imported your sample MIDI correctly, but I haven't stress tested the new logic.

@@raynebc something changed about the gp import, linked note with different technique doesn't import as it did in older version (before 1370 i think? @@Teinashu can you confirm in which version does it work).

 

As you can see in this gp file : https://drive.google.com/file/d/0B1ZKYtpB0vu2bkZzVU9IeC0tQ28/view?usp=sharing

In bar 20, 21 and 22 we have slides and vibrato in mid notes but they don't import at all as you can see on those two screen :

http://i.imgur.com/jrpm5AT.png

http://i.imgur.com/M5wCALO.png

It should import like :

http://i.imgur.com/2A7ywGg.png

It's working fine in 1366 (Though legato slides are broken in that one)
In 1396 the legato slides get imported correctly but the other things don't.