SmellyOrc

Wouldn't it be easier to save a gp4 file as a gp5 file? Guitar Pro 6 at least supports this. 

@SmellyOrc  This is an important point because once you edit the tone with the toolkit it inserts the XML tone id elements.  If you make a mistake in tone naming then you must start over with the original EOF XML that has no tone id elements.  If you don't use an original EOF XML there are likely to be all kinds of issues because the toolkit has no way of fixing the early error in tone naming.

I'm not changing any tone changes or names in EoF, but simply editing the arrangement. Then the ORIGINAL Eof XML is used by the toolkit (of course, because they have the same name as the altered one afaik), and this generates an error. 

 

 

You would really need to pull the altered arrangement XML back into the toolkit (remove then re-add) and re-assign your tone to it.

Except that if you have a ton of tone changes in your arrangement, it'll add those generic names that I use in EoF to the tone list, and after re-assigning the tone, I'll end up with multiple tones with the same name.

Also, removing and re-adding an arrangement because I changed a note from non-mute to palm muted (for example) seems a bit over-the-top, does it not? 

 

 

It's complicated I know, but no-one said progress was easy  :)

It's not complicated, the fix is easy. But somehow, they're not seeing it.

@SmellyOrc  Sorry to hear you are still having tone issues.   "The fix would probably be to change the name of "clean" and "distortion" in <tone time...> to reflect the names as defined in tonebase/tonea/toneb etc."

 

When toolkit Creator GUI, Tones "Edit" button is pressed the "Edit Tone" form pops up.  Change Tone Information (top left) from "Acoustic" to "Clean_Reverb" and press "OK".  The toolkit does above fix.  I just tested latest beta 15e1a63 and toolkit produces expected results.

That's what I did. THEN I changed something in the arrangement, saved it again in EoF, and THEN when I generate a package, I get that error. 

THEN when I change the XML as described in my previous post, it works just fine. 

And to add to raynebc's answer, yes it's normal, and it's only there in order to get a song working with only one actual tone change. EoF needs two tone changes in order to export them correctly (afaik), so I set tone change at the start of the song which "changes" to the tone already set. It's aaaaaallll good. 

More tone issues! Yay!

I've used the workflow that has been prescribed (Tone changes in EoF, load in toolkit, edit the tones and load the tones I want). Now, when I change something in EoF and re-save, I get the following error upon re-generating:

http://puu.sh/iYS9k/5165ec8d65.png

And I'm getting sick of it. The only way to fix it is to re-add the arrangement and then go to edit tone -> load the tone again. Re-saving the file in EoF does NOT work. And with the tone window taking forever to show up, it's really annoying. 

Now, if you'd just implement the fix I've set out before, I bet my ass that it will solve EVERY tone change issue that might crop up. 

I'm talking about this fix in http://customsforge.com/topic/989-custom-song-toolkit-v2600-was-released/page-20?do=findComment&comment=154110 :

 

 

The fix would probably be to change the name of "clean" and "distortion" in <tone time...> to reflect the names as defined in tonebase/tonea/toneb etc. After I did that manually, the package generated without errors.

Guess what I did. I manually changed the XML file from 

http://puu.sh/iYSrn/f7619b0c53.png

to

http://puu.sh/iYSt1/9b4971feb9.png

And it worked.

This is the EoF tone list:  http://puu.sh/iYSvi/5994fa5f80.png

And here's the arrangement window:

http://puu.sh/iYSxH/163b780a89.png

Just you. There are quite a few tutorials on how to use EoF here: http://customsforge.com/forum/78-tutorials/

And as for the red sections: it means that the duration of the notes/rests does not add up to what it should according to the time signature. In GP6, the duration of the note and the duration of the bar you're currently in is noted at the bottom. A full bar would show 4/4, while a read one might show anywhere from 0.5/4 to 3.5/4 or 3.5/8 etc, depending on your time signature. 

