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.

I'm making an effort to wrap up documentation updates for a new release candidate, since RC10 was close to 2 years ago now.

 

After I can get that accomplished, I'll have time to study your findings more closely.

Hi, folks. After about 22 months since the last release candidate, I finally went through all the documentation updates and put together 1.8RC11, which is available in the first post. Changes since the previous hotfix are as follows:

*Improved RS exports to offer to highlight notes that go above the supported fret limit for either game.

*Improved RS exports to offer to highlight notes that slide to or above fret 22, since these aren't compatible with either game.

*Improved lyric export to add handling for there being an empty lyric line (depending on the lyric format being exported) as the last line of lyrics in a project.

*Improved technique phrase (ie. handshape, tremolo, arpeggio) marking so that even if a note has linknext status, both it and the note it links to can be put into separate phrases.

*Updated EOF to launch the new chart wizard if a WAV file is passed as an argument over the command line.

 

The absurdly long changelog for this release candidate is available here:

http://www.fretsonfire.net/forums/viewtopic.php?p=640343#p640343

@@Berneer, I fixed the note count issue you mentioned in test 4g conclusion 3. I'm still sifting through all this information.

 

Edit: I also fixed the duplicate chord template issue regarding split chords inside a handshape.

 

Edit 2:

I also noticed lots of redundant FHP’s in repeated tags.

Could you give me a short example of where this happens?

Let me just summarize with some comments/questions I have about the dummy chord robustness test pictures so I can be sure I have a grasp over everything:

 

Test 2 PNG

Being able to display chord boxes for single notes is what I'd consider to be one of the most interesting aesthetic effects of the dummy chord mechanism.

 

Test 3 PNG

The 56ms padded length for handshape tags was implemented for RS1 era CDLC due to a perceived requirement by that game, or at least it seemed to be a standard observed by official charts. It's possible this has no benefit in RS2, does anybody know if RS2 CDLC should have any such padding?

 

Test 4 PNG

If I remember correctly, individual notes in a chord not being able to display in-game with separate lengths turned out to be a limitation with either the toolkit or Rocksmith. Using split status to force the chord to be written as single notes was the best workaround we could find, but now this meant it would not appear to be a chord in-game because there would be no chord pane. This side effect would be a primary reason for the need of a dummy chord mechanism, right?

 

Test 7 PNG

The "unk5" attribute you found in the bendValue tag is not something EOF would have written. I'm guessing this was something put there by the toolkit.

 

Your tests seem to prefer marking the single notes (that overlap the dummy chord instances) in the export as being ignored. Does this serve a functional difference to using the ignore attribute for the dummy chord's chord tag itself, or the ignore attribute for the dummy chord's chordnote tags? I don't know if you tested such a usage, but if not, it may be possible that if all three of these give the same results, the additional options may allow more flexibility with implementation. Perhaps marking the dummy chord instance itself as ignored may allow us to use an all -1s dummy chordid dummy chord template without any scoring/graphical issues? If absolutely necessary, we could pursue an implementation using nested handshape tags, but barring any major deficiencies I'd want to go with the simplest solution possible. It would also make it easier to interpret in the RS import logic.

Oh no, thats Berneer busy for another month.  We ain't never gonna see this Blaze custom :lol:

I'd be fine with even just the findings of a small amount of testing. If it turned out not to work, I could pusue the proposed method in test 11a.

@@Berneer, I fixed the note count issue you mentioned in test 4g conclusion 3. I'm still sifting through all this information.

 

Edit: I also fixed the duplicate chord template issue regarding split chords inside a handshape.

 

Edit 2:

I also noticed lots of redundant FHP’s in repeated <anchor time> tags.

Could you give me a short example of where this happens?

 

 

Oh wow, you actually went ahead and read the verbose PNG files. I think that was a good move even though I tried to save your time with a summary post...

 

I will try to answer as many of your questions now before my kid wakes up. If I don't get though it I'll try to answer all by tonight.

 

Regarding your last question I quote above,this is something I found in the EoF export of the final test I made for the post summary which contains every dummy chord case (with & without sustain, high density, handshape).

 

notes.eof

 

XML file

 

 

@PC Plum that was very funny! I must admit I need a little break but I'll resume the Blaze custom soon enough. LOL

Let me just summarize with some comments/questions I have about the dummy chord robustness test pictures so I can be sure I have a grasp over everything:

 

Test 2 PNG

