Chlipouni

@@mbanks850,

  I have fixed this issue. 

  I am looking for other similar issues before to release the new DDC ...

Thank you

@@Berneer, @@raynebc,

  DDC v2.9 allows the use of handShapes with "chordId=-1".

  In this case, the handShape appears at a level of difficulty if at least one of its notes is selected for this level.

  If two single notes in this handShape share the same time position (something like a chord) they will be considered as standalone notes.

@@Chlipouni, hope this tested with @@Berneer :lol: if so I'll do my job then

Hi Alex360,

  I have found a few issues with the DDC tab of the RSToolkit when I generate DD on a set of psarc files :

  - If an error occurs, the DDC tab is blocked and I need to restart the RST

  - Sometimes I have an error like : "File already exists" (you can try with the CDLC : "Faith No More - A Small Victory")

  - When DDC is launched the shell window is displayed

Thank you

  Update v2.9 (23/01/2016)

   - New logic to avoid the split of existing handShapes when the new phrases are generated

   - New process to allow excotic handShape phrases

@@Berneer, @@raynebc,

 The DDC limit is only about the generation process of chordTemplates for lower levels of difficulty.

  For specific usages in which there are no chord and only one note at the same time position, I can add this easily in DDC.

  Both existing examples we are studying for now (Faith No More CDLC, and Berneer test case) are in this case.

  So in DDC, I am going to implement the following rules :

  - "chordId=-1" only for handShapes to avoid the usage of a dummy chordTemplate (no finger hand position and no fret position)

  - these handShapes will appear in the game when the associated note is selected for a level of difficulty

  - if a chord or several single notes are included in this handShape, a warning will be generated in the log file and these events will be fully displayed when they will appear in a level of difficulty

Maybe @@Chlipouni could reveal which official DLC uses this mechanism?

 Yes, I can, but it is not an official DLC : Faith No More - A Small Victory (the Bass arrangement)

 I detected it because DDC is not able to manage this case and generates an error.

 For now, DDC needs the chordTemplate to generate the lower levels of difficulty. If this feature is added in EOF, it will be hard for me to manage it in DDC...

 As the dummy chord must be played in RS2014, is there any advantage to manage it like this ?

EOF doesn't have a way to write an XML using handshapes that way. My best guess is that it's just to display a handshape tag that would not show any fingering at the bottom of the screen or something. Even if the game supports that, it would take a fair number of changes for EOF to allow a handshape phrase to exist without a base chord and I don't immediately know if it would be worthwhile.

I am not asking about adding this feature, I am looking for the reason of this specific usage ...

 

Hi @@Gnobiwan,

 

  I have found a bug.

  When some chords are removed for the lower levels of difficulty, the "highDensity" status is not computed again for the chords which are kept.

 

  I will try to solve this problem for the next release ...

 

Thank you

 

Just wanted to post that I think I am seeing this bug on my CDLC as well.

I am seeing it on this one specifically

http://customsforge.com/page/customsforge_rs_2014_cdlc.html/_/pc-enabled-rs-2014-cdlc/feint-r19519

 

If you want the pre-DDC version to compare it too let me know.

 

When a phrase is fully mastered, the high density tag is not set to 1 on repetitive chords ...  I think this is what you are referring too.

 

Thank you for your feedback,

  I am working on DDC v2.9 and I would like to be sure that there is not another problem.

  Can you share the pre-DDC version of this file ?

Thanks

Hi Berneer,

  FYI, I already had this issue with one of my EOF test file which contains only a few notes (or chords).

  To correct it I had to add more notes in the track ...

  Maybe there is a minimum length requirement in RS2014 but I did not identify the exact reason.

DDC doesn't create the sections automatically (only the phrases). So if the CDLC has no section, only the whole song could be selected in the Riff Repeater.

If the CDLC is yours, you have to create the sections in EOF, save and generate DD again.

If the CDLC is not yours, you can quickly add the sections with the BPR tool (BPR topic).

I am try to help some one and they would like to be able to play one section in the middle of song

just the part not whole song

so I try to use DDC to do that and song is always locked to all the section can not get it to make

section so you can play only that part am I doing something wrong is it the way it is

it has levels but it is for whole song not just one part can this be done?

  DDC is always applied on all sections in a song.

  It is not possible to apply it only for one section.

  With RS2014 and its Riff Repeater, the player can select only one part of the song to practice.

  But maybe I have not understood what is your problem ...

@@Berneer,

  The CDLC is now available : Therapy? - Die Laughing

But then it will display in-game with the chord name defined for the previous chord instance's template, instead of displaying with no name. It seems to be an either-or scenario, and I'm not sure if it's worth keeping the logic to try to substitute nameless chord template instances because it adds complexity as well as this problem.

  When a chord is displayed as a repeat line (high density), its name is never displayed in the game.

  In my opinion, the highDensity status is not a property that users should be able to modify.

  It will only help us to simplify the management of handshapes in our tools.

  Nervertheless, the 3D rendering of this status stays useful.

  EDIT :

  About the 3D rendering in the last hotfix, it is not in consistency with the highDensity status. Some chords of low density have the [/] marker.

  About a specific usage of the "split" property, look at the following example :

  This example works fine except :

  - the slides of single notes are visually crossing in the game (the same sequence works well if I remove the "split" status on chords)

  - the single notes which are following the notes with the "linknext" status are still duplicated in RS2 export file

  The tools offer now great new functionalities.

  I am near to relase my new CDLC which contains these new features ...

Thank you

Yes, but in this case, if the second chord has to be displayed with a repeat line, it should have the same chordId than the previous one.

