Berneer

My first guess is that, since they're chords, the sustain isn't automatically kept because they have no techniques requiring sustain, and that applying sustain status would resolve this. If this doesn't get the result you're looking for, let me know. Ah yes, of course, I forgot the "sustain" status. Works fine now. OK, so I tested Robustness Test 9 with Techni ques on Dummy Chords with your Hotfix 03-13-2016 and I get the following. I have to rush to work so some of the conclusions are sparse and referring to follow-up checks I need to make tomorrow. Sorry. Limited time.... :) Here is a PNG file will all the screenshots. Here is the associated notes.eof file in case you want to look more closely. Here is the associated XML export. Have a great day!

Was there a reason each chordified note needed its own handshape tag in this example? The half second handshape covering both chords in each chord change seems consistent with normal EOF behavior, so I think it makes the best default behavior since it would be easily predictable. Separate handshape tags for each could be achieved by either manually authoring a handshape tag or marking a chord with both "crazy" "hi dens" statuses, with the noted exception that EOF still pads handshape tags to a minimum length of 56ms. OK, perfect then. I didn't realize that handshape marking was normally an automatic for successive identical chords. Of course we should mimic normal game behaviour. When I tried 'crazy' and 'hi dens', it worked as you say, but note that just "crazy" on both A5 power chords was enough to give each A5 power chord it's own 56ms handshape. Toggling high dens only played with the <chord time> tags' high density attribute (0 or 1). I guess it depends on specifically what you're wanting. If it's just no notes in the box, EOF should export it that way unless any of the notes require sustain or if any of the notes are open? If you also want no handshape tag, that's probably not something EOF can export. OK, I suppose use of the "hi dens" status on a non-chordified chord will do the job of creating a chord box with no notes. Also a repeat regular chord as follows will do the trick as per the image below which reproduces Robustness Test 11a, as desired: http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Reproduce%20test%2011a_zpslxeyzy80.png I did find a little unexpected behaviour though. See image below. Somehow the chordify logic is not working as expected here where the EoF authoring is for chordifying sustained notes in a handshape but the XML doesn't author the superimposing single notes. So in-game the chordify logic does author the dummy chord but without sustain (superimposed single notes). Here is the notes.eof file that includes the authoring below. Here is the exported XML in question. http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/No%20superimposed%20single%20notes%20on%20sustain%20chordify%20authoring_zpshvnej8wy.png Regarding redoing Robustness Test Case 9 (dummy chords with techniqes), I ran out of time this morning. Gotta go to work now. :( I'll try my best to get those tests done Friday morning. Have a great day!

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!

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

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

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.

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?

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.

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

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... :( 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. 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 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> 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!!!

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

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

Please see this post for the follow-on to this thread.

Dummy Chords & Robustness Testing Results Hi all, To follow-up on my last post on the subject of Dummy chords, and summarized in the earlier post, after significant initial testing carried out after this post, I provide below the results of robustness testing of dummy chords, in order to allow confident implementation in EoF, if deemed worthy. USAGE OF DUMMY CHORDS Place a chord box around split chords.Place a chord box around a chord with one or some of the notes having different sustains (ex: HOPO on some strings of a chord while other strings sustain) http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Initial%20inspiration%20case_zpsuuq60x3s.png This was the initial motivation for dummy chords because the following is not currently authorable in EoF as of this writing.This Guitar World link shows some nuanced examples of this and includes Sound Cloud audio samples.Putting a box around notes that start/reside at time stamps that are nearly but not all equalNot sure but might grace notes benefit from this?Others? Please share your thoughts. PRELIMINARY COMMENTS This testing took on a life of its own in that every test I made had unexpected findings, so I knew I had to continue until there were no more surprise findings. Unfortunately the “no more surprises” point happened after a very large amount of testing. I was tempted to just give up, but I have this quirky birth defect, such that when the going gets tough, it’s like I take it personally and become aggressive and determined. Enjoy my nerdy determination below…. J One thing that kept me going is thinking, “I can’t possibly let raynebc have to figure all this out on his own.” First the Summary then the robustness testing results in the form of large PNG image files to which I'll link. Each summary conclusion points to the specific detailed robustness test where the said point was examined. This detailed PNG image file reporting of my incremental findings show the order in which I tested things and they mostly have a logical progression. However, whenever a conclusion in the PNG files was made and then later superseded by new findings, I didn’t erase the initial findings, but rather I wrote in bold blue where to find the superseding conclusions. The following is the Robustness Tests basic outline: (“Handshape ChordId=-1 dummy chords”& “Dummy ChordId Dummy Chord” are defined in the next section). Can dummy chords make use of accents and chord labels? Can a dummy chord box appear around a single note? Examination of consecutive and varying “Handshape ChordId=-1 dummy chords”. Authoring HOPO on select sustained strings of a chord. Can a “Dummy ChordId Dummy Chord” exist without a chord template or piggy-back on other chord templates? Miscellaneous “Dummy ChordId Dummy Chord” tests examining handshapes, high density, scoring, box shape. Examining behaviours of “Handshape ChordId=-1 Dummy Chords” including scoring this constructs uniqueness. Examining DDC behavior with Dummy Chords Examining various guitar techniques applied to Dummy Chords Examining whether one can have control of dummy chord box shape as well as authoring chord labels/fingering Various tests repeated based on more recent findings. All tests have been conducted with EoF Hotfix 01-27-2016 & RocksmithToolkitGUI-b942ce6e-win (09January2016 nightly build) Please do let me know if there are any holes in the logic expressed or shown. Given there are so many tests, it is certainly possible I may have overlooked something. Definitions of Dummy Chords types and their Constructs Here is a brief description of both types of dummy chords examined in the robustness tests: 1. Dummy ChordId dummy Chord: The authoring of a chord box in-game, be it shaped like a box or goal posts ( |_| ), be it with single notes superimposed upon it or not. The basic idea is to have the XML contain <chord time> tags without <chord note> tags and ensuring that the <chord time> tag points to a chord template (chordId=… ) whose fretting is aligned with the intended chord to be played at the time stamp of this said dummy chord. Basic Construct example: <chordTemplate displayName="D5" chordName="D5" fret0="-1" fret1="5" fret2="7" fret3="-1" fret4="-1" fret5="-1" finger0="-1" finger1="1" finger2="3" finger3="-1" finger4="-1" finger5="-1" /> !This being the chordId=0 referred to below ... <chord time="2.000" linkNext="0" accent="0" chordId="0" fretHandMute="0" highDensity="0" ignore="0" palmMute="0" hopo="0" strum="down" /> !No <chord notes> tag. Note: initially the construct was for the chord template to contain only -1’s but Test 6B showed why this should not be the case. The -1’s template is where the name “Dummy ChordId” came from in the term “Dummy ChordId Dummy Chord”Note: Later the basic construct will be expanded for sustained dummy chords and use of handshapes with the help of the high density attribute and superimposing of single notes.2. Handshape ChordId=-1 dummy chord: The authoring of a chord box in-game, be it shaped like a box or goal posts (|_| ), be it with single notes superimposed upon it or not. The basic idea is to have the XML contain <chord note> tags within <chord time> tags associated to a chord template that gets normally authored with chords, but to also have a <handshape chordId=”-1” …. /> tag. The handshape tag displays as an empty chord box in-game despite the authoring of the chord notes, essentially erasing them. Note: Later the basic construct will be expanded for sustained dummy chords and use of handshapes with the help of the high density attribute and superimposing of single notes.Basic Construct example: <chordTemplate displayName="G5" chordName="G5" fret0="-1" fret1="-1" fret2="5" fret3="7" fret4="-1" fret5="-1" finger0="-1" finger1="-1" finger2="1" finger3="3" finger4="-1" finger5="-1" /> ... <chord time="3" linkNext="0" accent="0" chordId="1" fretHandMute="0" highDensity="0" ignore="0" palmMute="0" hopo="0" strum="down"> <chordNote time="3" linkNext="0" accent="0" bend="0" fret="5" hammerOn="0" harmonic="0" hopo="0" ignore="0" leftHand="1" mute="0" palmMute="0" pluck="-1" pullOff="0" slap="-1" slideTo="-1" string="2" sustain="0" tremolo="0" harmonicPinch="0" pickDirection="0" rightHand="-1" slideUnpitchTo="-1" tap="0" vibrato="0" /> <chordNote time="3" linkNext="0" accent="0" bend="0" fret="7" hammerOn="0" harmonic="0" hopo="0" ignore="0" leftHand="3" mute="0" palmMute="0" pluck="-1" pullOff="0" slap="-1" slideTo="-1" string="3" sustain="0" tremolo="0" harmonicPinch="0" pickDirection="0" rightHand="-1" slideUnpitchTo="-1" tap="0" vibrato="0" /> </chord> ... <handShape chordId="-1" endTime="3.056" startTime="3" /> “Dummy ChordId Dummy Chord” –vs– “Handshape ChordId=-1 Dummy Chords” It was determined in Tests 7D Cases C to H as well as in Test 11g that, although “Handshape ChordId =-1 Dummy Chords” were shown to author various dummy chord sequences, by virtue of the handshape tag erasing authored chord notes from a chord box, it was determined that the <chord note> tags are unnecessary to achieve the same results and therefore showing that the “Handshape ChordId=-1 Dummy Chord” construct boils down to a “Dummy ChordId Dummy Chord” construct. Furthermore nested inside overall handshapes consisting of other single notes, or chords or even other dummy chords, the overall handshape tag renders the nested <handshape chordId=-1 … > tag as redundant, and again boiling down to a “Dummy ChordId Dummy Chord”. As such, for simplicity, though all “Handshape ChordId =-1 Dummy Chord” testing carried out is presented in the large test results PNG image files, the summary that follows will only focus on the “Dummy ChordId Dummy Chord” and therefore it will generically be referred to as “Dummy chord”, despite the PNG files always maintaining a distinction between both dummy chord types. In fact, test 6B determined that a chord template of all -1’s is not the best construct for a “Dummy ChordId Dummy Chord” so it is actually a misnomer and is better served just being called a “Dummy Chord” Summary of Test Results General features of dummy chords: Dummy chords essentially author a chord pane where it would be intuitive for one to exist but currently does not by virtue of conventional CDLC XML authoring. (See Tests 1-11 PNG image files for various examples) No chord name or fingering displays in-game (see Test 1) unless the dummy chord occurs inside a handshape tag and the dummy chord’s <chord time> tag is not high density, however fingering will also display when the dummy chord’s <chord time> tag is high density (see Tests 4b, 4c, 4e, 4f, 6aCase1, 6aCase2, 10, 11). Accent status (see Tests 1 and 10j), bends (See Test 7), Pitched Slides, Unpitched slides, vibrato, palm muting, fret hand muting, harmonics, linkNext, arpeggios (see Test 9 for these 8 listed items) and handshapes (see Tests 4,6,7,8,10,11) have been demonstrated to display a dummy chord box. See the section on scoring below for some caveats. Dummy chord boxes can appear as short (high density) or tall (not high density) boxes or even short or tall goal posts ( |_| ) with some possibility of control over box height (as shown in Test 10; see also Tests 4b,4c and 11 for difference in Goal-post height, see tests 4c/4e,7,10j,11m for the difference between box and goal posts). Goal posts can only be displayed around 2-stringed chords as long the <chord note> tag associated chord template is proper (i.e. defines the intended fretting for the dummy chord to be played), otherwise a <chord time> associated with a chord template of all -1’s displays a box. Authoring of various dummy chord scenarios (See “Sample” section for visuals and video footage) Not in an overall handshape With sustain Low Density chord box/goal posts(See Test #11b – screenshot 1, chord 1) Need proper chord template Need <chord time> tag with high density = “0” No <chord note> tags Need <note time> tags Optional: Handshape around duration of dummy chord to author fingering and chord label – Issue: superimposed single and chord notes (cross-shaped gems). Acceptable? High Density shorter chord box/goal posts (See Test #11b – screenshot 2, chord 1)Need proper chord template Need <chord time> tag with high density = “1” No <chord note> tags Need <note time> tags Optional: Handshape around duration of dummy chord to author fingering only– Cannot display chord label on high density (dummy) chord – Can choose to not author single notes if want appearance of repeat boxes/goal posts – Issue: chord box shortens and might shorten below some of its notes. Acceptable? (Ex: Test 1, 2Case2, 4f , 6ACase1&6&7, 6C, 7C, 7D, 8, 10) Without sustain Low Density chord box/goal posts (See Test #11b – screenshot 3, chord 1) Need proper chord template Need <chord time> tag with high density = “0” No <chord note> tags No <note time> tags Must have a 1ms Handshape around dummy chord to display unauthored chord notes and display fingering and chord label – Note: When EoF exports a regular chord it exports a 56ms handshape. Nothing wrong with dummy chords following suit. High Density shorter chord box/goal posts (See Test #11b – screenshot 3, chords 2&3)Need proper chord template Need <chord time> tag with high density = “1” No <chord note> tags Need <note time> tags Optional: 1ms Handshape around dummy chord to author fingering only– Cannot display chord label on high density (dummy) chord – Can choose to not author single notes if want appearance of repeat boxes/goal posts – Issue: chord box shortens and might shorten below some of its notes. Acceptable? (Ex: Test 1, 2Case2, 4f , 6ACase1&6&7, 6C, 7C, 7D, 8, 10) Inside an overall handshape (“overall” or “global” are words I use to signify that other single notes, chords or even dummy chords can also be in the handshape) With sustain Low Density chord box/goal posts (See Test #11C, Screenshot 1, chord 1) Need proper chord template Need <chord time> tag with high density = “0” No <chord note> tag Need <note time> tags Fingering and chord label are automatically displayed due to being inside an overall handshape. – Issue with superimposed single and chord notes (cross-shaped gems). Acceptable? – On-screen artifacts (aka visual glitches) occur when a dummy chord (i.e. no <chord notes> tags) exists in an overall handshape and has it’s <chord time> tag set to high density = “0”, manifesting the artifacts only for chords containing open strings. The artifacts appear as thick horizontal, vertical or diagonal bars of the same colours as the open strings as seen in Tests 5c; 7D Cases B,D,E; 11i. Setting high density=”1” rectifies the issue, but then requires the superimposing of <note time> tags and fails to author chord labels. As long there are no open strings in the dummy chords being authored, there are no artifacts. High Density shorter chord box/goal posts (See Test #11C, Screenshot 3, chord 1)Need proper chord template Need <chord time> tag with high density = “1” No <chord note> tag Need <note time> tags Fingering and chord label are automatically displayed due to being inside an overall handshape.– Cannot display chord label on high density (dummy) chord – Can choose to not author single notes if want appearance of repeat boxes/goal posts – Issue: chord box shortens and might shorten below some of its notes. Acceptable? (Ex: Test 1, 2Case2, 4f , 6ACase1&6&7, 6C, 7C, 7D, 8, 10) Without sustain Low Density chord box/goal posts (See Test #11C, Screenshot 4, chord 1) Need proper chord template Need <chord time> tag with high density = “0” No <chord note> tag No <note time> tags Fingering and chord label are automatically displayed due to being inside an overall handshape. – On-screen artifacts (aka visual glitches) occur when a dummy chord (i.e. no <chord notes> tags) exists in an overall handshape and has it’s <chord time> tag set to high density = “0”, manifesting the artifacts only for chords containing open strings. The artifacts appear as thick horizontal, vertical or diagonal bars of the same colours as the open strings as seen in Tests 5c; 7D Cases B,D,E; 11i. Setting high density=”1” rectifies the issue, but then requires the superimposing of <note time> tags and fails to author chord labels. As long there are no open strings in the dummy chords being authored, there are no artifacts. High Density chord box/goal posts (See Test #11C, Screenshot 4, chord 2&3)Need proper chord template Need <chord time> tag with high density = “1” No <chord note> tag Need <note time> tags Fingering and chord label are automatically displayed due to being inside an overall handshape.– Cannot display chord label on high density (dummy) chord – Can choose to not author single notes if want appearance of repeat boxes/goal posts – Issue: chord box shortens and might shorten below some of its notes. Acceptable? (Ex: Test 1, 2Case2, 4f , 6ACase1&6&7, 6C, 7C, 7D, 8, 10) Scoring A dummy chord’s Chord template must have proper intended fretting to be played in order for it to score properly (see Test 6B). A dummy chord’s associated chord template filled with -1’s will score in-game when successfully playing the intended notes, but the problem is that it will also score successfully when playing incorrect notes, hence the importance of associating the dummy chord to a proper chord template. Slides, bends, etc. techniques inside dummy chords score with simply beginning notes’ success as opposed to scoring if the technique is accomplished. (See Test 9) When authoring superimposing single notes ( <note time> tag) those <note time> tags must be authored with ignore=1 in order to avoid a 2-string power chord, say, scoring as 3 successes or misses (chord + each single note). As such with single notes set to ignore = “1”, the frets around the single notes will blink showing success even if the wrong chord is played. This is a necessary evil of dummy chords with sustains which require the use of superimposing single notes. DDC DDC is not broken by dummy chords but see Test 8, based on DDC 2.8 (I only noticed 2.9 was out later on) to examine its behavior while ramping up and down the difficulty. @@Chlipouni, some minor changes might be preferable to DDC if Dummy chords are introduced. See the DDC 2.8 Pre and Post DDC XML’s and log file. DDC 2.9 Pre and Post DDC XML’s and log file. EoF Implementation considerations:Perhaps like the authoring of any new chord in EoF which creates a new unique chord template, so will the defining of a dummy chord also need to author an XML chord template for the intended chord to be played. It is alright to piggy-back a dummy chord on an identical template than was used for a regular chord. As it is best to allow the user to author dummy chords with as few selections as possible (hi dens, split, etc) I was imagining defining in EoF, a chord, setting it to “split” status, and then applying a status or marking called, say, “chordify” or “chord box”. Since handshape tags with duration equal to the dummy chords sustain (or 1ms if no sustain) is, at worst, redundant when nested in an overall handshape, it might be a good streamlining in EoF Allegro coding/ EoF user-authoring if all dummy chords come with a handshape tag associated with the same chord template as the <chord time> tag. Then all that remains to determine by the user is whether they want a high density or low density chord box and then if they want single notes superimposed or not (to mimick a repeat line) but I’m not sure if there is any use for that in practice. If a noteless repeat dummy chord is not deemed practical, then perhaps the “hi dens” status can be used to toggle the default low density dummy chord to a high density one. Just some preliminary thoughts for consideration or for you to improve upon - you know best @@raynebc. If you do want to have a dummy chord around single notes at different but close time stamps then EoF will have to recognize the cluster of notes and create a chord template with all the intended notes in the marking. So EoF might have to be coded with a new marking, not unlike handshape marking, and then a status such as “Chordify” (hopefully all dummy chords can be authorable with 1 new marking/status) to give the appearance of a chord with all notes at the same time stamp. It’s probably best to find a way to avoid users getting confused as to the reason for visual glitches when a dummy chord with high density =”0” inside a handshape tag and consisting of open strings. The allure of low density chords, with unrotating notes, and chord labels, is such that perhaps EoF could detect chords consisting of open strings, and only then, force the authoring of a high density dummy chord. Perhaps this can be a save message warning of an “automatic conversion from low density to high density dummy chord due to…” .Other Remarks @@raynebc, please see Test 4g,conclusion 3. When authoring the HOPO on select strings of a chord, the split status and linkNext tech note sets the following <notes count="8"> but it should be <notes count="5"> after your January 2016 new clean-up of single notes logic upon Linknext Tech notes are defined on a split chord.@@raynebc, I remember you were trying to minimize repeated identical chord templates a while ago so I’ve noticed that if chords in handshapes (and maybe not in handshapes too) have split status, then multiple identical chord templates are exported. This occurred when authoring as per Tests 11a,b,c. I also noticed lots of redundant FHP’s in repeated <anchor time> tags.If one really wanted to author a box around a 2-stringed chord, it is possible. One need only create a dummy chord with a chord template of all -1’s (See Tests 4e, 4f, 5d, 6aCases 1-8). The issue with this is that anything played will register as successful.Possible to place a dummy chord box around 1 note (See Test 2 for explanations)The Tech Notes Tutorial would eventually be updated once the @@mrmaton example of HOPO on select strings becomes authorable in EoF.Note that a further refinement to the authoring of HOPO on some strings is shown in Test 11l whereby fingerings are defined at each note pair’s time stamps in EoF and each with unique back-to-back handshapes. See video below. @@raynebc stated in this post that he’ll see if he can allow for these back-to-back handshapes on a sequence of linked notes can be authorable in EoF.https://youtu.be/0eblx5LiexI If needed, once dummy chord implementation is made in EoF, I can put together a quick tutorial on dummy chords.Do any of you have any other ideas of circumstances when authoring a chord box (aka a dummy chord) would be useful? I’d like to be able to list all scenarios in such a tutorial. Sample: All Dummy Chord Authorings from Section 2 in one XML/PSARC See this video for all the following screenshots in motion. https://youtu.be/ICryo4HPKCQ Here is the modded final XML that generated the screenshots below. Here is the corresponding psarc file. Part 1: Dummy Chords --> No overall handshape - No sustained notes http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Final%20Sample%20-%20NoHS%20No%20Sust%20Lo%20and%20Hi%20Dens%20-%20RS2014%20screenshot_zpscbu1i86m.png http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Final%20Sample%20-%20NoHS%20No%20Sust%20Lo%20and%20Hi%20Dens%20-%20EoF%20screenshot_zpss5kip2wy.png Plus the following adjustments: Add proper chord templates for A5, C3 chordsChords 1 & 3 (No Overall HS; No sustain, Low Density):Remove <note time> tags @ 2s&3sAdd <chord time> tags with HD=0 @ 2s&3sAdd 1ms <handShape> tags @ 2s&3sChords 2 & 4: (No Overall HS; No sustain, High Density):Set <note time> tags to ignore=”1” @ 2.5s&3.5sAdd <chord time> tags with HD=1 @ 2.5s&3.5sAdd 1ms <handShape> tags @ 2.5s&3.5s Part 2: Dummy Chords --> No overall handshape - Sustained notes http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Final%20Sample%20-%20NoHS%20Sust%20Lo%20and%20Hi%20Dens%20-%20RS2014%20screenshot_zpsmcae7ith.png http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Final%20Sample%20-%20NoHS%20Sust%20Lo%20and%20Hi%20Dens%20-%20EoF%20screenshot_zpsiz0letjb.png Plus following adjustments: Add proper chord templates for A5, C3 chordsChords 1 & 3 (No Overall HS; Sustain, Low Density):Set <note time> tags to ignore=”1” @ 5s&7sAdd <chord time> tags with HD=0 @ 5s&7sAdd 750ms <handShape> tags @ 5s&7sChords 2 & 4: (No Overall HS; Sustain, High Density):Set <note time> tags to ignore=”1” @ 6s&8sAdd <chord time> tags with HD=1 @ 6s&8sAdd 750ms <handShape> tags @ 6s&8s*750ms being the duration of these specific sustains. Part 3 - Regular Chords (added for comparison purposes inside the XML/psarc) http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Final%20Sample%20-%20Regular%20chords%20-%20RS2014%20screenshot_zps7qghlm9e.png http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Final%20Sample%20-%20Regular%20chords%20-%20EoF%20screenshot_zpsrgoouwxb.png Plus following adjustments: None Part 4: Dummy Chords --> Overall handshape - No sustained notes http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Final%20Sample%20-%20HS%20No%20Sust%20Lo%20and%20Hi%20Dens%20-%20RS2014%20screenshot-Take2_zpsjwlwqtpr.png http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Final%20Sample%20-%20HS%20No%20Sust%20Lo%20and%20Hi%20Dens%20-%20EoF%20screenshot_zpsjwpzxi5k.png Plus following adjustments: Add proper chord templates for A5, C3 chordsChords 1 & 3 (Overall HS; No sustain, Low Density):Remove <note time> tags @ 13s&14sAdd <chord time> tags with HD=0 @ 13s&14sChords 2 & 4: (Overall HS; No sustain, High Density):Set <note time> tags to ignore=”1” @ 13.5s&14.5sAdd <chord time> tags with HD=1 @ 13.5s&14.5s Part 5: Dummy Chords --> Overall handshape - Sustained notes http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Final%20Sample%20-%20HS%20Sust%20Lo%20and%20Hi%20Dens%20-%20RS2014%20screenshot_zpsg0gejorx.png http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Dummy%20Chords%20Robustness%20Testing/Final%20Sample%20-%20HS%20Sust%20Lo%20and%20Hi%20Dens%20-%20EoF%20screenshot_zpstorsy5su.png Plus following adjustments: Add proper chord templates for A5, C3 chordsChords 1 & 3 (Overall HS; Sustain, Low Density):Set <note time> tags to ignore=”1” @ 16s&18sAdd <chord time> tags with HD=0 @ 16s&18sChords 2 & 4: (Overall HS; Sustain, High Density):Set <note time> tags to ignore=”1” @ 17s&19sAdd <chord time> tags with HD=1 @ 17s&19s …So that was the summary …. LOL Dummy Chords Robustness Testing - Detailed Results The following Google Drive link contains the 11 large images, alluded to in the Preliminary Comments and they contain screenshots, both in-game and in-EoF, XML manual tweaks and test-by-test conclusions. It would be too large to post here so when you want more details from a given summary point, simply refer to the stated corresponding test result in the link below. https://drive.google.com/folderview?id=0B63pbIBRC6HQU1NhY2ZUZU1GTTA&usp=sharing Final Comments Lots of tests carried out, the details of which I didn’t want to complicate this summary with, so please go ahead and ask away if you have questions. It’s likely that I tested your question and can point you to the exact test. Again, please let me know if I’ve forgotten or misrepresented anything. Cheers, Berneer

Yes, I made back-to-back handshapes. Yes, the minimum note distance set to 1ms helped! Is there any reason why it is better to leave it to 3ms? The remaining issue is that I guess it is the linkNext Tech Notes, but EoF won't let me select just 1 sustained note at a time and create a handshape in efforts to make 4 back-to-back handshapes. Instead the menus say "re-mark" and it erases the marking on a previous sustained note. See pic below. Setting the fingering with the Hotkey F worked fine for each sustained note and exported properly in the chord templates. Note, setting "split" status on the first e0/B12 note pair didn't help with the disappearing marking. http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Back-to-back%20Handshapes%20for%20dyn%20fingering/Attempting%20back%20to%20back%20handshape%20marking_zpsge7gsng2.png It seems @@Alex360 is making a request not unlike the one I had made here, that is asking about a handshape (I was asking for partial handshapes at the time... to which raynebc recommended back-to-back handshapes) that changes by virtue of 1 string being fixed fretting but other strings being different frettings. Though you lose me at "ghost handshape" so I am not sure if I fully understood you. If I didn't, sorry for piggy-backing my info/questions on yours.

@@Alex360, I think I was tinkering with your idea yesterday while testing dummy chords (almost done, been sick all week). I tweaked the XML to author 4 successive handshapes with 1ms between handshapes so as to show dynamic fingering since EoF automatically authored as 1 handshape with fixed fingering due to chord templates finger definitions. See video below. Is this what you mean? If so then yeah I'd love to be able to author that in EoF with 1ms separating handshapes. Doing it in EoF in my Blaze custom I can manage getting two successive handshapes as close as 30-40ms apart leaving a visible gap in the lane handshape markings.

This video series helped me set up my strat. He also sells a thin but informative e-book. Good luck.

I could only say I tried using the crowd level event in EoF and it didn't have any effect of in-game. Apart from this, I don't know the answer to your question.

Sorry double post since my PC seemed not to post my last comment.

I might have gotten a bit confused. I thought I remembered handshape markings not displaying chord labels, but I just authored a little sequence in a handshape as a test and it seems the chord label appears for a chord in a handshape, but just not at the beginning of the handshape beginning with a single note, contrary to an arpeggio marking that would author a label from the beginning. See image below: http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Handshapes%20and%20labels/Handshape%20label_zpsftwaqinw.png I therefore tried putting a 1ms handshape in the XML manually, as shown below, but it didn't succeed in putting a label at the beginning of the handshape. So though this 1ms handshape construct is helpful for dummy chords (per my upcoming Test 10, which incidentally I just updated with 2 additional tests 10h and 10i) it is apparently of no use for regular chords... <handShape chordId="0" endTime="7.25" startTime="5" /> <handShape chordId="0" endTime="5.001" startTime="5" /> Note: In case it matters, I am still on Hotfix January 27, 2016 since I had to make sure all my dummy chord testing is using the same Hotfix....

@@SmellsLikeMonkey, I've discovered that placing chords in 1ms long handshape tags which themselves can be nested in overall handshapes tags will author chord labels. I don't remember if @@Chlipouni came to the same conclusion when testing nested handshapes, but while robustness testing dummy chords I noticed this works, assuming the chord in the 1ms handshape tag has high density = "0". Both 1ms and overall handshape can be associated to the same chord template. I'll be posting all my results of testing this week. Look out for Test #10 results when I post. [actually my test reporting images are ready, so here: Folder with all PNG files. Later this week I will finish by writing a summary since the testing is quite long.] For now this requires manual XML adjustment.

Why note use the bookmark feature in EoF to store up to 10 bookmarked time stamps.

OK. It seems that both types of dummy chords, really can do the trick. Let me run a few more tests on both types of dummy chords to see if one should be the dominant choice to implement. I think to avoid potential confusion in the community it is probably important to perform the following robustness tests. I could then list the pros/cons of each and then we could decide on one. The things I'd like to test to ensure robustness: 1. Can "dummy chordTemplate dummy chord" author with a chord name and/or accent? If so then it might be a choice to have EoF author a new dummy chordTemplate for each different chord. Perhaps the chord name is to much trouble for EoF code change but if accent works, then maybe it might become a combinable status with a "dummy chordTemplate dummy chord" 2. Can both types of dummy chords appear with only 1 note inside? (Related to Test 7 at the end of this post) 3. Test whether the last image of Post 1488 can be authored with the "handshape chordid=-1 dummy chord" since that was the main purpose of introducing dummy chords. 4. Since the "handshape chordid=-1 dummy chord" is after all handshape based on a range of time as opposed the the "dummy chordTemplate dummy chord" which is applicable for only a point in time, I'd like to test if in a long handshape with a myriad of various events, if anything unsavory happens. 5. In case one wants to author a "handshape chordid=-1 dummy chord" with a duration of 1ms, in order to avoid a range in time, I might as well check if that works. 6. Sometimes the "dummy chordTemplate dummy chord" is shown in game as a shorter box that is shorter than the tallest single note in the chord, which is maybe intuitive enough but inelegant. I wouldn't find seeing if there is something I could manually tweak in the XML that could avoid that and keep the box high, or ensure the box is low. High Density status was one thing that shortened the box. Any thing else you want me to test/verify? @@Chlipouni I think I failed to express myself properly in my first question to you earlier today. Your statement that "handShape appears at a level of difficulty if at least one of its notes is selected for this level." sounds like the "handshape with chordId=-1 dummy chord" would author a box around 1 note single at lower DD levels. I don't think I've ever seen DD do this. Am I misunderstanding you? Test 7: Might as well therefore test this last sentence above on whether the "handshape with chordid=-1 dummy chord" will create a chord box |_| around 1 note. Gimme a few days. I just noticed below my avatar that I have 0 warning points. I am expecting a brevity warning any time now... LOL

Haha not the place of a Padawan to test a Jedi's work unless delegated ... :)