Jump to content

Latest EOF releases (9-26-2020)


Recommended Posts

Hi, folks. The latest hotfix (1-16-2016) is in the first post. Changes are as follows:

*Changed Feedback import so that notes that aren't forced to be HOPOs are forced to be strummed, resulting in a more accurate chart.

*Fixed an RS2 export bug where a handshape that had only one non ghosted gem in the base chord would export that first single note twice.

*Fixed RS2 export bugs that could cause duplicate chord template tags to be written.

*Restored RS2 export logic that would cause a chord change inside a handshape phrase to be written as low density.

 

I fixed 3 different scenarios where duplicate chord templates could be created, and couldn't come up with any other ways to cause them. Please try it out and let me know if you end up finding a way to do so.

Link to post
Share on other sites

  • Replies 2.7k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Hi, folks. I'll be using this thread to maintain the latest versions of EOF in one place. To start, download and extract EOF 1.8RC12: http://www.mediafire.com/file/ih70h6p67iy77ka/eof1.8RC12.zip You

Hi, folks. The latest hotfix (r1378) is in the first post. Changes are as follows: *Improved GP import to process bend status for grace notes, it will apply a bend strength to the grace note correspo

Hi, folks. The latest hotfix (r1363) is in the first post. Changes are as follows: *Added a warning during save if any lyrics have extended ASCII or Unicode characters, as these aren't compatible wit

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 :

  handshape_without_chord.png

 

  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

Link to post
Share on other sites

Hi @@Chlipouni

 

I tried authoring your sequence above out of curiosity and it looks like this in-game:

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/High%20density/Chlipouni%20Example%20of%20Crrossing%20Slides_zpslyayhd4i.png

 

When I authored it, it forced me to specify the end fret of the pitched slide to the lower fretted string of the two simultaneous notes, so as you did, I set it to 2 based on the D-String end fret of 2, so EoF authored it in the XML such that both notes slide to fret 2 as can be seen in the XML, hence the crossing of the note tails in the game. It works fine without the split status, because EoF recognizes that the slide of the lowest fret by 1 fret is to be applied in relative terms for the higher fretted string chordnote as well, but that logic is either not yet available for EoF or maybe impossible, which i guess raynebc will confirm.

 

If there is no easy fix in EoF, I got your desired look to work with a tech note on the A-string note tail as shown below. Admittedly I didn't get the handshape lane highlights to follow with the FHP to transition nicely. I look forward to seeing how you manage the FHP in your custom. What is the name of your custom so I can inspect when it comes out.

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/High%20density/Chlipouni%20Example%20of%20Crrossing%20Slides%20fixed%20with%20Tech%20Note_zps0puephl5.png

 

Quick question:

 

I noticed two different red piano roll symbols for Palm Mutes, as authored in your example in the above post chlipouni,

 

"-" resulting from Edit Pro Guitar Note > Muting > Palm selected

"PM" resulting from CTL+M

 

Is there any difference making you select one over the other...

  • Like 1

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

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

Check out the Tech Notes Tutorial Version 1.1 // Chordify Tutorial release TBD.

Link to post
Share on other sites

I'm working on a really big project right now and the file I'm working with in EoF (22.11.2015 Mac version) is about 2 hours 50 min long. When I try to generate a waveform or spectrogram I'm getting an error message. In case of the waveform it's non descriptive but in the case of the spectrogram it tells me "ALOGG failed to decode audio input". I'm guessing Allegro can't handle the sheer length of the file but is there any way I could still get a waveform? Working without it makes everything a bit more annoying.

I'll try it on Windows tomorrow with the latest version but I guess that won't change anything, will it?

Link to post
Share on other sites

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

Looking back, that logic was intended for low density chords inside of a handshape:

http://customsforge.com/topic/22596-handshapearpeggio-for-multiple-notes-at-a-time/?do=findComment&comment=175512

https://github.com/raynebc/editor-on-fire/issues/292

 

@@th1rtyf0ur, Given the recent major changes in the ability to author different chords inside of a handshape phrase, do you think it's still worthwhile to have EOF try to substitute chord templates with blank names as a default behavior? I would think EOF would allow the author to manually name chords inside the handshape to have an empty name (one space character) and it would export that way if desired.

 

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

I don't think most users will bother with it, but one never knows when this type of hack will open up new possibilities.

 

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.