Being able to display chord boxes for single notes is what I'd consider to be one of the most interesting aesthetic effects of the dummy chord mechanism.

 

 

 

Really? Please do share your thoughts as to why authoring chord boxes around single notes is of such importance. I'm genuinely curious. I just tested it because @@Chlipouni mentionned something once about lower levels of DD doing this even though I never fully understood why.  :) Sorry chlipouni, I know you tried re-explaining it, but I didn't understand... :(

 

Test 3 PNG

The 56ms padded length for handshape tags was implemented for RS1 era CDLC due to a perceived requirement by that game, or at least it seemed to be a standard observed by official charts. It's possible this has no benefit in RS2, does anybody know if RS2 CDLC should have any such padding?

 

 

OK. When testing I came to the conclusion that handshapes automatically authored with 56ms duration for all authored unsustained chords was probably an aesthetics thing. When you set a handshape to 1ms, it does whisk away that chord label a bit abruptly whereas, with 56ms the chord label disappears less aggressively. Since 1ms padding worked for me during testing it seems there is no game limitation. I tried it many times and it never caused me any problems. The only reasons my final recommendation was not 56ms was two-fold: 1) I didn't want to take chances that someone would place neighboring independent notes less that 56ms apart.  2) I hoped to make it very obvious with 1ms that this would be a quickly deciperable way during XML inspections that we were dealing with a dummy chord.

 

But 56ms is fine if you want to maintain it that way. In fact whatever duration you'll choose will work.

 

Test 4 PNG

If I remember correctly, individual notes in a chord not being able to display in-game with separate lengths turned out to be a limitation with either the toolkit or Rocksmith. Using split status to force the chord to be written as single notes was the best workaround we could find, but now this meant it would not appear to be a chord in-game because there would be no chord pane. This side effect would be a primary reason for the need of a dummy chord mechanism, right?

 

 

I think what you are saying here is correct.  The original problem was raised by @@mrmaton and summarized here. We had raised a GitHub bug #153. Initially we found the linkNext Tech note was not working as you had programmed it, whereby it would show note heads randomly despite the authoring of linkNext tech note. At the time you tried to resolve this on EoF-side with a workaround but then I noticed the work-around would work fine for mrmaton's case but looked less intuitive for another case from my Blaze custom. See image below.

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/HOPOonSomeStringsOfChord-GitHubIssue153/SatS%20Intro%20single%20string%20HO%20on%20chord%20-%20Question%20GitHubIssue153_zpsnph4ryii.png

 

