Berneer

So using your DDC 3.2 psarc you linked above for my Blaze custom, I wanted to show you the following. 1. I did notice DDC 3.2 seems to fix the "Handshape starting later than in a higher difficulty" problem I reported in the chordify testing thread and which I thought I noticed in my DDC 3.1 packaging of the custom linked in Post 340 but can't seem to find anymore. I guess I'll confirm it when I resume chordify testing. 2. In the intro of my custom I noticed when leveling down 1 step the disappearing of every 1st of 2 concatenated handshapes (by concatenated I mean separated by 2ms, to give semblance of a partial handshape spanning the multiple concatenated handshapes). See below: Here it is in EoF: Can you please refresh my memory by confirming the following: DDC intends to keep handshape marking (lane highlights and all fingerprints, even those of notes not appearing in lower levels) all the way down to the bottom level? If yes are there circumstances when it is expected that DDC will not do this. I have found some instances in my custom at lower levels where some or all handshape markings are dropped. Just curious the criteria to know if the behaviour I see in-game is expected. Thanks!

Great stuff and fast work @@Chlipouni. Your fix resolved the issue completely and I am thrilled! Here is the 3rd occurence of my original issue: New animated gif http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Temporary%20half%20beat%20%20floor%20FHP5%20when%20should%20be%204/DDC%203.2%20fixes%20my%20issue%20-%20thankyou_zpscy342cwt.gif (trying posting image from Google drive, doesn't work, any special procedure to post an image from Google Drive? ) I also prefer how the yellow number FHP below the strings behave. So it seems you have somehow improved that too. When I come back in town I'll have to ask you some questions about handshapes working differently from top level to lower level, such as starting later a lower level than a higher level or even splitting up and making a handshape hole in the middle of an intended handshape. I was just going to accept it and post my custom, but I thought maybe this was an issue you'd like to know about and why not make it perfect? :) I'll post more details later, but they are the same details as I had noticed while testing chordify in my latest long chordify post I made a month ago. In fact if you check my custom I posted a few posts above in that Google Drive it's already present in that custom in the intro when you level down 1 or 2 levels. But I'll show specifics ASAP. Hmm, 4:13am. Supposed to be waking up in 47 minutes.... screw it, staying awake and will watch newest MacGyver episode! At 41 years old, it should take me 12 days to recover from this.... :) It's ok, we are the soccer champions and it feels great!

Thanks for looking into this @@Chlipouni!! I will try to check out your new psarc tonight but it's tight for me this weekend and I might only be able to check Sunday evening. I did not invert the animated gifs in my earlier post. Top animated gif --> After DDC Bottom animated gif --> Before DDC When I say "floor FHP" that was in contrast to yellow highlighted fret numbers below the strings which are goverrned by the anchor XML code. Well both should be governed by the anchor XML code. The 'floor' refers to the actual note highway that changes from black to dark blue in the fret lanes with upcoming notes. It is the "floor FHP" and not the yellow numbers that are momentarily wrong in the space with no notes between section start and first single note in the section (B5). When you click the link to the 3 screenshots from post 338 where I did as per Rockfirstlast's suggestions of moving the FHP=4 to the beginning of the section instead of being at the first single note, B5, after section start, each screenshot behaves a bit differently. The 1st link (3rd occurence in the song) shows a momentary floor FHP=5, width 4, the animated gifs and EoF screenshot are based on this occurence. The 2nd link shows the 1st occurence of this same phenomena in the song, in this case with a "floor FHP = 3,width 4". The 3rd link shows the 2nd occurence in the song and it also has a "floor FHP = 3, width 4. Sorry if I wasn't clear on that earlier. In each occurence, the preceding event is the same power chord with same FHP. But really we only look at the 3rd occurence screenshot for which I provided animated gifs and EoF screenshot and solving that will solve the issue. Perhaps you've already solved it. :) Regarding: " but between the start of the section and the first note, there is no anchor and RS2014 uses the previous one of the previous section." There is an FHP definition, and by extension an XML anchor initially at the B5 note,but now at section start since Rockfirstlast's suggestion and shown with in-game footage in post 338. Regarding: "I will try to force the time position of this new anchor to the start time position of the phrase if the note is the first one in the current phrase." That is what I did in EoF upon Rockfirstlast's suggestion and the problem persists. So I'm unsure this will solve the issue. I will try my best to confirm late tonight. Soccer party till 3am & waking up at 5am to drive out of town 3 hours away..... but I am burning to solve this so sleep be damned. :) Bon weekend!!

Yes, exactly as Firekorn wrote. I did set FHP of 4, for the single notes. I tried shifting it a bit to the left and to the right but the same problem occurred with DDC and did not occur without DDC. Thanks a lot for your attention. I really appreciate it!

Thanks rockfirstlast. Just tried it. It doesn't fix the issue unfortunately. It looks like this instead. Early in the song, in the first of 3 iterations of this same phrase, it looks slightly different but still with the issue. Again slightly different but still with issue in 2nd iteration of this phrase. Interesting the first two iterations highlight the floor as if FHP was 2. THe 2nd iteration shows a floor FHP of 2 but with width 5? The inconsistent look suggests it is a game glitch? Aside: Is anyone else having the same issue of not being able to post images on Customsforge for at least a week now?

Thanks firekorn. I didn't think any ODLC that use concatenated handshapes like I did. I have merely used an idea in my custom that raynebc gave me about a year ago and I've called it here "concatenated partial handshapes" for the lack of a better term. I wasn't writing this last post as a problem issue and this is not an EoF issue, but I wrote my last post more as an addendum to the "Overall Conclusions" in the earlier post, to inform anyone who wants to know, more about how the handshape fingering behaves but this time in a marked handshape, since a marked handshape can be a bit more elaborate than an automatic handshape defined for all chords. You mention overlapping. I'm only concatenating, not overlapping though. But interesting that you found ODLC with an overlapping handshape. Chlipouni was looking for an example of this over a year ago but then raynebc and chlipouni decided to dismiss that construct. Thanks for the YouTube tip.