I think one of the issues I'd run into was with repeated chords in a handshape. EOF was using an alternate chord template that was the same except that the chord name was made to be blank. This was to prevent the chord name from showing up every time the chord occurs in the handshape. Unfortunately this causes a template ID change and EOF would mark this change by triggering a low density chord in what would otherwise be perceived as the player as a chord repeat. I only see two options for me to pursue on this problem:

1. Do away with that blank named chord logic. Chord name will be displayed for each repeated chord?

2. Use the blank name chord template and explicitly mark the chord as high density even though a change in chord IDs takes place. This goes against the logic DDC wants.

In my opinion, this should not be a problem.

If you create a new template for a similar chord but without name, it's because you want to display it in the sequence, so if its "chordId" is not the same as the previous one, it will have a low density status. 

@@raynebc,

  Sorry for the "split" status, it works as expected (I were looking in the wrong file  :huh:)

  About the highDensity status, DDC has to correct it automatically when the lower levels are generated.

  So, it would be better that EOF uses the same logic (as described in my previous post).

Thanks

@@raynebc,

  I tried the last hotfix and I have a few problems with it :

  - the "split" status on a chord generates a chord and not the associated single notes.

  - the default "highDensity" logic, should consider only the "chordId" of chords and not the position of chords inside their handShape.

  - If a handShape phrase contains only single notes, the first one is duplicated in the RS2 export file (same time position and same fret and string).

  - Too many chordTemplates are exaclty the same and that can break the "highDensity" logic.

  About the second issue, look at the following example :

     <------------------ handShape chordId="0" -------------------->

     <-chordId="0"-> <-chordId="1"-> <-chordId="1"-> <-chordId="0"->

          hd="0"          hd="1"          hd="1"          hd="1"      default highDensity generated by EOF

          hd="0"          hd="0"          hd="1"          hd="0"      expected behaviour to display only the first occurrence of each variation of a chord

  The first chord of a handShape should always have a low density status.

Thank you

Hey @@Chlipouni,

 

That's awesome to hear! Is there anything I can do in the XML in the meantime to fix it?

You can set the "highDensity" value to 0 for the first occurrence of a chord and to 1 for the following ones.

But that will be fastidious because you have to do this on each level of difficulty ...

Let me know if EOF needs to do something like warn the author if a handshape phrase crosses from one phrase into another or anything like that.

This could be useful if EOF does not split the handShape itself.

Another specific case is when a handShape contains no note or chord inside (only ghost notes). I don't know what to do for these handShapes on low levels of difficulty.

For now, DDC removes them ...

Hi @@Gnobiwan,

  I have found a bug.

  When some chords are removed for the lower levels of difficulty, the "highDensity" status is not computed again for the chords which are kept.

  I will try to solve this problem for the next release ...

Thank you

Hi @@Berneer,

  In the internal coding structures used by RS2014, each event (single note or chord) can be associated with two distinct handShapes.

  For now, the RSToolkit uses the first level handShape for chords and the second level handShape for arpeggios.

  I successfully tried to update the RSToolkit code in order to use these two levels for a same chord.

  The first level is used to define the current notes of the chord (embedded handShape) and the second level is used to define the global finger positions (which may have more notes).

  To differentiate the two handShape levels, I had to use different time positions :

   - if the HS time is lower than the first event -> it is treated like a main HS

   - if the HS time is equal than the first event -> it is treated like a embedded HS

  After a discussion with @@raynebc, we have found that embedded handShapes are not mandatory because :

  - we can now display a chord with the "high density" status even if the chord is not the first one of its handShape.

  - the chordTemplate used by a handShape can be different from the one used by a chord

  So, for my first video example which shows variations of chords in the same handShape, we can simply make it with :

  - only one handShape (with the full finger positions)

  - one or several chords which can use all notes or a subset of notes of the full chord

  - the "high density" status to control which occurrence to display as a full chord box or as a repeated box

  As the simplicity is better than complexity, for now, we are not going to implement embedded handShapes ...

  PS : about the "-nop" tag, I don't know exactly its real meaning.

          It is used in official DLCs in case of embedded handShapes.

          I tried to use or remove it but with no visible change, maybe another limitation of the RSToolkit.

I have an xml that seems to be having an issue when run through DDC with chord protector.

 

When run through DDC it displays all the hand shapes rather then repeats even if the chord doesn't change. Non-DDC it doesn't have this effect. Any reason why DDC would remove all the repeat chord bars?

 

I don't know what files any experts would need to diagnose it, but here are the XML's before and after DDC. https://www.dropbox.com/sh/g7y8cg8yx0ysp4f/AAB_7hIHQbaXPDMdsXuTCAjWa?dl=0

Hi @@Gnobiwan,

  This case can occur when a new phrase is generated and breaks the current handShape (this handShape is splitted to allow two different levels of difficulty between the two adjacent phrases). So for the new phrase, the first chord is displayed with all notes inside even if the previous chord is the same.

  I will analyze your files tomorrow to be sure that there is nothing else that can cause an issue.

  I am working on DDC v2.9 to change the behaviour of handShapes, because new features are now available in EOF about them ...

Thank you for reporting this problem

@@Berneer,

  In your last example, you should remove the crazy status on chords inside the handShape phrase.

  This will avoid the single notes generation in addition to the existing chord notes (now correctly displayed thanks to the new high density feature).

I can see that the ability to still split up chords into single notes this way without having to specifically alter their start times could be useful for some authors, but I'd probably have to create a new status to apply to chords for this. Let me know what you guys think.

+1 for this new status :

 - easier to do in EOF

 - mandatory for DDC logic (single notes must have the same time position to consider them like a chord)

About the new FHP process : Ok for me, but I need to update DDC