You then went on in December 2015/January 2016 time frame to adjust the initial March 2014 attempted EoF-workaround with some new note cleanup logic due to the following image which would sustain the B12 note undesirably throughout (or in mrmaton's case above bottom right image the G9 note.

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/HOPOonSomeStringsOfChord-GitHubIssue153/Example%202%20-%20Hotfix%2012-24-2015_zpsq6sfqjmx.png

 

 

which allowed to now at least use the split status to author everything nicely minus the ability to display the chord box, as can be seen in my Robustness Test 4a. Now enter the idea of dummy chords and we could finally author what we wanted in the first place as you can see below as an excerpt from Robustness Test 4g:

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Initial%20inspiration%20case_zpsuuq60x3s.png

 

 

Test 7 PNG

The "unk5" attribute you found in the bendValue tag is not something EOF would have written. I'm guessing this was something put there by the toolkit.

 

 

OK. Does anyone know what "unk5" is meant for in XML?

 

Ex:

          <bendValues>
            <bendValue time="6.75" step="1" unk5="0" />
            <bendValue time="7" step="0" unk5="0" />
          </bendValues>

Your tests seem to prefer marking the single notes (that overlap the dummy chord instances) in the export as being ignored. Does this serve a functional difference to using the ignore attribute for the dummy chord's chord tag itself, or the ignore attribute for the dummy chord's chordnote tags? I don't know if you tested such a usage, but if not, it may be possible that if all three of these give the same results, the additional options may allow more flexibility with implementation. Perhaps marking the dummy chord instance itself as ignored may allow us to use an all -1s dummy chordid dummy chord template without any scoring/graphical issues? If absolutely necessary, we could pursue an implementation using nested handshape tags, but barring any major deficiencies I'd want to go with the simplest solution possible. It would also make it easier to interpret in the RS import logic.

 

Yes, I noticed in Riff Repeater (by extension in-game scoring be it in Score Attack or Learn a Song) that if we, for example, author a dummy chord for a 2-string power chord, then if neither single notes or dummy chord is set to ignore="1" then the game will consider playing the chord as 3 distinct successes and if misses, as 3 different misses.

 

As such, since a regular chord counts as 1 hit or miss in Rocksmith 2014, the obvious choice was to set ignore="1" on all single notes authored upon a dummy chord. This way missing the dummy chord counts as 1 miss, hitting it counts as 1 hit.

 

I did test it the other way around and it works, setting the dummy chord (<chord time>  tag) to ignore = "1", then that above example of a two-stringed power chord would register as 2 hits/misses. I personally don't really care about points in Rocksmith 2014 but given the Championship-folk play in Score-Attack I figured we should respect the 1 miss/hit per event way of Rocksmith 2014 to tally score.

 

As noted in my dummy chords summary post this week and in the conclusion of Test 7a, one of the necessary evils of dummy chords with sustained notes superimposed upon them set to ignore="1" is that missing the dummy chord will correctly see the chord not score (blink) in-game, but given the single notes are set to ignore ="1", the fret(s) surrounding single note(s) will blink no matter if the correct notes were hit or not, perhaps fooling the player into thinking they got something right. But I think that a chord box not blinking is quite obviously a miss despite a few frets blinking so I think we can accept this "necessary evil" of sustained single notes (set to ignore ="1") superimposed upon dummy chords".

 

Plus if you were to set <chord time> to ignore ="1" with sustained notes superimposed, you'd have to have a different logic of not setting ignore="1" when there are no sustained single notes on the dummy chord.

 

Instead it seems simpler to me (but you are the judge @@raynebc) to have one consistent logic:

• Sustained notes required on dummy chord --> <chord time > tag set to ignore ="0", super-imposing <note time> tags set to ignore ="1"
• No sustained notes required upon dummy chord --> <chord time > tag set to ignore ="0"  (handshapes display unauthored chord notes without sustains)

 

Since I don't recommend the export of <chord note> tags (since they are not needed) for dummy chords, I haven't tested the effect of setting those tags to ignore ="1".

 

Once you read this explanation feel free to request some additional testing to help your implementation. But at this time I'm not sure what it is that I would be testing exactly.

 

When you say "Perhaps marking the dummy chord instance itself as ignored may allow us to use an all -1s dummy chordid dummy chord template without any scoring/graphical issues?" I am not sure what you are getting at since I concluded (in Test 6b) that we shouldn't be using chord templates of all -1's since that construct will record both misses and hits as successes. The only graphical "issues" with chord templates of all -1's is that 2-stringed chords will author a box instead of goal-posts. But in terms of scoring, a chord template of all -1's, is undesireable.

 

Yes, I believe that authoring those nested handshape tags is fine and exhibits no-problems in game. There is no need for nested handshape tags if it is a pain for you. I only recomended it for simplifying the EoF logic whereby if we want chord labels and fingering  displayed in sequences with no overall handshapes we define 1ms handshapes, but in sequences with an overall hanshape I tested that there no adverse effects of nesting a 1ms hanshape inside an overall hanshape. This way you can have a ono-to-one relationship where every dummy chord comes with a 1ms handshape, the same way a regular chord creates a 56ms handshape. Then again, for regular chords in an overall handshape I'm betting you forego the 56ms handshape tag, so really it is per your preference really.

 

Did i properly understand your questions? For now I will await your responses, @@raynebc to see if you need me to test anything.

 

Cheers and thanks for your time!!!

I'd be fine with even just the findings of a small amount of testing. If it turned out not to work, I could pusue the proposed method in test 11a.

 

OK, with the understanding that the 1ms handshape tags are redundant in that Test 11a but can remain if it is desired for EoF coding simplicity to automatically export a 1ms handshape every time a dummy chord is authored.

 

Test 11a authors superimposing single notes despite it only being necessary to author superimposing single notes for sustained dummy chords. When not sustained, no superimposing single notes are authored and the unauthored chord notes will display in-game like the right-most image in Test 11a since with the absence of <chord note> tags, a <handshape> tag pointing to a proper <chordTemplate> tag is enough to authored what I call "unauthored" chord notes.

OK, it sounds like trying to mark the dummy chord instances themselves as ignored has problems so I won't worry about pursuing that.

 

Regarding your last question I quote above,this is something I found in the EoF export of the final test I made for the post summary which contains every dummy chord case (with & without sustain, high density, handshape).

I'll look into this soon.

 

Please do share your thoughts as to why authoring chord boxes around single notes is of such importance.

Not important so much as just being interesting in that it would probably be unique to CDLC. I doubt official DLC would use chord boxes for single notes.

 

This way you can have a ono-to-one relationship where every dummy chord comes with a 1ms handshape, the same way a regular chord creates a 56ms handshape.

Is the 1ms handshape mainly to prevent the fingering animation from displaying long enough to be noticed? Am I missing other uses for it, like chord pane shape/size? Me removing the 56ms handshape padding and instead making it strictly the length of the chord as it is authored would probably cause more problems than it's worth though, as it's common for people to author chords without sustain but they'd still want the fingering to display long enough to be easily read, like in official charts.

 

Just so I know the correct next step to take in EOF, we want this new dummy chord status to affect export as follows?

1. An affected chord will export as a chord tag as is normal. The author can decide whether to try to influence the chord tag's density to control the shape of the chord pane, or I could try to have EOF automatically decide which density to use depending on whether open notes are included in the chord?

2. It will also export as ignored single notes, but only if the chord requires sustain?

The redundant FHPs issue turned out to be correct behavior. The FHP is forcefully placed again at each RS phrase change so that it works correctly in charts with dynamic difficulty. After I removed the RS phrases, one FHP was generated to cover your test file.

This way you can have a ono-to-one relationship where every dummy chord comes with a 1ms handshape, the same way a regular chord creates a 56ms handshape.

Is the 1ms handshape mainly to prevent the fingering animation from displaying long enough to be noticed? Am I missing other uses for it, like chord pane shape/size? Me removing the 56ms handshape padding and instead making it strictly the length of the chord as it is authored would probably cause more problems than it's worth though, as it's common for people to author chords without sustain but they'd still want the fingering to display long enough to be easily read, like in official charts.

 

Just so I know the correct next step to take in EOF, we want this new dummy chord status to affect export as follows?

1. An affected chord will export as a chord tag as is normal. The author can decide whether to try to influence the chord tag's density to control the shape of the chord pane, or I could try to have EOF automatically decide which density to use depending on whether open notes are included in the chord?

2. It will also export as ignored single notes, but only if the chord requires sustain?

 

 No the 1ms  handshape doesn't do any such thing as display a chord label and fingering that lasts only 1ms, essentially flashing and disappearing. I chose 1ms because I just needed a handshape to encapsulated the instant the unsustained dummy chord was authored. I could have chosen other than 1ms.

 

You can download the psarc of the final sample which I linked to in order to see the 1ms handshapes in effect (or click the YouTube link of the in-game footage). Visually a 1ms handshape will appear in advance of the dummy chord as the dummy chord is coming down the highway (therefore lasting much longer than 1ms), however the chord label will disappear a bit abruptly 1ms  (instead of 56ms) after the beginning of the handshape as the notes cross the note highway threshold, and the fingering will disppear abuptly too unless there are other subsequent identical fingerings for subsequent chords, in which case the fingers just stay put until they are no longer pertinent.

 

1 ms (or whatever length you choose)  handshapes for dummy chords serve 3 purposes:

1) display chord labels when no overall handshapes are present.