Should I change it so that it will only split up chords within arpeggio phrases and not within handshape phrases?

 

Also, maybe I should change it so that notes/chords inside of handshapes aren't forced to have crazy status like they are in arpeggio phrases, since this prevents contained chords from displaying as repeat lines as well.

To the first question: Yes. As seen in this official DLC, chord panes are displayed inside handshape phrases: https://www.youtube.com/watch?v=mI_fniggOS0

Second question: yes.

There is no need to wait for feedback, if you think it's ready, just submit it.

Here's a quick checklist though:

- Sections

- Good sync

- Good tones/tone changes

- Leading silence

- WORKS!

How can we configure EoF to have the previous behaviour ? because for example, if I got a chord played multiple times followed by the same chord fret hand muted. this fret hand muted chord is displayed as a new chord with all x on each note previously i would have only a box with one x

That should not be happening. First off, because when you update, the default settings are the same as any previous versions, and there should not be any change in behaviour. If there are, Press F11, disable "Apply crazy status to...." and set chord density threshold to 10000 (10 seconds) ms. But don't set it to 10000. That's silly. 1000 is good enough, and probably too much already.

I guess we'll see what others think. In guitar tab the palm muted notes wouldn't be authored with rests anyways so it comes down to how individuals prefer to author palm mute sections.

True, and disabling that function and setting the chord density threshold to a low value would do the same anyway.

I want a repeat line even if there is a rest between chords, if the former chord is a palm/string muted chord. palm/string muted chords don't ring out, and when you have a lot of switches between muted and non-muted chords, it could clutter up the screen. For example, this is how something like that is currently imported:

http://puu.sh/ipHRe/6bcd59a092.png

In essence, those palm-muted chords don't need a crazy status, because they don't ring out anyway.

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

*Fixed some bugs with Rocksmith import logic that is used when importing a file over the command line or via the menu when no project is already loaded.

*Renamed the "GH Import" menu function to "Guitar Hero Import" and assigned the H hotkey to it.

*Fixed memory leaks that could occur during failed Guitar Pro or Rocksmith imports.

*Added the ability to import Guitar Pro and Go PlayAlong files via the command line or when no project is already open. EOF will prompt which pro guitar/bass track to import the content to.

*Improved RS export's high density detection to look at the distance between the start of a repeated chord and the end of the previous chord, instead of using the start position of the previous chord.

*Added a "Chord density threshold" preference that defines the maximum distance a repeated chord can be from the previous chord and still be allowed to RS export with high density (repeat lines).

*Added a "GP import truncates short chords" preference that works the same as "GP import truncates short notes", except that the latter now only applies to single notes.

*Added a "Apply crazy to repeated chords separated by a rest" preference that does what it implies if the distance between the distance between the chord and the one that precedes it is greater than the minimum note length preference (or 2ms, whichever is larger) and that preceding note is not selected (ie. not still being edited). The purpose of this preference is to display repeated chords as boxes instead of repeat lines if there is explicitly space between it and the chord it follows.

Thank you! lots of great improvements :D

Edit: I think you can improve the 'Apply crazy to repeated chords separated by a rest' function by making an exception if the previous chord is a palm or string muted chord. What do you guys think about that?

@@firekorn I am unable to reproduce the error without having SmellyOrc project files.  Interesting SmellyOrc and I responded here after his initial post and now our responses are missing.

I have uploaded a project here:https://www.dropbox.com/s/67b3zu5xs18vu6m/Amorphis%20-%20Day%20of%20Your%20Beliefs.rar?dl=0

This is my workflow:

1) Create tone change.

2) Give a descriptive name, like  "Acoustic", "Distortion" or "Lead", for example.

3) Save project in EoF.

4) Add XML file as arrangement

5) Toolkit loads the descriptive tone names

6) Add real tones to my tone list

7) Edit arrangement to change the tones to the ones that I have loaded.

8) Make everything else correct in toolkit

9) Save

10) Generate

