Anyone have any idea why these notes have sustain until the next note/chord when it's clearly not charted this way?

 

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

 

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

 

I get the exact same if I change the notes in EOF to:

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

I had the exact same problem with my last custom.

Have you tried to toggle the status "Crazy" on the chord after the 1st or 2nd?

In my case, the chords are much closer to each other, I tried everything I could think of (even editing the .xml file manually) and the result in game is always the same. If I toggle "Crazy" the chords after the 1st, the highlight on the note highway disappears, but every chord shows the chord box, instead of just this |__| on the note highway.

It would be nice to know if there's a way to author the chords in EoF, so that the sustains in game match what is charted in EoF.

Yup toggle the 3rd and 5th chord in that first picture.

 

The handshape for the 1st chord will follow through to the 2nd chord.  The second chord's handshape will continue for something like 50ms if you don't extend it (your eyes won't notice the 50ms).

 

The third chord (now toggled crazy) will not be a high density repeat pane anymore.  It's handshape will continue into the next chord.  The fourth chord's handshape will continue for another 50ms if you don't you extend it.

 

The fifth chord (now toggled crazy) will not be a high density repeat pane anymore.  It's handshape will continue into the next chord.  The sixth chord's handshape will continue for another 50ms if you don't you extend it.

"When EoF exports your song to the XML file, it looks ahead of every chord, and if it finds the same chord within 10 seconds (at least, I believe it is 10 seconds), it will lengthen the chord's sustain all the way to the next chord. This was done to reduce screen clutter in the RS1 era (as far as I know)."

quote from the link here: http://customsforge.com/topic/9858-most-common-problems-with-customs-a-few-things-that-a-charter-should-care-about/?p=79315

 

 

Assuming SmellyOrc is right about that 10 second thing.... why not default it to only do the current sustain-ignoring thing when the notes are connected by sustains? I might as well just mark my entire project as crazy notes since practically all the notes in it are like this.

 

I don't think over-riding sustain length is worth the reduction in clutter. What's the point of basically ignoring mutes by default for chords in a game that strives to be as accurate to the song as possible?

 

How about this as a suggestion then: Make the note highway/preview display the forced sustains for chords. This way everything is consistent and there is no confusion as to why eof is doing something it's not showing.

 

Second suggestion. Make the guitar pro import logic interpret rests after chords auto-toggle crazy on the next chord if it is the same chord before the rest. This way, the high-density mode is activated when theirs sequential chords without rests, yet rests are preserved.

EOF 3D preview clearly show you that the chord are repeated with the blue bar which means that the chord box will keep on untill the next chord change.

 

I prefer to toggle the crazy status on the chord i wish than having to deactivate it on every chord i don't wish to have it cause toggling on is a limited case when toggling off is most of the chord.

 

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

I guess after I've played around with toggling crazy throughout my song, I guess I am inclined to agree, but I think my two suggestions still stand. The guitar-pro import logic will automatically add in crazy when needed, and the preview would potentially help visualize how it will actually look in-game.

 

I think it should have the vertical sustain lines for whatever strings are in the chord in addition to the blue bar. As well as sustains lines

http://i.imgur.com/5ElEMSy.png

 

Perhaps the sustain lines should be lighter/darker to represent that the chord sustains are over-ridden by the lack of crazy being set on the next chord?

 

If i have a gp5 score that is 100% accurate, isn't it the tool's job to import that as accurately as possible? Why did I transcribe rests after chords into gp5 if EOF is just going to ignore them?

@@raynebc ^

 

I like the idea of semi transparent sustain as a way to display the handshape on the 2D pane :)

 

About EOF import being as accurate as possible, hum yes and no. EOF and therefore RS have element that doesn't exist in GP and vice versa.

 