2) display fingering

3) for the cases of no sustains, and therefore no need for superimposed sustained <note time> tags, since there are no <chord note> tags in dummy chords, it is the 1ms handshape that authors the so-called "unauthored" chord notes by virtue of a 1ms <handshape> tag associated with a proper <chord Template>.

 

You don't have to remove the 56ms padding. You could either make them 1ms only when a dummy chord is being authored, or make dummy chord 1ms handshapes as 56ms handshapes. That 's fine. Yes when a sustained dummy chord needs single notes with a specified amount of sustain then instead of 1ms I recommend a handshape the intended duration of the sustain instead of 1ms. So in the final sample example in my summary post I showed a 750ms duration handshape.

 

In terms of implementation, I didn't want to presume too much how you would go about coding this so I opted to show my recommendations on the mechanism of dummy chords with you deciding how to implement and perhaps even ignore some scenarios such as low density chord notes and single notes making cross-shaped gems, which are easily dismissed by opting for high density dummy chords, for example. That said, I did think it might be useful to provide you some of those "implementation" considerations in the summary post.

 

Yes you have the option of allowing the user to decide upon the chord box shape by giving him/her authority over the density of the chord box, but for simplicity I had imagined you might go ahead an automate it to some extent. Your choice. Low density chord boxes have a tendency to be short enough to not encapsulate all the notes so I would've preferred some sort of automation if possible to prevent  charts with users complaining about notes sticking out of the chord box. Yes that open string visual glitch is rectified by forcing the export of high density, so there is another example where automation is well-advised.

 