The only instance I'm aware of this currently happening is due to the logic mentioned above that replaces chords inside a handshape to use a blank named chord template. If it's deemed that logic should be kept, I could probably limit it to only affecting low density (marked as crazy) chords inside of handshapes and then it wouldn't mislead the 3D preview of the chord's density because all crazy chords will always be low density.

 

Can you provide a simplified example screenshot or project file where another scenario causes the 3D rendering to show the wrong density status for a chord?

 

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

handshape_without_chord.png

 

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

Sliding chords that have split status is a special case I hadn't considered yet. When the chord is split up into single notes, I will most likely have to add logic to determine each of the new single notes' end of slide positions.

 

If there is no easy fix in EoF, I got your desired look to work with a tech note on the A-string note tail as shown below.

While I was reading Chlipouni's post, I wondered if tech notes would be a usable bandaid for this problem, so it's good to know it can be done. I'm going to be fixing it when I can though.

 

I noticed two different red piano roll symbols for Palm Mutes, as authored in your example in the above post chlipouni,

 

"-" resulting from Edit Pro Guitar Note > Muting > Palm selected

"PM" resulting from CTL+M

The tab notation will substitute "-" for "PM" when consecutive notes use that technique, similar to how printed guitar tablature would. This reduces screen clutter, otherwise there's be a bunch of "PMPMPMPMPMPMPMPM" ugliness when a run of close notes were all palm muted.

 

I'm working on a really big project right now and the file I'm working with in EoF (22.11.2015 Mac version) is about 2 hours 50 min long. When I try to generate a waveform or spectrogram I'm getting an error message. In case of the waveform it's non descriptive but in the case of the spectrogram it tells me "ALOGG failed to decode audio input". I'm guessing Allegro can't handle the sheer length of the file but is there any way I could still get a waveform? Working without it makes everything a bit more annoying.

I'll try it on Windows tomorrow with the latest version but I guess that won't change anything, will it?

Both the waveform and spectrogram features depend on the same ALOGG function that decodes the OGG into a PCM style format in memory, at which point it's easy for EOF to use. I'm pretty sure the problem you're running into could be not having enough memory, otherwise it would probably have to be a limitation of Allegro or something. If my math is correct, decoding that much audio into PCM into RAM would take just over 850MB of memory. As a workaround, you could try using an OGG of a lower sample rate (ie. 22.1KHz or even lower if necessary) while authoring, and substitute the full quality audio when you're done authoring. You could also try just using the low quality audio while beat syncing, then lock the tempo map and switch back to the full quality audio. If all else fails, trying it on a Windows machine couldn't hurt. I'd imagine more Allegro developers used the Windows platform than did Mac.
  • Like 1
Link to post
Share on other sites

Sorry, took a while to comment, but here goes,

 


: chlipouni

- the default "highDensity" logic, should consider only the "chordId" of chords and not the position of chords inside their handShape.
...
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

I don't mind changing this back, but in the interest of not overlooking anything, does anybody have any arguments against this?
 

As long as the author has the feedback in the 3D pane to be alerted that he should set the chord to "hi-dens" when it is identical but different chordid, chlipouni's logic sounds fine.

 

 

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

 

This is the current logic, unless the author explicitly marked the first chord as high density. Should this be disallowed?

 

Like chlipouni, I initially didn't like the idea of a handshape's base chord showing up as a repeat line (high density) but then I remembered an instance where it would actually be warranted. In my custom, No More Lies, by Iron Maiden, the chorus portion shown below used crazy status on the 6th of 10 chord boxes to simulate a silence between the first 5 A5's and then next 5 A5 power chords. Now, with handshapes, I'd create a handshape for the first 5 and another for the last 5 and I would put a "high dens"  status on the 6th chord to remove the gems inside it, which I couldn't remove below at the time. This would give the player that cue for a silence (in the case of this custom, a dramatic one) after the 5th chord instead of a "let ring" cue if it were one long handshape. And then the player quite obviously would resume the same chord for the next 5 chords all showing, nice and cleanly as repeat lines.

 

However, apart from using the "high dens" for the purposes of authoring a silence between two handshapes, I see no other reason why an author should start a handshape with a repeat line. Perhaps firekorn is right that it's a concern only for people "nose-deep into EoF" and we likely won't see a bunch of new authors rendering their charts indecipherable with over-liberal use of high-dens...

 

Either way is fine. ... I could live with my chorus 6th chords being a full chord box... LOL

 