I'm all for a way to have the minimal amount of correction to do in EOF but i'm 100% sure that you will always have to do some adjustment (i already encounter things i couldn't get right in GP so EOF would have never imported it correctly). Toggling on the crazy status when there's a rest (longer than 1/16 maybe?) after the chord could be a good way to improve it but i sure wouldn't like to have the crazy status on by default as it will be more work than it is right now to correct the chart in EOF.

It all would be so much easier, if we could switch to a real 3D Rocksmith preview in EOF, instead of the GH Preview.

It would make so many things like bends, sustains, handshapes and frethandpositions straightforward.

While charting, we always have to imagine how it will look,

most of the time I have my guitar on the knees while working in EOF to simulate the real thing.

I know this is probably a huge module to develop, but maybe some students are willing to assist the developers. 

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.

I know some people consider handshape tag highlighting in game to be sustains, but they're not the same thing. RS1 didn't have a way to display actual sustains for chords, but in RS2, it can display sustains for the individual notes in the chord, and EOF allows you to do this with the sustain status that can be applied to the entire chord or to individual notes in the chord by applying tech notes with the sustain status. Marking a chord with "crazy" status tells EOF you want that chord to display in game starting it on a new handshape tag, which also causes it to display in-game as a chord box instead of a repeat line. The short story is that a chord at the beginning of a handshape tag is shown as a chord box and anything else is shown as a repeat line. It's not as simple as just telling the highlighting to go away because that would remove your ability to display the chord as a repeat line. So far it hasn't been figured out if/how it would be possible to display a repeat line for a chord that is at the beginning of a handshape tag.

 

There is some inconsistency with the 3D preview and the exported XML as far as what chords are or aren't low density (chord boxes) because there is complicated logic in the RS export code, and the logic is different for both RS1 and RS2 export. Getting the 3D preview to reflect RS2 export (particularly the high/low density status of each note) more closely could be possible, I'll try to determine how doable that is. I'd like to make a Rocksmith preview panel some day, but it would be a huge undertaking so it's more of a wish list item now.

 

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. 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 (how close is subjective, 10 seconds was just something we all figured would work back in the Smithy Anvil days). It would be relatively easy for me to make that 10 seconds threshold user-configurable, I just hadn't gotten around to it. I'll bump it up on my to do list.

 

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. I could add a preference to automatically apply crazy status to a chord if it was the same as the previous note but imported so that the two chords were separated by space (say more than 2ms), generally this would only happen due to rest notes.

 

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.

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.

 

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 for all i've seen so far and even if it's not pretty, i doesn't make any problem during playing tho.

 

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.

 

I like the application of toggling crazy status on a chord after a rest so that the chord before the rest either get an handshape of 56ms or the actual length of the sustain as it is in EOF if there is one not matter if both chord are the same or not.

 

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'

 

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.

 

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.

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*

But if you get rid of that look ahead logic for repeat pane you don't get anymore repeat pane at all or you keep the look ahead logic but adjust the time to your convenience but that's one of the proposition of @@raynebc already.

 

In both case i don't see where sustain comes into play since a chord sustain that touch another chord won't create any repeat pane as far as i know or that's what your logic imply if there's no look ahead logic for repeat pane (or if the look ahead don't look further enough).

 

I prefer to have too much repeat pane and get rid of them with the crazy status by hand than having not enough repeat pane and not being able to create some when i need it. One way i have control over the result, on the other i can't adjust anything.

 

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

Welp. Looks like I inadvertently started a massive debate.

 

How about we break it down to sub-issues?

 

1) gp5 import rest handling. If there is a rest after a chord, look for the next note. If that next note is a chord, check to see if its the same chord as the previous chord. If it is, mark as crazy. I don't think there will be a case where you would want rests ignored. If so, please give an example and let us analyze the merits and debate it.

2) Some sort of preview that correctly shows sustains in EOF when they're automatically added due to the lack of crazy status on the next chord. See photoshoped screenshot here: http://i.imgur.com/5ElEMSy.png

3) look-ahead logic improvement? I'm a bit new to this, but I'd probably suggest the look-ahead to only check the next note/chord, not beat, after the current chord, because there's no point in checking 10 seconds worth of notes just to decide if it's the same chord and plop down a repeat chord thingy. However, I think the crux of this problem will be: do we want the import logic to import chord sustains?

4) gp5 import chord sustain handling? Why bother with invisible sustains when we can just have eof figure out chord sustains when they are imported? If the gp5 shows a whole-note sized chord, bam we get a whole beat of sustain.

 

"Bob64'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."

 

I really fail to see how chords or notes imported via gp5 can be 1ms. All notes have a note length based on bpm. Whole notes, half notes, quarter notes, sixteenth notes, 32th notes and so on. Unless the bpm is like 1000bpm and we've got like a 1/1000th speed note, i don't think it's possible to even get a 1ms note.

 