Bonjour @@Chlipouni, I am trying to weed out my final imperfection in final testing of my latest custom, Blaze Bayley - Stare at the Sun. It's not a big deal, but since I've spent so much time on it I'd like to try to remove this blemish. See this passage where an 1/8 of a measure with no notes shows a floor-FHP of 5. I pause it in the animated gif. http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Temporary%20half%20beat%20%20floor%20FHP5%20when%20should%20be%204/Temporary%20half%20beat%20wrong%20floor%20FHP5_zpsfceodniu.gif In EoF, it is authored like this. Sorry Customsforge is bugging and won't allow me to post an image other than via a URL. You could see I force the FHP to 4 a quarter beat before the b5 note, and FYI I place a new section and phrase at the beginning of measure 247, which contains no note until a quarter beat later. I am suspecting DDC doesn't is not comfortable with this but I don't see any indication in the DDC log. All I could find in line 10960 and 10961 in one of the difficulties, a peculiar absence of anchors between the B5 note and the previous anchor being a huge 15 seconds earlier with an FHP of 5.... Here are the lines of code in question: <anchor time="398.692" fret="5" width="4" /> <anchor time="413.475" fret="4" width="4" /> But as you could see when I pack the CDLC without DDC, it works fine as shown below: http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Temporary%20half%20beat%20%20floor%20FHP5%20when%20should%20be%204/PreDDC%20works%20as%20desired_zpsuars7sft.gif I am using DDC 3.1 from RSToolkit 2933f3b1 (dated 24Oct2016). Would you know how I can avoid this issue? I have made a Google Drive folder with all pertinent files, in case you needed to inspect more closely. Thanks.

I have noticed another little handshape fingerprint behaviour with marked handshapes whereby the fingerprint outline blinks. In my latest custom (Blaze - Stare at the Sun) I have decided to take a seemingly complicated almost arpeggio passage and use concatenated handshape markings in EoF to simulate a partial handshape whereby fingers that stay fixed throughout all the handshapes have fingerprints that stay put and then those that change usher in a new handshape marking in EoF which suddenly displays which finger to use to play the varying added note. Each handshape is painstakingly placed 2ms apart, though EoF seems to prefer to output them as being 1ms apart, but I digress. This construct is quite effective in my opinion apart from this very insignificant but irritating blinking problem. See the pre-verse section which has a two different sets of 24 so-called "concatenated partial handshapes". https://youtu.be/RPmWYdYTRtI (btw, How do we post a YouTube window in the pst rather than a link?) You could see the reason for the blinking in the annotated EoF screenshot below. EoF screenshot (sorry issues with Customsforge with posting images in the last week(s)) Thought I'd share this as an addendum to the Overall Conclusions in the above post, since it does add fingerprint behaviour information for the case of a "EoF manually marked handshape" using (CTRL+SHIFT+H). Interestingly it also seems to show that a double outline can disappear based on small time away from the end of a handshape which the above Overall conclusions post was inconclusive whether a double outline could be governed also by a time based logic. Oh well, I guess I have to live with it in my custom. If the price of 'concatendated partial handshaping' is tiny fingerprint blinks, then so be it.

Oh boy, I am so sorry @@raynebc and anybody who read this. I figured out the problem. It is not a Toolkit problem and it is not an EoF problem it is a Berneer problem... After re-looking at the above GIF, I noticed a peculiar thing, "Why is there a 5 fret width on the first 3 notes?" Looking via EoF I noticed that the FHP was 1ms too late, and Rocksmith didn't know what to make a of handshape beginning one instant and FHP changing 1ms later. On Oct 8, I was making tiny resync tweaks in the intro and despite anchors in place, EoF export recalculations must have shifted something by 1ms due to round off or something, without me noticing, and screwed up the FHP, which interestingly, only removed the lane highlights.... Man, testing and re-testing and re-re-testing a custom before release is so important. raynebc, I simply made a handshape marking for both series of 3 notes to show that each set of 3 notes could be nicely played with one handshape, which by defintion should highlight the left and right lane with blue highlights. Am I misunderstanding your question?

Hi guys, I've been following your work from the last month or so, BTW, and you guys have done incredible work!!!! Thank-you!! I have an issue, that may or may not be Remastered related. While final testing my imminent CDLC, Blaze Bayley - Stare at the Sun, I encountered a strange issue. See animated GIF below from my custom's outro with 2 similar successive handshapes, where the first works perfectly in-game but the 2nd neglects to highlight the lanes in blue on each side. http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Non-appearing%20handshape%20lane%20highlights/Blaze_SatS_NonAppearingHSlanehighlights_zpszk0maktj.gif It doesn't seem to be an EoF issue since the XML looks as it should. http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Non-appearing%20handshape%20lane%20highlights/EoF%20screenshot%20and%20pertinent%20code_zpsfc6qawc4.png I am using latest toolkit 2.7.1.0-2933f3b1 from October 24. First noticed issue: October 8 packing with CST v2.7.1.0-53552b41 (I retouched the synch in this version, rel to Sep22) Last functionning packing: September 22 pcking with CST v2.7.1.0-7b9489e5 I happen to have handy a video playthrough from September 22 packing from before the Remastered Rocksmith 2014 release on Oct 4 in which you could see from 7:10 to 7:16 in the following link, that it worked fine in the past. (Top left quadrant which is the lead PART Real_Guitar arrangement in which the issue exists) https://www.youtube.com/watch?v=u3dkcbUdF7k This makes me wonder if something in the toolkit has inadvertently changed due to "Remastered". I just can't tell if it is a toolkit issue or not or just the game glitching and beyond repair. Here is a link to all my files of any interest including psarc from Sept 22, Oct 8, and latest from Oct25. Anyone know why this is happening and, more importantly, how to fix it? Remarking the handshape in EoF didn't solve my problem. My PC: OS: Windows 10 Home Version 1511, OS build 10586.633 - 64 bit, RAM 32GB CPU: Intel® CORE i7-6700K CPU @ 4.00Ghz AV: Haven't installed any - useless. Even with them I have to re-install Windows every 6 months .NET Framework 4.6.1