When you say "An affected chord will export as a chord tag as is normal" I agree except that it is not like a normal chord because, with dummy chords, it is a <chord time> tag without <chord note> tags inside.

 

When you say "It will also export as ignored single notes, but only if the chord requires sustain?" --> Yes

 

Ask away, I'm happy to answer since I know it is a bit much to all take in. If you would prefer to Skype or Steam chat, let me know and we could set that up.

OK, I'll start with trying to get this to work for chords. Getting it to work for single notes will require extra attention because EOF doesn't currently generate chord templates for anything that isn't a chord.

I am not sure if there is any confusion but unless you wanted a chord box around 1 note the dummy chord mechanism could be authored as a chord and then when a sustained dummy chord is authored you need simply author, on top of a <chord time> tag and <chord template> you would add superimposing single notes with sustain, so the template already exists.

Sorry to break up your little handshape party with a problem :(

 

http://images.akamai.steamusercontent.com/ugc/320125724618391507/0FEBBA34E375C4FA6DAE3652AF2BBC1CCA1BEFF5/

 

I wanted so much to report a flawless entry to the world for RC11 and it took up until I tried to be sociable and add handshapes :lol:

 

 

Files

 

https://drive.google.com/file/d/0B2oZs0ta32KyZjZtSXNjM3BHdVE/view?usp=sharing

 

 

 

Good luck on the dissertation Berneer :D

Here is a simplified XML excerpt of where this feature is with EOF now:

http://i15.photobucket.com/albums/a354/raynebc/EOF%20dummy%20test%201_zpshkjc6pyw.jpg

...

Normal chord

 

Dummy chord with no open notes (low density OK)

 

Normal chord

 

Dummy chord with open notes (high density required) and sustain status (ignored note tags required)

 

Dummy chord with no open notes (low density OK) and sustain status (ignored note tags required)

 

Split chord with the A string linked to a note at 1750ms

 

The non-linked note at 1750ms

 

Dummy chord with the A string linked to a note at 2250ms, no open notes (low density OK), the A string is sustained because it links (ignored note tag for this string required)

 

The non-linked note at 2250ms

 

Dummy chord with the A string linked to a note at 2750ms, no open notes (low density OK), the A string is sustained because it links, the E string explicitly has sustain status (ignored note tags required for both)

 

The non-linked note at 2750ms

...

At this point, all notes with "chordify" status (the ones with the "C" designation below the piano roll) ignore split status and split up based on their own needs (if the chordnotes would sustain).

Hi @@raynebc,

 

I've looked it over and I think this all looks great and correct.

 

Couple of questions/comments:

 

1. I don't know if it is Rex Mundi view with which I am unfamiliar, but the normal chords at 0.250s and 0.750s seem to visually have a note tail on the piano roll but the sustain attribute in the XML shows 0 sustain. Not related to dummy chords but it had me confused for a couple of minutes.

 

2. I never used the "sustain" status since I believe I was once told it was a relic from RS1, so it seems like the ideal candidate to let the user decide if he/she wants to sustain the note(s) or not.

 

3. I like what you did at 2.000s which has one note in the chord sustain due to a linkNext tech note and the other string doesn't sustain at all. I've been wanting to be able to do that for a while! This reminds me, that like my Blaze custom, the dummy chord can be used for situations when we see "Let ring......" on music sheets. Awesome!! I'll add that to the Tech Notes Tutorial  once I finish my Blaze custom. (Though of course I'd write a dummy chords tutorial before my Blaze custom so that people can use dummy chords with confidence in the near term)

 

4. Sustain tech note: sweet!

 

5. Not sure I fully understand your statement: "At this point, all notes with "chordify" status (the ones with the "C" designation below the piano roll) ignore split status and split up based on their own needs (if the chordnotes would sustain)." I am not sure what you mean because, in your example, none of your timestamps have both a "split" and "chordify" status simultaneously. By "split up based on their own needs (if the chordnotes would sustain)" I imagine you mean that "split" status will be overruled by tech notes if both we to exist on the same note/notetail?

 