I guess one of the things this really boils down to is note length. In music scores, all notes have a length. Quarter notes, half notes, whole notes, and so on. Right now there seems to be a divide with rocksmith's single note display (without sustain tail).

So the best question we want to ask is, what note type should we make "single note without tail" vs notes with tails? 16th notes based on bpm? or quarter notes? What do you think.

 

Answering this will probably shed some light on how we want to handle chord sustains.

@@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.

 

@@bob64

 

1) crazy status for a chord if there's a rest before no matter what would be simple and still have the exact same effect and easier to implement i guess.

 

2) I'm all for it but don't know how easy it would be to implement it

 

3) it works fine as it is and even if a user parameter to manage the actual duration for the look ahead, i'm not sure it will have any benefit over the first point at all and might even have downside since we have no way of creating a repeat pane in EOF.

3) it works fine as it is and even if a user parameter to manage the actual duration for the look ahead, i'm not sure it will have any benefit over the first point at all and might even have downside since we have no way of creating a repeat pane in EOF.

@@firekorn.

 

I edited my post above with some further discussion points.

 

Ok, lets say eof imports chord lengths as sustains. Whole note-chords take up a whole beat or whatever and so on. All other logic that messes with the sustains of chords is removed.

IF the sustain of one given chord touches the next chord//in the 2d view.
>>>IF the next chord is the same chord as the touching previous chord. 
>>>>>>>THEN mark as a repeat chord. 
>>>ELSE IF the next chord is different
>>>>>>>THEN do nothing. //The previous chord maintains the sustain it has.
>>>ENDIF
ELSE IF there is no sustain touching the next chord, do nothing. //It should display a single chord pane with no sustain in-game

Two big reason why i don't see any benefit in the solution you're suggesting compare to what we have right now :

1) it has to be implemented as it doesn't exist

2) sustain should never touch the next note even for chord to make it looks like official, changing that logic in some case but not all will be messier than using the crazy status

 

on your point 3 that changed => checking the next note/chord might be even worse than checking only 10 seconds in some cases.

 

I think both of you misunderstand sustain as it is shown as a tail in EOF and the handshape that's still maintained over time, both are really different.

 

Chord sustain get imported the same way it is done for single note, that seems to bother a bit Smelly but Raynebc already have in his to do list a way to deactivate the truncation on chord and not on note.

 

Handshape sustain are handle by the look ahead logic that check up to 10 seconds to see if repeat pane can be used and (sadly) those repeat pane aren't really visible in the 2D view (that's why the semi transparent sustain could be an interesting way of displaying it).

 