Unless we can avoid handshapes altogether and auhor as I did in the past with Crazy status on the 6th chord but then overrule that 6th chord with high dens status to eliminate the gems inside the 6th chordbox. Then I think handshapes could forcibly always start with a full chord box.

 

(You can ignore the red text in the image below since the image was from Post #1382 when PC Plum wanted to see examples of High Density.)

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/High%20density/Highdensity%20insight%202_zpsk59knezy.png

 

 

Edit:  FYI, I tried testing some of these ideas but both currently crash the game.... despite the XML seeming logical enough....even when I author each deqeunce of 10 chords individually..... go figure...

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/High%20density/Testing%20No%20More%20Lies%20chorus%20with%20Hi%20Dens_zpsgrovxgb2.png

 

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.

 

Hmm, I wish we could avoid repeating chord names to keep charts elegant since this makes it harder to detect and time the strumming for changes in quick chord sequences on a busy screen.

 

Ex: GGGGAGGGG ---> G---AG--- is cleaner

 

But I see the importance of harmonizing our tools and it does seem to be "either/or" as raynebc said.

 

Maybe it is a silly idea but maybe we could have our cake and eat it too by putting a "split" status on all chords in the handshape for whom we don't want to see repeat chord labels, and then add a "dummy chord box" around those notes per the discussion in this thread. However the dummy chord boxes I've been able to create are big square ones instead of the more elegant half boxes that seem more common as shown in Post 1450. Would love to know how to create dummies of those half chord boxes. So if this silly idea were to be used, the whole high density issue would be gone and the DDC issue would disappear, presumably.

 

I understand this is laying it on a bit thick and should probably be dismissed as an idea but I wanted to offer food for thought.

 

 

 

 

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

 

@@th1rtyf0ur, Given the recent major changes in the ability to author different chords inside of a handshape phrase, do you think it's still worthwhile to have EOF try to substitute chord templates with blank names as a default behavior? I would think EOF would allow the author to manually name chords inside the handshape to have an empty name (one space character) and it would export that way if desired.

So, if for purposes of harmonization with DDC, the chord labels repeat on the side of the highway due to having only one instead of multiple chord templates in the handshape, one would still be able to remove all those repeat chord labels by selecting all but the first (base) chord and doing Note > Edit Name  and setting it blank (1 space character)? I thought that very action in EoF would author a whole new chord-id?

 

 

Thanks for all the hard work chlipouni and raynebc!!

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

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

Check out the Tech Notes Tutorial Version 1.1 // Chordify Tutorial release TBD.

Link to post
Share on other sites

FYI, I tried testing some of these ideas but both currently crash the game.... despite the XML seeming logical enough....even when I author each deqeunce of 10 chords individually.....

It's possible that in some circumstances the game or the toolkit doesn't like high density chords? If you make those two high density chords normal, does it stop crashing?

 

Hmm, I wish we could avoid repeating chord names to keep charts elegant since this makes it harder to detect and time the strumming for changes in quick chord sequences on a busy screen.

 

Ex: GGGGAGGGG ---> G---AG--- is cleaner

That's supposed to be the case as long as the chords are high density. If the author defined repeat chords in a way where they would display as low density, he/she could now just mark them as high density to override. I don't think there's a significant purpose for that old logic anymore.

 

But I see the importance of harmonizing our tools and it does seem to be "either/or" as raynebc said.

 

However the dummy chord boxes I've been able to create are big square ones instead of the more elegant half boxes

Maybe a high density dummy chord box would do what you want?

 

So, if for purposes of harmonization with DDC, the chord labels repeat on the side of the highway due to having only one instead of multiple chord templates in the handshape, one would still be able to remove all those repeat chord labels by selecting all but the first (base) chord and doing Note > Edit Name and setting it blank (1 space character)? I thought that very action in EoF would author a whole new chord-id?

A chord name change would certainly cause a change in chord ID and make the offending chord a low density one by default. This could be a useful scenario for the high density status to come into play.
Link to post
Share on other sites

I did have a quick read and seen nothing of this.

 

1-16-2016, hammer ons now say "hS" instead of just "h"?

 

 

- Create a note

 

- Hit h to turn it into a hammer on

 

- Red letter now says "hS"

 

- When turning it on/off with h, the S sticks with the h i.e. comes and goes with the h

 

- Pull offs only have a "p" still

 

 

 

DId I miss something?

 

 

 

Cheers :D

Link to post
Share on other sites


 

FYI, I tried testing some of these ideas but both currently crash the game.... despite the XML seeming logical enough....even when I author each deqeunce of 10 chords individually.....

It's possible that in some circumstances the game or the toolkit doesn't like high density chords? If you make those two high density chords normal, does it stop crashing?

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/High%20density/Testing%20No%20More%20Lies%20chorus%20with%20Hi%20Dens_zpsgrovxgb2.png

 

Hmm you seemed to have predicted that, raynebc. :)  I wonder what is going on. Have I corrupted something by authoring the above yesterday... take a look below for my follow-up tests as you suggested:

 

  • I ran sequence 1 alone without any "high dens" on the 6th A5 power chord -->  CRASH
  • I ran sequence 2 alone without any "high dens" on the 6th A5 power chord -->  CRASH
  • I ran sequence 2 alone without any "high dens" on the 6th A5 power chord & just authored 1 G0 note randomly (thinking I had deleted all notes except the G0 note but having accidentally maintained the sequence 2, albeit sequence 2 authored at the 4s time stamp instead of 2 sec like in the picture above) -->  NO CRASH! --> Perhaps crazy status + "Hi dens" status is a bad mix ...
  • I ambitiously therefore retried running sequences 1 and 2,  without any "high dens" on the 6th A5 power chord, with sequence 2 occurring at 4 sec and sequence 2 occurring, now at 6 sec --> CRASH
  • I kept the two sequences without any "high dens" as in the previous bullet but removed the Crazy status from the 6th power chord --> CRASH ---> WTF
  • I tried starting a new project in a new directory, and building up to the error by simply authoring 2 sequences of 5+5 A5 power chords, so essentially what you see in the image above but without any "hi-dens status or Crazy status or Handshape marking --> CRASH ---> WTF^2
  • Erased all notes and authored a simple G0 sustained notes at 2sec mark lasting 2 second --> CRASH --> Worrisome
  • OK .... let's see if I can play my long ago authored CDLC No More Lies which basically contains Sequence 1 above but without the "HI Dens" status --> NO Crash --> Thank goodness!! (It was authored with a very old Hotfix)
  • Tried running the latest Beta version of my Blaze custom authored with Hotfix 01-12-2016 -->  --> NO Crash

 