6. Since, at 2.000s, visually on the piano roll you have an E2 note sustaining and an A1 note linked with LinkNext Tech note. I suppose this is a nice example where the handshape and chord template display the unauthored (and unsustained) E2 note while the linked A1 note has sustain and therefore a superimposed sustained single note. I guess what confused me is allowing the E2 note to visually sustain on the piano roll but I guess you did that on purpose to see if the handshape+chord template would do it's job of authoring an unsustained E2 note despite visually sustaining it?

1. This wouldn't be related to the input mode in use (Rex Mundi has you mouse over where you want notes and then press a number key from 1 to 6 to place a note on that string).

 

2. As per established Rocksmith CDLC authoring conventions, unless a chord has a technique that requires the sustain to be kept, the sustain is removed from the export. The "sustain" status was added a couple years ago as the mechanism allowing the author to specify that the sustain for a note is to be exported regardless of techniques involved. I'd not heard of any complaints, so this mechanism has been kept in use since then.

 

4. Any Rocksmith technique in the lower half of the "Edit pro guitar note" dialog can be applied to a tech note.

 

5. Yes, the current Git revision of EOF won't prevent the author from putting both the split and chordify statuses on a chord at the same time, but if that is done, RS2 export ignores the split status and chordify takes precedence since it has conflicting rules on which single notes are exported.

 

6. The piano roll is largely oblivious to the special rules for each game format that can be written and would show all notes as they exist in the project instead of how they would actually export. The 3D preview's RS chords option follows Rocksmith rules a little more closely, but not enough so to display when complex manipulations are performed during RS2 export (such as linked notes being combined). I'm not aiming for 3D preview to be 100% authentic to RS2 export because it's still meant to reflect the editor window (piano roll) overall.

 

Should I go ahead and proceed on with the logic to handle chordified single notes? I should be able to get that to work in a few steps:

a. Unique chordified single notes have to have a chord template written.

b. Chordified single notes have to have a chord tag written.

c. If the single note has a length greater than 1 it will be written as an ignored single note tag. In this case I'm not immediately sure it should be required for the single note to have sustain status or another technique in order to keep its defined sustain. I'm thinking it would be easier on the author to not have to apply chord based considerations like sustain on it since it's still a single note.

Should I go ahead and proceed on with the logic to handle chordified single notes? I should be able to get that to work in a few steps:

a. Unique chordified single notes have to have a chord template written.

b. Chordified single notes have to have a chord tag written.

c. If the single note has a length greater than 1 it will be written as an ignored single note tag. In this case I'm not immediately sure it should be required for the single note to have sustain status or another technique in order to keep its defined sustain. I'm thinking it would be easier on the author to not have to apply chord based considerations like sustain on it since it's still a single note.

 

Thanks for the explanations @@raynebc!

 

From your questions, in general, it seems like you have fully digested everything I wrote up. I could only assume that when you say "logic to handle chordified single notes" you mean 'encapsulate with a chord box single notes authored on the piano roll that are at either at identical time stamps or very near time stamps'. I guess I just want to be sure I understand you because I'm used to EoF forcing multiple identically timed single notes to be treated and manipulated as a chord. Then I typically authored dummy chords by applying "split" status and therefore have 'access' to each note individually. I'm pretty sure we mean the same thing, so I would say it seems that you are good to go ahead with "the logic to handle chordified single notes".

 

Just to be sure when you say "If the single note has a length greater than 1 it will be written as an ingnored single note tag." I'm assuming you are referring to a note with sustain greater than 1ms, in which case EoF will be satisfied that the dummy chord must be authored with superimposing single note.

 

I would imagine if the single note is authored in EoF with a note tail that it need not additionally have a sustain status but I guess testing will show upon implementation. I'll obviously test what I think to test but feel free to make me a grocery list of things you'd like me to check for you.

 

One thing I am wondering, you seem to be talking about manipulating single notes to be 'chordified' so I am wondering if you are changing things such that  two or more identically timed single notes will no longer necessarily be manipulated as a unit. If so, I am surprised, because I thought that logic was necessary to author regular chords, so I look forward to see what you have been cooking.

 

You mention Github, do you already have an EoF-pre-Hotfix you would like me to test? No rush. Whenever you are ready.