I found two very good videos on putting modes into practice and which correspond perfectly with my crib sheet on modes in the OP. These are from the guitarist of Blue Oyster Cult, Richard Castellano, who has a major YouTube presence and is very good at explaining things. This video below explains diatonic chords without ever using the word diatonic :) This video below runs through the modes and shows examples of which scales to play on which chords in all the modes. To use the crib sheet terminology, it basically demonstrates how the 'tonal centre' tells you the (diatonic) chords to play while soloing over that using the "parent major scale" Ex: C Dorian, you play diatonic chords (Maj-min-min-Maj-Maj-min-dim) of the CMaj scale and then solo over it with the Bb Parent Major Scale since Dorian always has it's PMS down a Major 2nd from the tonal centre (C tonal centre--> Bb PMS) Another very good music theory instructor on YouTube is Michael New. His tutorials on modes are visual and attack modes from a different angle but it is nonetheless instructive. Watch his three brilliant videos on demystifying time signatures.

Yes, I agree that is a great 1 sentence conclusion! Since you wrote this post prior to me writing (completing) the above post, I figured your use of the word "simplify" meant I had to write a long detail overall conclusion... ;) This is probable. I'm too anxious to finish my custom to do any more testing to confirm this... :P I agree. I am still not decided which of the two options I will choose. I was even thinking of a 3rd option of only applying fingerings to a each different chord once where it is not too messy. Thank-you @@firekorn, it is very motivating to be bouncing off ideas off one another. Makes the extensive testing feel more worth it.

OK, so I could have made this a rigourous analysis but I think I will content myself with the conclusions from the tests below to at least get a good approximate understanding of the RS fingerprint logic. Still a deep enough look to be typical of Berneer... :) If you want to skip each test (observations and conclusions) you can skip all that and look that the Overall Conclusions section at the end of this post. For the masochist. Click here to see all tests, obsersations and test conclusions in a Word document. The document above is complete. OVERALL CONCLUSIONS 1. Handshape fingerprints begin aligning with a subsequent chord/handshape 0.5sec prior to it, taking 0.4 sec to transition and being fully transitioned 0.1sec before the subsequent handshape. This transition will always begin even if within a preceding handshape! All transitions, be they appearing, disappearing or transitioning fingerprints take 0.4sec to complete. Visual Substantiation: https://youtu.be/dAQM2XM_zy4 (All links: Timer bottom left, 30fps, 3 frames = 0.1 sec) Chord 1/2/3 --> 0.8sec/0.9sec/1.0sec sustain --> No/Single/Single outline 2. Different notes and, by extension, fingerprints of a handshape behave independently from one another based their individual circumstances if the different strings are played on different frets. If the different strings are played on the same fret, see Conclusion 6. Visual Substantiation: https://youtu.be/YIGQlWVBFwI (Blaze Bayley - Stare at the Sun, measure 128) Different outlines on different notes of a chord. 3. Single outlines around fingerprints occur if two criteria are satisfied: i) Another chord exists after the current one. (even if 5 secs after, perhaps even all the way to the end of the chart, but more than 5 sec was not verified) AND ii) The handshape lasts 0.9s or more without changing, even if it spans multiple chords. Visual Substantiation: i) https://youtu.be/fvLwazOnCEQ --> No chord exists after the last chord 5sec after the previous chord Chord 1/2/3 --> 1.0sec/1.0sec/1.0sec sustain --> Single/Single/No outline ii) See visual from Conclusion 1 and see following for example spanning multiple chords: https://youtu.be/OC-_OZGtMIE (Blaze Bayley - Stare at the Sun, measure 132) Single outlines remain on multiple chords more starting at least 0.9s prior to next different chord - first two A7/D6 chords are start > 0.9 sec from later chord A4/D4 hence single outlines, however the last A7/D6 chord starts 0.4s before the A4/D4 chord hence no more outline. 4. Double outlines around fingerprints occur on notes of a chord that are common to the next different chord (as noticed by @@iminashi ). Visual Substantiation: https://youtu.be/sv8gBs4IAWs (Blaze Bayley - Stare at the Sun, measure 128, chord 4 to measure 130, chord 1) - A4/D6 x 3, A4/D4 x 1, A4/D6 x1, A7/D7 x 1 Double outline remains on the A4 for 4 chords, but not 5th (last A4/D6) since the next different chord has no common notes with it. ***VERY INTERESTINGLY, note that A4/D4 chord has the double outline on A4 despite starting only 0.8sec before the A7/D7 which seems to suggest that unlike the single outlines requiring at least 0.9sec between different chords, the double outline either is not time dependant or is time dependant with a smaller time requirement than 0.9sec. My tests performed so for do not allow to confirm which is the case. 5. No outlines around fingerprints occur on notes of chord: if the current handshape is not at least 0.9sec long OR no follow-up chords exist after (5 sec or maybe even in the rest of the section or even chart - need more testing) Visual Substantiation: See visual from Conclusions 1 and 3 6. If adjacent strings are barred for a given chord and each note, with the above logic would each possibly have a different number of outlines, the barre will be applied with both (I assume 'all' if >2 string barre) notes in the barre surrounded but the number of outlines of the note that has the most outlines. Caveat 1: I have only verified the above conclusion with a case of a barre chord with one note satisfying the criteria of double outline and the other note in the barre satisfying the criteria of no outlines with the result being both barred fingerprints being surrounded by one larger double outline. Caveat 2: I have not verified what happens on same fret notes on non-adjacent strings. Visual Substantiation: See visual from Conclusion 4 A4/D4 chord have one double outline surrounding both fingerprints, even if D4 on the next different chord is not in common with it since the next chord is A4/D6. 7. Single outlines around fingerprints remain until there is 0.5sec till the end of a handshape, though the fingerprints (and numbers in fingerprints) remain in position until the end of the handshape unless a subsequent chord is within 0.5sec. Visual Substantiation: See visual from Conclusion 3i at 25% speed in YouTube. 8. Single notes that are between two handshapes will interrupt (make disappear) outlines until, at the very latest, 0.1sec before the said subsequent handshape, however fingerprints and their number remain despite the single notes Caveat: I assume if the time interval between the last single note and the chord is greater than 0.5s, no interruption will occur since the outline will not have appeared before the single note(s) in the first place. Visual Substantiation: See visual from Conclusion 4 The palm muted A4 single notes preceding the A4/D4 chord interrupt the barre double outline leading up to the chord by quickly disappearing suddenly 0.16sec before the first palm-muted single note and reappearing suddenly instantly after the 2nd palm muted single note, doing so 0.1sec ahead of the A4/D4 chord. Overall Caveats: 1. I have not run exhaustive tests to make 100% sure that the above statements are correct without exception. It is possible that some of my conclusions may be premature. 2. I sorta use the words 'chord' and 'handshape' interchangeably throughout this post even though I only authored chords and imposed no handshape markings in EoF. I'm assuming the behaviour for both manually and automatically created handshapes to behave the same. I still have to figure out how to make my custom look cleaner in the verse section. I am even considering removing the handshape definitions since they are somewhat obvious. Thanks for your help @@firekorn and @@iminashi ! You are very kind and helpful.