By CRASH, I mean Message that program stopped working and back to Desktop. I even rebooted yesterday before reporting the crash.

 

So anything I author with the latest Hotfix is no longer authoring.

 

Since something has seemingly corrupted should I:

  • Erase and Reinstall the latest Hotfix
  • Erase and Reinstall the whole EoF program
  • Erase and Reinstall the latest toolkit
  • Erase and Reinstall Rocksmith 2014

I guess I'll start in the above order and probably do so tomorrow morning since I have to go to work soon...

 

Edit: Somehow rebotting EoF and rebooting the RSToolkit allowed me to test  the dummy chord boxes to see if manually changing the XML to High Density =1 in the dummy chord tag in the XML would author the desired  |_| chord box instead of the square box. Here is what I found.

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/HOPOonSomeStringsOfChord-GitHubIssue153/Attempt%20at%20creating%20dummy%20half%20box%20-%20Attempt%201_zps0vw4xdvd.png

 

Hopefully rebooting EoF and RSToolkit is all I needed to get the above crashes resolved. TBD tomorrow morning.

 

Edit 2:

 

After testing the dummy chord boxes in the Edit 1 above,, after having rebooted EoF and RSToolkit, I had just enough time to retry testing

 

  • 10 chord sequence of A5 power chords with a bit of time between chords 5 and 6, (no hi dens statuses, no Crazy chords, no handshape marking) --> NO CRASH (contrary to the 4th last bullet above)

 

I will proceed tomorrow adding 1 item at a time so as to return to the first image in the top of this post, the last one being crazy+hi-dens on chord 6. Hopefully we'll conclude then what's breaking the game.

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

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

Check out the Tech Notes Tutorial Version 1.1 // Chordify Tutorial release TBD.

Link to post
Share on other sites

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.

Link to post
Share on other sites

I am lost with all the changes, and I just want to check if this is expected

 

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

 

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

 

the D5 slides up to the E5 then there is an E5 repeat.  The FHP changes in the repeat of the E5 from the original E5.  I would have thought that the FHP would not change back until the next D5?

 

If you want files I can give them, just want to check first.  It's 1-16-2016.

 

 

Thanks :D

Link to post
Share on other sites

Hopefully this makes it clearer

 

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

 

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

 

 