In regards to this new feature being used for single notes, I mean being able to have one single note display in-game with a chord box.

OK, so though I didn't have much time to try out a bunch of tests, I tested the exact authoring you posted a few posts above in Post #1592, with all identical time stamps. This shows that your changes work. This is what I get in-game, which is pretty much as intended. You obviously put everything close together in EoF for illustrative purposes and in-game it is tight but we can still make things out.

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/raynebcs%20sequence%20for%20initial%20implemenation%20from%20March%20132016%20Pre%20Hotfix_zps2yttjxgw.png

 

I get it now, when you author a note in EoF it automatically comes with a note tail as always (which I always automatically shortened down to 0ms by rolling the mouse wheel back). Chords ignore that sustain unless, as  you say, a technique is applied upon it's tail, such as 'sustain' status. However a handshape tag does not ignore that note tail and extends it's duration to contain the note tail, as seen by your XML handshape tags shown in Post #1592.

 

It makes sense that chords instead of single notes be the objects "chordified" since after all we are adding <chord time> tags minus the <chord note> tags. Some users might ask why one would "chordify a chord" but I suppose that is where a tutorial will come in. I am thinking that if one wanted to "chordify" nearby notes one would have to select all notes to chordify, ensure that only one note per string is selected and then proceed to mark some colour, not unlike handshape marking, that those selected chords are chordified.

 

I guess I'll have to test this later but if one wants to "chordify" a chord not in a handshape, without single notes (due to no sustain) and just with a chord template, then  just a box without notes will display?

 

 

In regards to this new feature being used for single notes, I mean being able to have one single note display in-game with a chord box.

 

raynebc, on 13 Mar 2016 - 4:03 PM, said:

 

Should I go ahead and proceed on with the logic to handle chordified single notes? I should be able to get that to work in a few steps:
a. Unique chordified single notes have to have a chord template written.
b. Chordified single notes have to have a chord tag written.
c. If the single note has a length greater than 1 it will be written as an ignored single note tag. In this case I'm not immediately sure it should be required for the single note to have sustain status or another technique in order to keep its defined sustain. I'm thinking it would be easier on the author to not have to apply chord based considerations like sustain on it since it's still a single note.

 

Got it. So in response I would say, that it it is fine to implement that too, but note from Robustness Test 2 that the only way to make that work intuitively in-game is if the chord template you author for that is one of all -1's since the Toolkit will not allow a template with only 1 string fretted (not equal to -1). The negative side of doing it this way is that a dummy chord based on a chord template of all -1's will register as a success no matter if the correct or incorrect note is played.

 

 

 

Please let me know if you want me to test anything else before you add any further EoF coding for dummy chords (aka Chordify feature), if you are adding any further coding. Once you tell me you are done, if not already the case,  I can go ahead and try to reproduce all/most of my Robustness testing XML mods directly in EoF.

 

Thanks raynebc. Nice and clean implementation from what I've had time to see so far!

 

 

Some users might ask why one would "chordify a chord" but I suppose that is where a tutorial will come in.

At this time, the only useful purpose I can think of to use the chordify status on chords is to work around the issue where the game/toolkit can't show a chord where the strings have different lengths (ie. your previous example where one string in a chord continues to sustain on top of hammer ons and pull offs on the other string).  The split status was one workaround to get around the limitation, but then the chord displays as multiple overlapping single notes and not as a chord.  Using "chordify" instead will author the same thing, but in the "dummy chord" method you've been describing.

If a handshape phrase isn't authored for a chord with this status, it will use the normal handshape tag EOF ends up creating to encompass the chord.  So while controlling the handshape isn't a requirement, the chord at the base of a handshape phrase could probably be chordified to get whatever effect the author wanted, but I suppose that remains to be verified in testing.

 

So in response I would say, that it it is fine to implement that too, but note from Robustness Test 2 that the only way to make that work intuitively in-game is if the chord template you author for that is one of all -1's since the Toolkit will not allow a template with only 1 string fretted (not equal to -1). The negative side of doing it this way is that a dummy chord based on a chord template of all -1's will register as a success no matter if the correct or incorrect note is played.

That's a bummer, although it's possible that could simplify my implementation (no need for a unique template for each single note that has chordify status).

Ok so it seems that you've completed the chordify implementation in EoF then, so I'll go ahead an test it out a bit more with Robustness test examples now to be authored in EoF directly.

 

 