11) ERROR

Note: it does not matter if I load the real tones (the ones that I'll use/try out) before or after I add the arrangement.

The problem is that the toolkit changes the XML file to reflect the changed tone names in the <tonebase> <tonea> etc fields, but not in the ones after that, the fields that specify the time of the tone changes:

http://puu.sh/i4QN1/e8e89524b5.png

So in the above case, the EoF tone names have been changed from Clean and Distortion to Clean_Reverb and endofhope, respectively. Done manually, by me. In the Edit arrangement box. The <tone time> stuff still uses the old tone names, and therefore returns an error. If I manually edit those tone names to Clean_Reverb and endofhope, the package generates just fine, and the song plays just fine as well.

If you need anything else, let me know.

PS: The project I've uploaded is a different project from the one described here.

completely unneccesary, just select all phrases, level them up to max and then turn off level up

There's something broken in RS2014, since turning it off won't always stop the game from leveling you down. Unless of course, you open the riff repeater menu every time you start a song. Which is annoying. That's why I stopped including DD in my CDLC.

 

Sounds interesting, I'm gonna give that a try.

 

Thanks SmellyOrc :D

 

It's the closest you can get if you want to slide from an open 6th string. If you're on the 5th string or higher, you can transpose it to one string lower, 5 frets up (or 3-4 depending on which string you're coming from, and the tuning), and then slide up.

So for example, if you have an open string note A that you want to slide up, in standard tuning this would be an open note on the fifth string. Fret 5 on the sixth string is the same note (in standard tuning).

You can't. What you could do is have an open string note, then a hammer on to another note, which slides upwards. RS2014 does not support open string slides.

@@SmellyOrc In the case you are suggesting that any consecutive Half note (or longer) will always have their full chord pane no matter what? i would really dislike that way of working as i wouldn't be able to make it look like any official song anymore.

Right... that might be a problem. Maybe start the look-up from the end of a chord instead of the beginning?

Or just do the automatic crazy toggle thing. Probably easier.

 

No look-ahead (or at least, not further than the next beat)

On your second case it won't import and look the way you think it will unless you add a crazy status on the second chord box the way EOF logic with repeat pane work at the moment.

At the moment. YES. But not if you remove the look-ahead logic that EoF currently uses, which is what I'm basing this argument around.

*bangs head on desk*

 

It's not my suggestion it's @@bob64 ones, and that 56ms (or 1ms) issue is one that the user should do himself like the sustain that touch the next note. Short chord boxes seems to bother mostly you @@SmellyOrc Probably.

 

Even with the correct sustain on all chords you would never get rid of the handshape sustain being too long than it needs to be if the next chord is the same one. So what you are suggesting will basically change nothing to the actual state of cdlc creation. Removing the look-ahead processing that happens during export to XML will do EXACTLY that.

At one point EOF shouldn't do all the job of the charter, EOF should import the best way it can a GP file but there's always adjustement to be made no matter what. If charters don't care about that it's their issue not EOFs'.

What I'm suggesting is actually that EoF does LESS than it's doing now. No look-ahead (or at least, not further than the next beat), and import chords with their correct lengths. This means that 4 quarter note-length chords in a row will start with a chord box, and then 3 repeat boxes, but something like <quarter note length chord><quarter rest><two quarter note length chords> will start with a chord box with correct length, a pause, another chord box, and a repeat pane.

 

I know some people consider handshape tag highlighting in game to be sustains, but they're not the same thing. When sustain for individual notes is not needed, then yes, the handshape tag highlighting IS the sustain. If it wasn't, it might as well not be there at all. Why are we even bothering with it then? Just make every handshape tag highlight go from the start of the song until the end? Makes just as much sense. I seriously do not know you can not see how that handshape tag highlight IS sustain. Even the name, handshape... it tells us how long to hold the handshape, right? Well... if we keep the handshape, guess what? The chord will be sustained. Unless we mute it. And then we might as well remove the handshape.

 

Whether or not two chords should be separated by rests to determine whether they import as low density chords (chord boxes) instead of repeat lines is something I'd consider more of a personal preference. It's not a preference, it's how it should be played. Seeing that handshapes ARE sustains, importing chords after a rest as low density chords ignores that rest. That messes up the rhythm. You can't tell me that http://puu.sh/i6g7C/77577a4768.png

  Is the same as:

 

http://puu.sh/i6gtd/8925614ef9.png

 

Which is what you're suggesting.

 

 

Like you guys have said, probably the only way this could be achieved during an import would be to forcefully mark the low density chords with crazy status, since this is the only status EOF uses to force a chord to export this way. Personally though I think it's better if consecutive chords that are "pretty close" are displayed with repeat lines. Sure, as long as there's no rest in between.

 

The 1ms length for "short" notes is already a user preference that can be disabled, but I don't know if it would be very helpful to make a separate preference that did the same but only for single notes instead of chords. The option to truncate short notes is used to reduce screen clutter. This is simply not applicable to chords. 

 

About minimum handshape lengths, EOF enforces a minimum handshape length of 56ms (unless a non matching note is closer than that). This seemed to be the shortest any handshape used in RS1 official charts and it seemed plausible that shorter ones would malfunction in some way. Are people still creating RS1 charts?

 

The shortest that I can see are for example in this video:

 

Comments in italics and bold.

Accuracy is the job of the charter himself, EOF is just the tool to make it easier ;)

Except that most charters either don't know about this, or don't care. Ten seconds is a LONG period for forward looking.

I believe the easiest way to fix this would be to have EoF import chords with their correct length (so NO truncating chords to 1ms even though truncating short notes is on), and then just doing no look-ahead.

This will achieve the following:

* No more chord boxes that are 1 ms in length. They look so ugly, and chords don't need to be truncated anyway.

* No more incorrect chord sustains

* This might lead to slightly increased screen clutter, but this is negligible in 99% of the cases

* Rests will now be properly be "imported" (goes back to #2)

In short: this will improve the accuracy of a chart.

Firekorn's suggestion of automatically toggling crazy status on a chord after a rest is also viable, though that still leaves us with chord boxes that are 1ms long.

You probably have the "Adjust notes/beats" option enabled in the leading silence window, whereas before you disabled it. Anyway, it's better this way. No need to shift notes around if you're importing from a gp file.

Also with regards to vocals, you can just go to track_vocals, press ctrl+a to select everything, and then move everything 3 seconds. The Marks (blue lines) that denotes where a line starts and ends does not move with it, so you'll have to remark them (shortcut: ctrl+m).

Also remember: LYRIC SUSTAIN. Keep that spacebar pressed for however long that syllable is sung.

http://customsforge.com/topic/11210-lyric-tutorial/

It's fine if the first beat starts at 3 seconds. Rocksmith 2014 jumps to a few seconds before the first beat marker, so 3 seconds of silence works just fine.

Also, of course the original.mp3 won't have the leading silence. It's the original. You need to convert the .wav file that eof generated to a .wem file (using wwise directly or using the toolkit) for use.

Sigh... I don't know what you did, but my previous tone error is back (latest version, 9312319f):

http://puu.sh/i4QGy/ed8971b15f.png

How it's set up in EoF:

http://puu.sh/i4QHP/d078312cdb.png

XML file before generating package:

http://puu.sh/i4QKp/bfee0e8f93.png

XML after trying to generate package:

http://puu.sh/i4QN1/e8e89524b5.png

The fix would probably be to change the name of "clean" and "distortion" in <tone time...> to reflect the names as defined in tonebase/tonea/toneb etc. After I did that manually, the package generated without errors.

Also, I can't find this accurate TS option anywhere I'm going blind :(

It's in the song properties window (shortcut: F9):

http://puu.sh/hYW1e/6285b92312.png

It's enabled automatically for new projects.