I think both firekorn (proximity dependency)and iminashi (double outlines for different chords with same fingering) are onto something. I am thinking is that the finger outline is based on how much time until the next change in position. I am thinking that magic number is between 0.5sec and 0.75 sec but using Bandicam and frame by frame verification of multiple examples in EoF I can probably zero in to the exact number. Using this and your conclusions above I think I am close to finding 5 or 6 rules that dictate the behaviour. I will report my conclusions later.

Thanks @@firekorn and @@iminashi. Yours are the best explanations so far, but if you look at the linked image in the original post, a static annotated EoF view, you'll see that there are exceptions to even both your explanations... seems like the correct answer is still a bit of a mystery. I suppose for now I've got to live with it though I wish I could control it since I find that passage not aestheticlly pleasing in my new custom which I am making every effort to make pristine. I'm being a even more perfectionist than usual since I will be sending my custom and video playthrough to the artist (Blaze Bayley, former Iron Maiden singer) since he was nice enough to personally send me tabs for his song. If I understood the logic better then I would be happy to so some heavy-handed finger editing. Thanks for you help guys!!! I really appreciate it.

Hi guys, I am not thinking the following is an EoF issue so I figured I would post here. During final testing of my newest CDLC (Blaze Bayley - Stare at the Sun) I am noticing something I haven't noticed before. Those finger prints in the game that show what handshape is needed to play a chord behave a bit differently based on a logic I don't yet understand. If you look at the GIF snippet below of my custom you'll notice a series of chords intermitted with palm mutes. Notice how the finger prints tend to either show up in game in 1 of 3 ways. 1. Number with a double outline around it. 2. Number with a single outline around it. 3. Number with no outline around it. Does anyone know why the game does this and upon which logic or criteria it decides how many outlines a fingerprint must have? http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Handshape%20varying%20outline/Handshape%20fingerprint%20outlines%20vary_zpso9hakqzl.gif Here is what it looks like in EoF with representation below that shows what happens in game to better allow recognition of a pattern, which I don't see yet. http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Handshape%20varying%20outline/Stare%20at%20the%20Sun%20verse%20hanshape%20outline%20variance%20questionJPG_zpsel9nc4cm.jpg~original And at the end of this post is the pertinent XML code which doesn't seem to dictate number of fingerprint outlines since regardless number of outlines, the code seems to have the same nomenclature for each chord. Anyone see a pattern? Or can anyone provide an explanation? I just checked an official song, REM - Losing My Religion, and within the first 30 seconds of that song I see all three types of outlines discussed above. It must mean something. Can any tell me what each outline type signifies..... looks like it is more a game rendering phenomena than and XML related one. Link to pertinent XML