... the chord at the base of a handshape phrase could probably be chordified to get whatever effect the author wanted, but I suppose that remains to be verified in testing.

Curious, what are examples of what you mean by "whatever effect". I am wondering if you've imagined things I haven't yet. Or do you just mean the same example of HOPO on select strings of a chord, but with other effects that are not HOPO's?

 

I'll try to give some thought to whether there are other practical uses of "chordify"/dummy chords, specifically situations whereby nearby notes need to appear as being a chord. I know I've had problems in the past with crazy status forcing me to make single notes close but not exactly at the same time. I guess I gotta think back a little... Perhaps to my MacGyver CDLC finger-style arrangement which was quite challenging to author.

I guess I mostly meant that the author can decide whether to apply a handshape tag if he/she wants to influence the fingering animation for chords that follow a chordified note or not.

Hi @@raynebc et al.

So I realized that testing your new "chordify" implementation for the imminent next Hotfix is most easily testable by attempting to author the "Final Sample" sequence from the end of my Dummy Chords Test Results post since it contains all the permutations. On top of that tomorrow morning I'll additionally try to reproduce Robustness Test 9 directly from EoF: that's the robustness test where I tested dummy chords with various techniques on them.

So here goes, the following is basically the "final sample" example from my test results post except that instead of split status and modding the XML manually, I authored everything as below directly in EoF.

Zoomable Link

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Final%20Sample%20now%20with%2003-13-2016%20Implementation_zpswvdzsvdx.png

I was happy to see that EoF (based on the Pre-Hotfix 03-13-2016) is pretty much implementing dummy chords very well. The following are a few comments:

1) Here is EoF export from the above image and here is the notes.eof file for the above authoring. Here is the reference XML output from the Robustness Test Results post.
2) I took a guess that if I applied "hi dens" status to the "Chordified" chord, that the <chord time> 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. Do you prefer we don't allow the authoring of high density boxes (via the "hi dens" status)? I'm starting to think we should allow the user to control the dummy chord box density since ultimately it boils down to what the user's chart finds least offensive: 1) low density chord box with cross-shaped gems due to superimposed chord and single notes OR 2) high density chord box that may have notes above the box due to a shortened box.
3) Apart from the check-marked "hi dens" status currently exporting "chordified chords" (I'm wondering if the status name "chord box" will see less questions asked by users ...) with high density ="0" chord tags, the only other notable difference from the EoF-authored example in the image above and the reference (XML-modded) case is that the chords at 2s and 3s export a half second handshape tag as follows:

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?

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, like Robustness Test 11a. I'm thinking there is no way to do this right now and perhaps there is no need for it?

Regarding the other possible uses of Chordify...

So I tried to go back and figure out where one would need to desynch notes of a chord and benefit from adding a chord box around those desynched notes. It turns out 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. I thought it had to do with Crazy status and linknext not working as expected from this post you responded to me but I guess it is not pertinent for dummy chords. The closest thing I could find was my MacGyver CDLC, the Finger-style Rhythm arrangement, in the sequence shown below where a chord is played but slightly de-sycnhed. I just ended up using an arpeggio because your suggestion with LinkNext didn't work. The arpeggio ended up cluttering the chart, but it is good enough. I was thinking that finger-style guitar has a lot of de-sycned (or I guess arpeggiated is the better word) chords and that if that G2 note or E3 note shown below were even closer to the main chord that a dummy chord was probably a good way to author it since it would show a chord label and fingering, though tell the player to hit all notes simultaneously despite the more nuanced de-sych...

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/MacGyver%20Example%202_zps9bqg5v36.png

Another MacGyver finger-style example I stumbled upon, which I forgot about, surprised me because it authored without a chord box. I guess I'll have to explore this further but perhaps at the time the Crazy status in a handshape was splitting the chord into single notes (?) ..... I authored this with Hotfix 1392 (April 19, 2015) in this exported XML, which I will explore further and try to re-author again out of curiosity.

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/MacGyver%20Example%201_zpsragoofse.png

I thought maybe grace notes might benefit from this, but, I'd have to give it some more thought. Perhaps I'm wrong. I was envisioning a split chord with one note having a rapid unpitched slide.... but I might be off here. I'll let you know if I think of something.

I suppose if new ideas come up we'll see if if "chordify" is the solution when the question arises. For now I suppose the best documented need for "chordify" is indeed a chord with differently sustaining strings.

Cheers!