Jump to content

Latest EOF releases (9-26-2020)


raynebc

Recommended Posts

Sorry guys, it seems some of the numbering of sections wasn't liked by the Customsforge editor. I suppose it's still makes sense and I'd rather not break things trying to fix it since the editor is a bit fussy.

 

 

Thanks @@Chlipouni

 

Good questions below.

 


 

  1) Overlaped handShapes

  In your XML example, there are several overlaped handshapes :

...
  <handShape chordId="4" endTime="7.75" startTime="6"/>
  <handShape chordId="-1" endTime="6.001" startTime="6"/>
...

  What is the purpose of the "dummy chordId handShape" when another handShape starts at the same time position ?

 

 

The only reason why I went ahead and gave some information on the following distinction between dummy chords:

 

"Dummy ChordId Dummy Chords"        and      "Handshape ChordId=-1 DummyChords"

 

is due to the fact that in previous posts I asked consideration for a distinction between both, but Tests 7D Cases C to H as well as Test 11g allowed me to conclude that there is no need to keep considering a distinction because they are essentially the same.

 

Yes "Handshape ChordId=-1 DummyChords" will uniquely work in that they erase authored <chord notes> from a chord box, but, as you point out in your question, I later clued in that nesting handshapes one inside another is redundant. And I clued in that both these two types of dummy chords are one and the same because <chord notes> are not needed for the "Handshape ChordId=-1 DummyChords" plus the <handshape chordId=-1 > tag is redundant when another overall handshape marking is present. Add to this that we can add a handshape associated to a proper chordId to a  "Dummy ChordId Dummy Chord" when no overall handshape exists in order to display fingering and chord label. So as I showed in  Tests 7D Cases C to H as well as Test 11g that both "Dummy ChordId Dummy Chords" and "Handshape ChordId=-1 DummyChords" are really the same thing authored slightly differently.

 

From that point on in the summary I simply refer to "Dummy Chords" and do not make a distinction and it basically refers to "Dummy ChordId Dummy Chord" which Test 6B first revealed that this is a misnomer since a chord template of all -1's is no longer suggested since it registers success for both correct and incorrect notes played. So it is not really a 'dummy chordId' now but actually a proper chordId that is needed.

 

You can therefore now ignore from the testing anything that relates to "Handshape ChordId=-1 DummyChords" since I went on to say in the remaing Summary post that only "Dummy ChordId Dummy Chords" shall now be considered for implementation, unless you guys want to keep "Handshape ChordId=-1 Dummy Chords" alive. In that case, I have kept all "Handshape ChordId=-1 DummyChords" test results and conclusions in the large PNG image files.

 

The only place where I do recommend the use of nested handshape tags in the final implementation is for ease of coding by @@raynebc which I touch on in "EoF Implementation Considerations, bullet 2" whereby if we want to reduce the EoF user's manipulations to author dummy chords, that all dummy chords should have corresponding <handshape> tags associated to a proper chord template. For cases where overall handshapes are already defined, this will imply nested handshapes, where, at worst, the nested handshapes are simply redundant and have no adverse effects if nested.... unless your earlier testing on the matter of nested handshapes shows this to be ill-advised.

 

 


 

  2) Non elimination of single notes

  About the non elimination issue of the surimposed single notes in DDC, it is because the associated handShape has a dummy chordId.

  I can modify this by deducting the chordId from the chord tag at the same time position ...

 

OK, thank-you for considering that!

 

You make me realize that when I performed the DDC tests, I hadn't yet realized  that for unsustained  dummy chords that I don't even need superimposing single notes since the handshape tag associated to a proper chordId is enough to, interestingly,  display the unauthored <chord notes>, so I am thinking that this issue would go away in that case. Superimposing single notes, however are needed for all high density boxes (upon which note gems are desired) as well as low or high density boxes containing sustained notes.

 


  3) Phrases start time

  Your are using phrases which don't start on the main beat of a measure. Is it intentional for testing purposes ?

  For your information I had to add a logic in DDC in order to modify the start time position of the first handShape of a phrase (same time position as the one of the phrase) to avoid a display issue in RS2014.

 

 