This is a very good tutorial. Thanks Pyrobillie! I understand modes (though always need to refresh my understanding) and understand that modes help explain which solo or lead notes (scales) fit well with which chords in rhythm arrangements. I will study your spreadsheet, but must admit I am not understanding it just yet and will "refresh my understanding". I understand you are putting x's below notes that fit the mode but I am not yet understanding exactly how you are using the spreadsheet to help you and how the labels (Ionian, Dorian, Phrygian, Lydian, Mixolydian, Aeolean, Locrian) belong where they are shown. I will try to figure it out by watching your video in 25% speed, but perhaps it'll help viewers of your video better understand that aspect to maximize the appeal of your tutorials. Perhaps a link to your spreadsheet could also be helpful (found the link, thanks), assuming it is generalized and not just for your custom. I assume the x's are the part that is song-specific. Brilliant work. I never really imagined a CDLC could be created from rhythm. I love how art like music, is quite methodical and mathematical and therefore allows songs to be reverse engineered into a chart! Incidently I am working on a tutorial for a new EoF feature called Chordify which is not related to chordify.net so I will mention in my tutorial that these two uses of the word chordify refer to different things. Edit: Okay I think I understand better how this spreadsheet is organized and what you are doing. 1) Your spreadsheet simply shoes the fret board based on your Green Day song's non-standard tuning (Dstd drop C). Your linked spreadsheet however shows Estd tuning as can be seen by the notes in the 0th fret column. 2) the x's you placed in your video simply show notes you've seen used in your video for the two lowest pitched strings (red and yellow) and you select only from among those notes in lead arrangement with the presumption that the lead parts of the songs follow a pattern, typically following a mode. 3) The labels, Ionian, Dorian, Phrygian, etc. shown in your spreadsheet are simply an example of which modes come from the Cmaj scale and define which chords (roots of diatonic chords) sound good when notes from the C Maj scale are solo'd over them. Ex from theory: C Ionian, D Dorian, E Phrygian, F Lydian, G Mixolydian, A Aeolian, B Locrian each have a C parent major scale that can solo pleasingly over those modes' diatonic chords (Dmin, Emin, Fmaj, Gmaj,Amin,Bdim) 4) Harmonic Minor (1 2 ♭3 4 5 ♭6 7 8 rel to Major scale) shows in colour in your spreadsheet, notes in the A harmonic scale (which incudes G# which could also be represtented by A♭ which you show in colour) 5) Pentatonic Minor label shows in colour in your spreadsheet notes in the A Pentatonic Minor scale 6) Pentaonic Major label shows in colour in your spreadsheet notes in the C Pentatonic Major scale I guess next step, for me at least, is to rewatch your video in slow motion to see how this spreadsheet guides you to determine which notes to place on the lead chart. Boy, I can be a nerd....

Hi guys, Not that chordify is at the forefront of current issues, but just letting you know that I won't be able to do any testing for hopefully only a little while since I have a herniated disk now pinching my siatic nerve and making it excruciating to get out of bed. I made some diving soccer saves and won the playoffs, but I am no goalkeeper, however I improvised since winning is something I deeply desired against sworn enemy. I never thought being off work could be so boring. I always imagined playing RS all day but ixnay on that for now. I'll get to finishing my custom and testing /tutorializing chordify as soon as I am better. Cheers all!

Been so busy with my latest custom that I sorta forget some fine details of chordify at the moment and whether it is better to not put fretted notes chordnote tags to avoid cross-shaped gems. Will have to Review past posts/tests. Didn't even realize there was a rule forcing open string chord notes at the beginning of a section (now phrase) and unsure right now if that even affects chordify. I don't believe it affected me in the past. Priority is obviously to get the game working normally again and me checking soon if everything we've tested still stands and if not, finding a workaround. Tomorrow or Tuesday morning, I can pause my work on my imminent custom and run a few tests to test the following: 1) fretted note chord note tags 2) chordify on chords at beginning of phrase 3) if density is still user-selectable when using chordify Thanks chlipouni and everyone for digging deep on the RS Remastered issues. I was surprised during testing that I scored 100% on my Blaze - Stare at the Sun custom, which is a challenging song... LOL

If you refer to EoF post 1574 (Robustness TEsting of Dummy chords, March 9) where I tested two types of dummy chords in parallel: "dummy chordId dummy chords" and "Handshape chordid-1 dummy chords", I realized, in Robustness Test 7 (if memory serves), that the former should not use -1's in the chord template, and that the latter didn't need the Handshape chordid set to -1 since it was redundant. This led me to conclude that both dummy chord types were one and the same and then chordify was born. Test results showed that this "Handshape chordid-1 dummy chords" method is no longer needed for chordify implementation and was dropped and never programmed into EoF so you cannot use EoF to create such handshapes. If ever for another purpose we felt the need to revive Handshape chordid-1 at least thereis significant testing of this in the dummy chord robustness testing of EoF post1574. So apart from being a possible way of creating a chord box, there seems to be no compelling purpose to proceed with that construct. I do remember using "Handshape chordid-1 dummy chords" in Robustness Test 2 (I think, sorry at work I don't have access) to place a box around a single note, which might or might not be of any interest in ramping up a chord in DDC whereby the MAXCHORDSTR=1 levels might show a box, and then when MAXCHORDSTR>1, then more note heads appear in the box, in order toalert the user early that he will soon be playing a chord when leveling up.

Warning: Not as daunting a read as it appears. You'll see when you read. I notice @@Chlipouni you are currently making revisions to DDC, so I figured that even though I only have some preliminary notes, I might as well summarize things I have already noted in case it helps since all our communications is a bit much to re-read so I thought I'd do that for you. Summary of Robustness Testing DDC and Chordify (EoF Post 1574, March 9): Link to Robustness test 8 Conclusion 1: Transcription track rightfully maintains high density = "1" but DDC adds new lower level chords with high-density = 0 which introduces in lower levels the open-string visual glitch --> I'm now thinking the new chlipouni-inspired construct of chordify might do away with this issue by virtue of open string chord-notes being added in chordify construct.Conclusion 2 & 10: Non elimination of superimposing single notes giving appearance of of chords not levelling down though they do. --> chlipouni says he can modify these by deducting chordid from the chord tag at the same position.Conclusion 4: Redundant single notes when chord becomes note in MaxChrdStr = 1 level --> No big dealConclusions 5 & 6: Obsolete conclusions due to "handshape -1 dummy chords" no longer being considered but ensure chosen chordify construct behaves appropriately in a handshape as well as not in a handshape. --> I can keep an eye out.Ex: Handshape beginning timestamp shifting, or just 1st chord in handshape levelling differently than other chords in the handshape.Conclusion 7: Lowest pitch string of chord is always the one maintained last in lower difficulties --> chlipouni says he keeps the chord's base note in the lowest difficulties.Conclusion 8.2: DDC seems to split the handshape in higher difficulties, cutting them 4ms short. --> OKConclusion 9: Is standard ramp-up model ideal for chordify? Maybe multiple lines with only MAX CHORD STR increasing by 1 while category and sub-category remain unchanged? --> I can examine later.Conclusion 11: Is scoring ok with newer DDC and chordify? --> I can test later. This test showed behaviour is in-line with normal DD behaviour.Note to self: superimposing single notes are needed for high density chords or chord with sustained notes.Note to self: redo Robustness Test 8 with a follow-up version of DDC since initial test only contained 3 (or more) string chords, and really I should also test 2-stringed chords.Summary of Follow-up Discussions between Berneer and Chlipouni: June 12 e-mail exchange with chlipouni:see Image DDC3.0 behaviour_take2.pngHOPO chordify example: e10 note tail only extends till HO even though transcription track maintains full sustain duration --> chlipouni says he can make DC avoid shortening e10 sustainWould it be more natural if longer sustaining e10 were maintained at lower levels --> chlipouni says DDC keeps the fundamental note, but then my question is how does DDC know which chord is being played? For example an e10 note and B12 note, which are D and B respectively, can form a D6 or Bminor chord. So D is fundamental if observing the D6 chord and B is fundamental in a Bminor chord.Handshape marking and fingering starts later when ramping down --> Strange behaviourHandshape and No Handshape ramp down difference: No handshape maintains B-string notes, despite being in MaxChordStr=1 AND why are there HO & PO on 2 strings though no double stop on initial chord. --> I believe this is due to non-elimination of superimposing single notes which you said in response to Conclusion 2 of Robustness testing.see image: "Show error message to chlipouni"error message with Palm Mute --> Strange behaviourJune 15 chlipouni wrote:DDC knows to remove notes of a chord uniquely via "chord Notes"DDC accepts redundant single notes and notes of a chordDDC always bases itself on the same logic to remove notes of a chord: fundamental note of a chord disappears lastchlipouni says he can evolve DDC to correct the first point . however the 3rd point is harder to changeBerneer asked: How does DDC decide which is the sequence of note removal for non-Fundamental notes? Highest pitch to lowest pitch? Note in the official song, REM - Losing My Religion, interesting an Emin ramped down straight to an E5 after 2 reductions in difficulty. Probably the result of manual DD during chart creation...Berneer wondered: When DDC notices a chordified sequence (chord time .....with chord notes not equal to chord template should DDC either:consider chordified chord as 1 rigid item to be removed in its entirety when ramping down (ex: e10 + (B12, B13, B12, B10) might be better served remaing as one item to to be down-rampedkeep note with longest sustain in the lowest difficulty.June 16 chlipouni wrote in this thread, Post 6:chlipouni-proposed chordify construct: Shifted single notes using chord tag linkNext and open notes of chord defined by chord Notes should be applied to all chords (with or without open notes) and all densities, since DDC logic which already manages these cases of a chord with linked single notes. --> Done EoF-side, though no chordNotes if no open notes.June 22Berneer wondered, if trouble accepting chordify construct in DDC, then should we simply just show regular notes in lower levels then for top level, add techniques, imported from the Transcription track?For chlipouni's question from posts 26-28, Case 3, is out of scope because I'm only looking for cases where LinkNext =1, whatever its position (chord note or chord tags) --> Not sure if there was any issue there but you seemed not bothered by this. Post #58 shows the latest IF statement.June 23 Berneer question to chlipouniCan/will DDC handle pre-bend? --> question for chlipouni?See Post 60 latest IF statement about pre-bends, first concluded circa Post 37. ELSEIF (Chordify AND (pre-bends)THEN pre-Hotfix 06-19-2016 logic (no single note offsets) with chordtime LinkNext = 0 chordNote LinkNext = 1 (can't bend an open note so moot) ENDIF Comments about chlipouni's July 28 (Post 59) interim DDC version output of my July 19 (Post 58) sample XML containing myriad Chordify examples: Berneer uploaded in-game footage of chlipouni's XML passed through an updated version of DDC. See Post 60.Not had time for detailed comments, sorry. All I did confirm to myself so far is as follows:: Pre-DDC XML and DDC transcription track verified to be identical. Good.9 new chord templates were created by DDC --> I don't remember if this is good or bad. Will confirm later. I didn't seem to think it was bad back in July...G#aug --> fret 5: 0 becomes -1FMaj7 --> fret 5: 0 becomes -1G#aug --> fret 5: 0 becomes -1FMaj7 --> fret 5: 0 becomes -1skipped C3FMaj7 --> fret 5: 0 becomes -1C#dim --> fret 5: 0 becomes -1 --> finger5: 1 becomes -1A --> fret 5: 0 becomes -1G6 --> fret 5: 0 becomes -1--> finger5: 2 becomes -1G6 --> fret 5: 0 becomes -1D5,E5,E5,A5 not repeated and dumbed-down --> I don't remember if this is good or bad. Will confirm later. I didn't seem to think it was bad back in July...If memory serves, and quickly looking at the YouTube links posted in Post 60 from July 29, I see the following issues in-game similar to the March Robustness Test 8 and the June 12 "DDC3.0 behaviour_take2.png" results, but have not had time to look more closely at the post-DDC XML yet:HOPO Video Hi Density & Handshape: Fundamental note is G in G6 chord, sustaining note is open e --> Should logic change. Not a must.As seen in earlier tests the handshape starts later in lower dfifficulties --> I don't understand why it does this.But at least now the same number of notes in a chord are constant for the entire sequence, for a given difficulty. --> goodHmm, the box is not high density.... despite the "hi-dens" ... and the XML below is as expected.... --> I expected high density to work. More a check I'll have to do with raynebc. <chord time="2.000" linkNext="1" accent="0" chordId="9" fretHandMute="0" highDensity="1" ignore="0" palmMute="0" hopo="0" strum="down"> <chordNote time="2.000" linkNext="1" accent="0" bend="0" fret="0" hammerOn="0" harmonic="0" hopo="0" ignore="0" leftHand="-1" mute="0" palmMute="0" pluck="-1" pullOff="0" slap="-1" slideTo="-1" string="5" sustain="0.001" tremolo="0" harmonicPinch="0" pickDirection="0" rightHand="-1" slideUnpitchTo="-1" tap="0" vibrato="0"/> </chord> <chord time="6.000" linkNext="1" accent="0" chordId="9" fretHandMute="0" highDensity="0" ignore="0" palmMute="0" hopo="0" strum="down"> <chordNote time="6.000" linkNext="1" accent="0" bend="0" fret="0" hammerOn="0" harmonic="0" hopo="0" ignore="0" leftHand="-1" mute="0" palmMute="0" pluck="-1" pullOff="0" slap="-1" slideTo="-1" string="5" sustain="0.001" tremolo="0" harmonicPinch="0" pickDirection="0" rightHand="-1" slideUnpitchTo="-1" tap="0" vibrato="0"/> </chord> <chord time="10.000" linkNext="1" accent="0" chordId="9" fretHandMute="0" highDensity="1" ignore="0" palmMute="0" hopo="0" strum="down"> <chordNote time="10.000" linkNext="1" accent="0" bend="0" fret="0" hammerOn="0" harmonic="0" hopo="0" ignore="0" leftHand="-1" mute="0" palmMute="0" pluck="-1" pullOff="0" slap="-1" slideTo="-1" string="5" sustain="0.001" tremolo="0" harmonicPinch="0" pickDirection="0" rightHand="-1" slideUnpitchTo="-1" tap="0" vibrato="0"/> </chord> <chord time="14.000" linkNext="1" accent="0" chordId="9" fretHandMute="0" highDensity="0" ignore="0" palmMute="0" hopo="0" strum="down"> <chordNote time="14.000" linkNext="1" accent="0" bend="0" fret="0" hammerOn="0" harmonic="0" hopo="0" ignore="0" leftHand="-1" mute="0" palmMute="0" pluck="-1" pullOff="0" slap="-1" slideTo="-1" string="5" sustain="0.001" tremolo="0" harmonicPinch="0" pickDirection="0" rightHand="-1" slideUnpitchTo="-1" tap="0" vibrato="0"/> </chord> Low Density & Handshape:Same first 3 comments as above applyHi Density & No Handshape:Again not high density --> ??Without handshape, the first chord ramps down differently than the other chords in that when the 1st chord ramps down to one note the other chords remain with two notes even in MaxChordStr=1 level as shown with the bottom right level where it is even leveling down the category while maintaining two-note chords. --> Seen in earlier testing too. Can we fix that? Likely non-elimination of single notes issue, but maybe more since behaviour is different with 1st chord relative to others.Low Density & No Handshape:Same comments as immediately aboveAccent/Harm/PHarm/PM/FHM/tapping/slapping/plucking videoAccent, open strings --> Funda is note not sust note & first chord ramps diff.Accent, fretted notes --> ditto (ditto is English word for French word 'idem')Harmonic, open strings --> ditto Harmonic, fretted notes --> ditto Pinch Harmonic, open strings --> ditto Pinch Harmonic, fretted notes --> ditto Palm Mute, open strings --> ditto Palm Mute, fretted strings --> ditto FHM, open strings --> ditto FHM, fretted notes --> ditto Tapping, open strings --> ditto Tapping, fretted notes --> ditto Slapping, open strings --> ditto Slapping, fretted notes --> ditto Plucking, open strings --> ditto Plucking, fretted notes --> ditto Vibrato /bends / unpitched slides / pitched slides video (being two-stringed chords, the 1st chord ramping differently issue is not visible here but likely still prevalent) Vibrato, all strings --> Even if E5 chord, E funda note disappears firstVibrato, 1 string --> dittoBend, all strings --> dittoBend, 1 string --> dittoPre-bend, 1 string --> ditto + pre-bend note doubling issue for me to resolve with raynebc, surprised because @@raynebc and I tackled this earlier on... by bringing back the pre-bent note with no 1ms offset and setting high density =1. The XML has high density=1 which should erase the unauthored chordnotes but isn't here... <chordTemplate chordName="D5" displayName="D5" finger0="-1" finger1="-1" finger2="-1" finger3="-1" finger4="2" finger5="3" fret0="-1" fret1="-1" fret2="-1" fret3="-1" fret4="10" fret5="10"/> ... <note time="68.125" linkNext="0" accent="0" bend="2" fret="10" hammerOn="0" harmonic="0" hopo="0" ignore="1" leftHand="-1" mute="0" palmMute="0" pluck="-1" pullOff="0" slap="-1" slideTo="-1" string="4" sustain="0.375" tremolo="0" harmonicPinch="0" pickDirection="0" rightHand="-1" slideUnpitchTo="-1" tap="0" vibrato="0"> <bendValues count="1"> <bendValue time="68.125" step="2.000"/> </bendValues> </note> <note time="68.126" linkNext="0" accent="0" bend="0" fret="10" hammerOn="0" harmonic="0" hopo="0" ignore="1" leftHand="-1" mute="0" palmMute="0" pluck="-1" pullOff="0" slap="-1" slideTo="-1" string="5" sustain="0.749" tremolo="0" harmonicPinch="0" pickDirection="0" rightHand="-1" slideUnpitchTo="-1" tap="0" vibrato="0"/> ... <chord time="68.125" linkNext="0" accent="0" chordId="10" fretHandMute="0" highDensity="1" ignore="0" palmMute="0" hopo="0" strum="down"/> Unpitched slide up, all strings --> Even if D5 chord, D funda note disappears 1st ; Non-DDC-issue: hmm despite linkNext on e string, still two noteheads.... perhaps cannot link unpitched slide?Unpitched slide up, all strings, diff slide speeds --> Even if D5 chord, D funda note disappears 1stUnpitched slide down, all strings --> Even if E5 chord, E funda note disappears 1st ; Non-DDC-issue: hmm despite linkNext on e string, still two noteheads....perhaps cannot link unpitched slide?Unpitched slide down, 1 string --> Even if E5 chord, E funda note disappears 1st Unpitched slide up, 1 string --> Even if E5 chord, E funda note disappears 1st Pitched slide up, all strings --> --> Even if D5 chord, D funda note disappears 1st; Interesting that when the B-string stops the e string sequence dones't disappear there. I'm not sure whether it is good or difficult for a ramped-down difficulty, and also if the linkNext on the e-string were to work then this would mean that the the undisappeared e-string bit would start without a note-head?; Non-DDC-issue: hmm despite linkNext on e string, still subsequent noteheads....pitched slide not linking properly? I'll need to examine this with raynebc in the coming weeks...Pitched slide down, all strings --> Even if E5 chord, E funda note disappears 1st; bottom left difficulty again has undisappeared e string which is fine if I wanted an e10 notehead, but I didn't. Wonder if DDC should just refrain from undisappearing e-string in bottom left difficulty for eventuality that linkNext will work as intended. What do you think? I guess I'll run a series of tests on why LinkNext is not working.Pitched slide up, 1 string stop --> Now with A5 chord, fundamental note remains. Seems like the DDC logic makes a decision between keeping the fundamental note when reducing the difficulty unless it is on the higher pitched strings. --> EoF/RS consideration: Note how contrary to all strings being pitched, now the open e-string note head rightfully doesn't keep appearing down the sequence, unlike the fretted note slide down to e10, which shows that LinkNext is working for the case of and unpitched string.Pitched slide down, 1 string --> Even if E5 chord, E funda note disappears 1st;Pitched slide up, 1 string --> Now with A5 chord, fundamental note remains.I can exmaine the post-DDC-XML in more detail when I resume work on chordify DDC testing and tutorializing in the coming weeks.There is a french word we use in Quebec when seeing such a long post: "colisse!" :) And this was the summary.... :) My goal was to have all we've discussed (or need to discuss) all in one place. :)

As far as I know, ignore status will make a note or chord appearing in-game register as success (blink, and not count as a miss in RR or Score Attack) regardless of note/chord played or even not played. But I am note sure if that is what you are asking.

@@Chlipouni, if you need my latest comments now for chordify vis-a-vis DDC which we discussed in early August in the dedicated thread before I resume chordify testing/tutorial I can give you my preliminary comments(my observations) which I admittedly haven't yet had time to fully flesh out with details and robust well-though-out responses to your sample DDC version of my chordify sample XML I provided you. For now you have the You Tube footage of that DDC-ified XML file. Thank-you again for your effort!!

Since you know chordify well and since chordify used to go by the name "dummy chords" and specifically originally split into "dummy chordid dummy chords" and "handshape minus one dummy chords" back in March, I am wondering if this is a question I should help raynebc by answering myself. in light of the above, can you specify exactly what you need to know? Dummy chord Id dummy chords whereby -1 appeared throughout a chord template to create a chord box. The reason this doesn't exist per se any more and evolved into the "chordify" construct is because, though it worked in creating a chord box, it scored achievement in-game no matter what was played, which is against the point of the game. If you wanted a box instead of goal posts for two note-chords, manually tweaking an XML chord template with all minus ones would work visually but again scoring successfully would be forced regardless of notes played. If memory serves, a chord template of all minus ones can be manually placed in an XML to place a box around one single note as shown in March's robustness test 2, again with the scoring issue. Let me know if I have not answered your question. I apologize the Chordify tutorial is not ready yet. I will resume in a few weeks.

I think we can agree that I like to be an agreeable person. But now I am upset. Last week @@Unleashed2k you closed a topic and deleted posts in the following thread. http://customsforge.com/topic/32465-customsforge-merch-shop-is-open-for-business/ I understand the need for any self-respecting forum to be governed by a set of principles and that unconstructive criticism or being a jackass can warrant a user's posts being deleted for the greater good and a thread closed. Being off-topic is, at worst, a reason to migrate posts to a new thread, but it is quite a matter of opinion that the posts were off-topic. Additionally I believe commenters were respectful. Let me be clear, as a proud and constructive member of CustomsForge I can say the following without impaired judgement, that if I see any more non-malicious and well-intentioned posts deleted by you or your board of directors, I will refrain from donating to this site in perpetuity. People give this site the most precious thing that they've got: their limited free time and thoughtfulness. These things need to be respected. Didn't this site begin on the principle of non-deletion? If I were GTLO especially I would be quite upset that his eloquent, diplomatic and thoughtful post was deleted. Rant over. Please close this thread at your earliest convenience, seriously, as I am not one to want to start trouble of a spate of dissent. If 7 days later I am still angry, I realize I had to say something. Even if someone agrees with me don't hit the Like button please, since I'd prefer not to stir things up and solicit any us versus them sentiment. You guys still rock in my book! All this doesn't change that I like this site and it's members and that I have tremendous respect for you Unleashed. Sincerely, Berneer