it's a basic repeated double stop which I presume should have the same FHP (where the box is positioned on the highway), but it jumps 2 frets to the left.

 

To be clear though, it does this through the entire section (and another part of the song where an identical theme appears), it cannot be anything to do with it beginning a new section.

 

I suppose my next step would be to save the project using an old EoF to see if the repeat box comes out on the same fret position.  I'm pretty sure they used to, and somewhere in the recent EoF updates were FHP generation changes.

 

I did nothing, as always, to any FHP manually.  I always just use auto EoF when saving.

 

It did strike me as odd the first time I played it, I had to kind of look twice to see what to do.  I'm pretty sure there has been a change in behaviour, but I will double check tonight.

Link to post
Share on other sites

Your first image Plum is something I don't seem to understand what is being shown on screen or have ever seen, though it looks cool and flashy .... :) I too do not understand what you are pointing out.

 

So below I resume crash testing from my previous post 1462.  Seems like everything is fine after all and the crashing was sopme sort of unexplained anomaly...

 

Zoomable Link

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/High%20density/Hotfix%2001-16-2016%20-%20Determining%20cause%20of%20crashing_zpsbzqdxbnu.png

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

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

Check out the Tech Notes Tutorial Version 1.1 // Chordify Tutorial release TBD.

Link to post
Share on other sites

  • Administrator

The problem PC plum is highlighting is the FHP automated generation that is changing the anchor from 12 to 10 but it should stay on 12 since it's a repeating chord.

 

I'm not sure it's really new but the change in the way repeating chord are managed in EOF might have exacerbate a bit the issue.

Firekorn's workshop
In Flames Discography

#FirekornHasDoneNothingForTheCommunity

Link to post
Share on other sites

My guess is that since it's two notes on the same fret on consecutive strings the FHP generation treats the chord as "fingerable" in all positions of the current FHP, so the only reason the FHP moves to 12 is because of the slide. It may not be perfect, but otherwise FHP generation for things like drop power chords would probably be a disaster.

My CDLC releases and my workshop 
My CDLC previews (Lots of bass only stuff)
Join us at the Rocksmith Championship!

Link to post
Share on other sites

It's a basic repeated double stop which I presume should have the same FHP (where the box is positioned on the highway), but it jumps 2 frets to the left.

I see. The FHP generation is forced to change position at the end of the slide but immediately wants to get back to a position where all notes are playable in a 4 fret range. I may be able to make a special condition in the logic so that an FHP change isn't automatically created for a repeat chord perhaps except in some cases (ie. the latter instance defines use of the index finger and the previous did not).

 

I suppose my next step would be to save the project using an old EoF to see if the repeat box comes out on the same fret position. I'm pretty sure they used to, and somewhere in the recent EoF updates were FHP generation changes.

I would imagine it exported this way since the r1396 hotfix (April 25, 2015), which was the first hotfix to have the logic to place an FHP change to reflect the end position of a slide.

 

Edit: I added a condition to the FHP logic and it gets the desired result on PC Plum's example now.

  • Like 1
Link to post
Share on other sites

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

Link to post
Share on other sites

Maybe it's the official equivalent of the "dummy chord" mechanism that @@Berneer has been proposing.

 

Berneer: Would you have time to do any quick tests to see if using a "-1" chord template reference gets the same or similar results to the dummy chord templates you've been testing with? If it works the same way, I'd rather use the "-1" chord reference because it would likely be simpler to program into EOF.

Link to post
Share on other sites

 

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

handshape_without_chord.png

 

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

Sliding chords that have split status is a special case I hadn't considered yet. When the chord is split up into single notes, I will most likely have to add logic to determine each of the new single notes' end of slide positions.

 

I fixed it so that now each of the split up single notes gets the appropriate end of slide position. Regarding the other problem you mentioned here, is it that you're wanting the 4 single note tags associated with those two double stops to be combined into 2 longer single note tags?

 

Edit: A different example may be needed because EOF won't combine a sliding and a linked, non-sliding note because the statuses are different. Doing so would ruin the end of slide effect.

 

Edit 2: A no-technique chord that is linked to the next chord and also has split status doesn't have its single notes combined correctly. I'll look into improving this.

 

Edit 3: I improved RS2 export so that if the first of two identical chords is given split and linknext status, the second chord is properly broken up into single notes and combined with the first chord that is exported as single notes.

Link to post
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.


×
×
  • Create New...

Important Information

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