Actually I ran all my tests without consideration for beats and instead opted for the clean reporting of results based on rounded numbers as time stamps for notes.  It is only afterwards, when I though I should check DDC's behaviour that I could/should have performed those DDC tests with proper beat synching as DDC prefers. But given the results were not too enigmatic, in rare fashion, I cut corners and simply left it as is since I was satisfied that DDC was working relatively well with Dummy Chords.

 

Thanks for that info. Let me know and I can test other stuff for you if needed.

 

Thanks for reading that long post... :)

"A dreamer is someone who wants beyond what is reasonable. A hero is a dreamer who cannot take no for an answer." (Martin Spina)

My Released CDLC - Blaze Bayley - Stare at the Sun & MacGyver Theme Song & Iron Maiden - No More Lies

Check out the Tech Notes Tutorial Version 1.1 // Chordify Tutorial Rough Draft.

Link to comment
Share on other sites

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

  • Like 7
Link to comment
Share on other sites

@@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?
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

"A dreamer is someone who wants beyond what is reasonable. A hero is a dreamer who cannot take no for an answer." (Martin Spina)

My Released CDLC - Blaze Bayley - Stare at the Sun & MacGyver Theme Song & Iron Maiden - No More Lies

Check out the Tech Notes Tutorial Version 1.1 // Chordify Tutorial Rough Draft.

Link to comment
Share on other sites

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!!!

"A dreamer is someone who wants beyond what is reasonable. A hero is a dreamer who cannot take no for an answer." (Martin Spina)

My Released CDLC - Blaze Bayley - Stare at the Sun & MacGyver Theme Song & Iron Maiden - No More Lies

Check out the Tech Notes Tutorial Version 1.1 // Chordify Tutorial Rough Draft.

Link to comment
Share on other sites

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.

"A dreamer is someone who wants beyond what is reasonable. A hero is a dreamer who cannot take no for an answer." (Martin Spina)

My Released CDLC - Blaze Bayley - Stare at the Sun & MacGyver Theme Song & Iron Maiden - No More Lies

Check out the Tech Notes Tutorial Version 1.1 // Chordify Tutorial Rough Draft.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

"A dreamer is someone who wants beyond what is reasonable. A hero is a dreamer who cannot take no for an answer." (Martin Spina)

My Released CDLC - Blaze Bayley - Stare at the Sun & MacGyver Theme Song & Iron Maiden - No More Lies

Check out the Tech Notes Tutorial Version 1.1 // Chordify Tutorial Rough Draft.

Link to comment
Share on other sites

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.

"A dreamer is someone who wants beyond what is reasonable. A hero is a dreamer who cannot take no for an answer." (Martin Spina)

My Released CDLC - Blaze Bayley - Stare at the Sun & MacGyver Theme Song & Iron Maiden - No More Lies

Check out the Tech Notes Tutorial Version 1.1 // Chordify Tutorial Rough Draft.

Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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?

"A dreamer is someone who wants beyond what is reasonable. A hero is a dreamer who cannot take no for an answer." (Martin Spina)

My Released CDLC - Blaze Bayley - Stare at the Sun & MacGyver Theme Song & Iron Maiden - No More Lies

Check out the Tech Notes Tutorial Version 1.1 // Chordify Tutorial Rough Draft.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

"A dreamer is someone who wants beyond what is reasonable. A hero is a dreamer who cannot take no for an answer." (Martin Spina)

My Released CDLC - Blaze Bayley - Stare at the Sun & MacGyver Theme Song & Iron Maiden - No More Lies

Check out the Tech Notes Tutorial Version 1.1 // Chordify Tutorial Rough Draft.

Link to comment
Share on other sites

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!

"A dreamer is someone who wants beyond what is reasonable. A hero is a dreamer who cannot take no for an answer." (Martin Spina)

My Released CDLC - Blaze Bayley - Stare at the Sun & MacGyver Theme Song & Iron Maiden - No More Lies

Check out the Tech Notes Tutorial Version 1.1 // Chordify Tutorial Rough Draft.

Link to comment
Share on other sites

 

 

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).
Link to comment
Share on other sites

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.

"A dreamer is someone who wants beyond what is reasonable. A hero is a dreamer who cannot take no for an answer." (Martin Spina)

My Released CDLC - Blaze Bayley - Stare at the Sun & MacGyver Theme Song & Iron Maiden - No More Lies

Check out the Tech Notes Tutorial Version 1.1 // Chordify Tutorial Rough Draft.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. - Privacy Policy