If a chord have the crazy status, the chord before will have an handshape sustain equivalent to the chord sustain in EOF (if there's no sustain on the chord the handshape sustain is 56ms long => that's what's bother Smelly aka the 1ms chord boxes)
 

So if you want the handshape sustain to be equivalent to the sustain in EOF you just activate the crazy status on the next chord (the status won't change anything else).

 

Why would anyone want to create something else or modify more stuff while this would perfectly do the trick?

 

 

So the best question we want to ask is, what note type should we make "single note without tail" vs notes with tails? 16th notes based on bpm? or quarter notes? What do you think.

This is already answered by the truncate short note function in EOF and i believe it's 16th notes based (longer keep sustain, shorter cut it out).

@@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.

Lots of discussion in this thread, but I'll try to cover the important points:

 

When sustain for individual notes is not needed, then yes, the handshape tag highlighting IS the sustain.

The handshape tag is basically the part of the chart where a single chord fingering remains in use, also controlling whether or not a chord box is displayed for a chord. The handshape mechanism itself doesn't mean any more than that, its exact use is up to the author. Three consecutive G chords could have one handshape covering them all (the highlighting then wouldn't represent sustain of the individual chords), or each could have their own handshape (you can't display the repeated chords as repeat lines if you do this). When there's a chord change, there's a mandatory separate handshape tag, or else the chord change is displayed as a repeat line instead of a chord box showing the change. This is a limitation with Rocksmith's design, it would have been great if there was just a boolen attribute to control a chord displaying as a box or a line.

 

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.

I don't know if official Rocksmith charts always make such a distinction between two repeat chords when there's a short rest between them. As an author you have the option to explicitly use the "sustain" status on a chord to make the chart display tails for the notes in the chord and it will be obvious how long each chord in a handshape is to be played. If you want a separate handshape it's as easy as putting the crazy status on that next chord, or manually marking handshape sections.

 

Are people still creating RS1 charts?

Sure, I can think of at least one hardcore RS1 purist that won't upgrade to RS2. Otherwise I don't believe anybody's done testing to determine if RS2 has any minimum requirement length for handshape chords. If this was done and the results were revealed, I can update RS2 export accordingly.

 

This still all boils down to specific user preference for what the default behavior is. I'm not going to remove the logic that will automatically extend a handshape tag over repeated chords to allow them to display as repeat lines, because this makes a cleaner looking default chart for somebody that doesn't want to spend extra time customizing which chords do or do not display as chord boxes. What I am willing to do is make this logic more customizable so instead of hard-coding it to 10 seconds it can be changed to a different threshold. I just need to plan out the details such as whether this is a per-chart setting (set it once per project) or a user preference (set it once, I'm leaning toward this). Changing the threshold to be based on beat lengths instead of real time adds complexity to how this would be programmed, so I'll probably stick with real time amounts for now. I'll also try to work on the changed GP import logic that will apply crazy status to repeated chords that follow a rest note to force it into a new handshape tag.

 

I really fail to see how chords or notes imported via gp5 can be 1ms. All notes have a note length based on bpm. Whole notes, half notes, quarter notes, sixteenth notes, 32th notes and so on. Unless the bpm is like 1000bpm and we've got like a 1/1000th speed note, i don't think it's possible to even get a 1ms note.

There is a user preference in EOF for Guitar Pro import to remove the sustain from notes (either single notes or chords) shorter than a quarter note. Like was mentioned, this was intended to make the screen less cluttered with short note tails, but it's probably not useful for chords. If most people agree this preference should only apply to single notes and not chords, I'm willing to make that change, just let me know what you all think.

 

3) it works fine as it is and even if a user parameter to manage the actual duration for the look ahead, i'm not sure it will have any benefit over the first point at all and might even have downside since we have no way of creating a repeat pane in EOF.

It's been confirmed that manipulating handshape tag start times (so that a chord begins at least 1ms after the beginning of the tag) is enough to cause the chord to display as a repeat line in-game. Manually creating handshape tags, editing the XML or perhaps trickery involving ghost notes may all be options for forcing repeat lines. It may also be possible to add a status in EOF to try to force a chord to display as a repeat by altering the start time of any handshape tag that would start at that note, but then I have to worry about whether this should be allowed to override manually-defined handshape sections, etc. I don't consider this possibility as immediately high priority as the other things described in this thread.

I'm all for having to separate preferences for the truncation of short notes and the truncation of short chords this, i like to have short chord truncated but i see why some people would not want them to be.

 

I know we can manipulate the xml directly to create repeat pane but the less i have to put my hand in the xml the better i am and i did say that we don't have ways to create repeat pane in EOF. but in the state of things i don't see the need have having a way to create a repeat pane in EOF directly.

 

One thing you didn't talked about @@raynebc is the crazy status to be activated by default (on the chord) when there's a rest before a chord. I'll admit it would be a nice feature to have to make cleaner chart more easily.

I'll also try to work on the changed GP import logic that will apply crazy status to repeated chords that follow a rest note to force it into a new handshape tag.

I did mention it, but it got buried in the giant post.

Lots of discussion in this thread, but I'll try to cover the important points:

 

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.

I don't know if official Rocksmith charts always make such a distinction between two repeat chords when there's a short rest between them. As an author you have the option to explicitly use the "sustain" status on a chord to make the chart display tails for the notes in the chord and it will be obvious how long each chord in a handshape is to be played. If you want a separate handshape it's as easy as putting the crazy status on that next chord, or manually marking handshape sections.

 

 

As far as i know Ubi notetrackers dont author rests, if i remember correctly they argued that it could clutter the screen and that the guitarrist would know after a few plays when to rest by themselfs. I dont agree with it, i always put a crazy when a rest is needed and when there is a sustain on a chord that i want to highlight i use as you said a sustain status on it.

 

about sustain cuts in EOF, i always cut sustain from chords and notes. Its usually 1/16 or 1/12 that i cut but it varies depending on the BPM of the song and the distance of the notes to each other. I feel that the result is always clearner and looks that way more professional. Slides, bends and other special cases are a different story. You just need as a notetracker enough experience to know when to use what.