Latest EOF releases (9-26-2020)

[raynebc]

I can't think of any recent changes that would have introduced this kind of behavior. I remember fixing something like that a long time ago, so now every time the active track or difficulty is changed, the clap positions are recalculated immediately instead of just when playback is started. Can you confirm what you're changing when this happens, ie. are you changing from one difficulty to another difficulty in the same track? A different track entirely? Are you using the Tab based keyboard controls or the controls to change to a difficulty by its number (ie. CTRL+SHIFT+#)? Is it required for certain features (ie. secondary piano roll) to be in effect to trigger this problem?

[PC Plum]

I was changing from Bass to Guitar using the ctrl+shift+up/down arrow.  There is only one difficulty per arrangement and I have it in Amazing.

 

Its no real problem, I just thought for a second that were gems hiding that I couldnt see.

[raynebc]

Thanks, I'll fix that.

[Berneer]

Hi all. Long time I haven't posted here. I miss it but have been following as much as I can. Please allow me a few questions.

 

Question 1:

 

Well I'm back authoring a new CDLC (MacGyver Theme Song) and I am having an issue with the fingerstyle bonus arrangement (Part Real_Bass). I am wondering if I've encountered a bug with the new handshape marking feature of Hotfix 1363  or if there's a better way to author what I'm trying to author. Any help would be welcome. It occurs at measure 16 at the 26.4 second mark. I've linked to my EoF file and posted an image of my exact procedure followed that generates my issue.

 

http://www.mediafire.com/download/b2wxi1iwsvdedkl/notes.eof

 

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Marked%20Handshape%20sustains%20curtailed%20issue/Markinghandshapes-sustaincutailingproblem_zps64a06bca.png

 

 

Question 2:

 

Again for my finger-style Part Real_Bass bonus arrangement of the MacGyver song I am basing myself on an excellent YouTube video and though it is a small detail, the 1st notes of the song, an arpeggio I model as a marked hansahpe, are automatically labelled as B7sus4 but the YouTube video I wish to emulate defines it as Esus4, which I also happen to prefer since there is no F# in my chart which a B7sus4 would require. So I followed the procedure improvised in the following image to tailor things to my taste. But my overriding tends to get forgotten by EoF. I don't know all causes for it forgetting of my overriding but simply scrolling later into the song and left-clicking somewhere else in the chart without doing anything else will do it because when I scroll back I find the label as B7sus4 again. I realize this function is found under the "SONG" menu which suggests it's not meant for individual chords and may not be the purpose of the feature, but then again the function won't work unless I choose a specific chord. So I am wondering if it is 1) a bug 2) not doable or 3) doable by another way which I haven't figured out. Any thoughts on this override being forgotten? I'm getting the impression this feature is meant to be applied to whatever chord is selected and applies that to the entire song, which is the reason it appears in the SONG menu...

 

In the same project linked above, this occurs at 3.9 seconds. The overriding or the chord label I attempted intelligently occurs for the other instance a B7sus4 which reoccurs at  arouind 10.4 seconds but alas, they are short-lived since the overriding disappaears without warning.

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Marked%20Handshape%20sustains%20curtailed%20issue/Alternatechordnameissue_zpse160d89b.png

 

Edit:

 

I do get the same issue with a chord name I didn't even need to customize in the chordshapes.xml. See the last chord at the end of the 24th measure (I show it in the following image)?  It is labelled as G. Then when I do Song>ProGuitar>Next chord name, the labelled chord name changes to G5/B which is the label I actually want (since G is not the base note I in the chord I am charting) that EoF intelligently automatically determined as an alternate label. Point is the issue seems unrelated to my customization of the chordshapes.txt file.

 

http://i920.photobucket.com/albums/ad41/Berneer/CustomsForgeStuff/Questions%20for%20CF/Marked%20Handshape%20sustains%20curtailed%20issue/Alternatechordnameissueanotherinstance_zpsa8b1e0d5.png

 

Question 3:

Ran out of time. I will ask my other question later. --> Nevermind. Can't seem to reproduce it anymore.

 

Thanks for your attention.

[raynebc]

Question 1: This is an old limitation where EOF won't allow notes to overlap other notes on the same string. As arpeggio/handshape sections cause the base chord to be placed at the beginning of the section, this makes it harder to author what you're wanting. This was brought up a long time ago, but I thought linknext could be used to extend the truncated notes to merge with notes placed at where the notes ended early. I can't remember for sure. If that doesn't work, my fallback suggestion was to just not author overlapping sustains for notes in arpeggios because notes ringing on top of each other is already implied.

 

Question 2: Changing the chord lookup result isn't permanent, but when you're done authoring all the chords, you can do a select like and use the "Note>Edit name" function, leave the name blank and click OK. EOF will offer to manually permanently apply the currently displayed name(s) to the selected chords. Regarding the 7sus4 chord and some others, it's apparently not uncommon for people to use those chord names even if the chord omits the fifth interval. EOF added variant chord formulas, upon request, to allow this.

[Alex360]

I've put out of hardcoded state that seek marker 300px value, but I need limit it to center of screen and account in page rendering and probably jst compute best position based on a\v delay(because 300 was default a\v and 300 is default seek offset). wip..

[Berneer]

Question 1: This is an old limitation where EOF won't allow notes to overlap other notes on the same string. As arpeggio/handshape sections cause the base chord to be placed at the beginning of the section, this makes it harder to author what you're wanting. This was brought up a long time ago, but I thought linknext could be used to extend the truncated notes to merge with notes placed at where the notes ended early. I can't remember for sure. If that doesn't work, my fallback suggestion was to just not author overlapping sustains for notes in arpeggios because notes ringing on top of each other is already implied.

 

Question 2: Changing the chord lookup result isn't permanent, but when you're done authoring all the chords, you can do a select like and use the "Note>Edit name" function, leave the name blank and click OK. EOF will offer to manually permanently apply the currently displayed name(s) to the selected chords. Regarding the 7sus4 chord and some others, it's apparently not uncommon for people to use those chord names even if the chord omits the fifth interval. EOF added variant chord formulas, upon request, to allow this.

 

Hi raynebc!

 

I missed the excitement of getting stuck, posting a question followed by your generous speedy help that allows me to make a better custom. Thanks again.

 

Question 1,  Linknext works perfectly!

Question 2, Though I've followed your procedure for edit name, the name has permanently changed, but in-game nothing appears. So I reloaded an previous version of my custom with B7sus4 labelled in EoF. I notice now that even then the B7sus4 label didn't appear in-game despite it showing up in EoF.  Strange behaviour. Plus the XML's before and after the change seem to show it working.

 

Before change (B7sus4)

    <chordTemplate chordName="B7sus4" displayName="B7sus4" finger0="-1" finger1="1" finger2="2" finger3="3" finger4="-1" finger5="-1" fret0="-1" fret1="2" fret2="2" fret3="2" fret4="0" fret5="-1"/>

After change (Esus4)

<chordTemplate chordName="Esus4" displayName="Esus4" finger0="-1" finger1="1" finger2="2" finger3="3" finger4="-1" finger5="-1" fret0="-1" fret1="2" fret2="2" fret3="2" fret4="0" fret5="-1"/>

Any ideas why it won't show despite showing in EoF. If not, I don't want to waste your time. There are worst things than a chord label not appearing.

 

Thanks again for your eternal helpfulness!

[PC Plum]

If you use the handshape feature you will not get chord names appearing in game.  The only way to get chords appearing in game is to use an arpeggio setup.

 

 

Good luck, bring on some MacGuyver :D

[SmellyOrc]

I've got a crash bug that pretty reproducible. It involves deleting all the tech notes after the normal notes have been deleted.

Here are the steps I use to create the crash bug:

 

1) Import Guitar pro file with tech notes

2) Ctrl + A to select all normal notes.

3) Press delete

4) Press F4 to go to tech note view

5) Press Ctrl + A to select all tech notes

6) Press Delete

7) Crash

8) ???

9) Profit!

 

Reproducibility is around 80%

 

Edit: One more bug, but I don't know whether it's a bug or intended behaviour:

 

I have time signature changes in my tempo map. Now, because #/8 tempo isn't handled properly yet, I use the double BPM feature as a quick n dirty work-around. Thing is, when I use it, the  time signature change moves to the next few bars over, so that it's in the exact same position time-wise (but not bar-wise, get it?). So, for example I have a 13/8 time sig at bar 31 (00:51 seconds) that I want doubled in BPM, and a 7/4 time sig change at bar 34 (1:08). When I double the BPM at bar 31, the time sig change to 7/4 is now at bar 37 (still at 1:08). And there is no change at bar 34. Is this intended?

[PC Plum]

What version of EoF are you using would be the next question?

 

I've never, ever seen that and I do that stuff all the time to re-import GP files. I'm still using r1363 though.

[SmellyOrc]

The latest one, of course :) But I've noticed this crash since a few versions ago.

[SmellyOrc]

I've found a bug in the "truncate short notes" feature.

 

Anything shorter than a quarter note, regardless of time signature. If a note is tied to another, or has a technique where the duration is important to keep (slide, bend, vibrato) it is not truncated no matter how short the combined length is. If you ever needed to know specifics about any menu functions or preferences, check out the manual (Help>Manual). The preferences are described in the "Configuration EOF>Preferences" section.

 

In short: quarter notes are truncated when they're in a 3/4 time signature bar:

 

http://puu.sh/eKLGl/022106570b.png/ss%20%282015-01-19%20at%2011.28.15%29.png

 

This gets truncated to this:

 

http://puu.sh/eKLMj/5b98f6eeb5.png/ss%20%282015-01-19%20at%2011.28.48%29.png

 

Just thought I'd give a heads up. Don't you just love bugs? :D

[raynebc]

Any ideas why it won't show despite showing in EoF. If not, I don't want to waste your time. There are worst things than a chord label not appearing.

If the XML file is showing the desired chord name, I'm stumped. Maybe some old files were being used by the toolkit or something?

 

I've got a crash bug that pretty reproducible. It involves deleting all the tech notes after the normal notes have been deleted.

Thanks, I've fixed this.

 

Edit: One more bug, but I don't know whether it's a bug or intended behaviour:

 

I have time signature changes in my tempo map. Now, because #/8 tempo isn't handled properly yet, I use the double BPM feature as a quick n dirty work-around. Thing is, when I use it, the  time signature change moves to the next few bars over, so that it's in the exact same position time-wise (but not bar-wise, get it?).

I don't think it's ideal behavior, but it's what I'd expect to happen. The double/halve tempo functions aren't meant to do anything except insert or remove beat markers to satisfy the Magma tool used for Rock Band authoring, it won't do anything as thorough as trying to move time signatures.

 

I've found a bug in the "truncate short notes" feature.

This is 3/4 time signature, right? This is almost surely a math rounding error where doing 0.25 * 0.75 / 0.75 is not equal to 0.25. I'll add some more logic to try to avoid this problem. If the next hotfix doesn't correct that, let me know.

[PC Plum]

an arpeggio I model as a marked hansahpe

Handshape feature does not make chord names appear in game...

[Berneer]

 

Any ideas why it won't show despite showing in EoF. If not, I don't want to waste your time. There are worst things than a chord label not appearing.

If the XML file is showing the desired chord name, I'm stumped. Maybe some old files were being used by the toolkit or something?

 

 

 

 

an arpeggio I model as a marked hansahpe

Handshape feature does not make chord names appear in game...

 

 

Thanks raynebc. Plum is right. As per your hotfix 1363 release notes you did state that marking a handshape with CTRL+SHIFT+H results in a chord highlight but without chord name on the side of the note highway. So the behaviour is expected. Hopefully one day we'll figure out how to add the chord name too.

[PC Plum]

Mark it as an arpeggio section instead of a handshape section and it will display the chord name.

 

I hate arpeggio secitons (I think that they are more confusing than helpful) but it's your custom, and my opinion is not everyone's :D

[Berneer]

I've developed your aversion to arpeggios notation in RS2014, Plum. Especially for a song as fast as finger-style MacGyver. Tried arpeggios and it was a mess. Then SmellyOrc and raynebc suddenly swooped in with this brilliant handshape timely idea/feature. I prefer no chord name with clean look than a messy look with chord name.

I just gotta be careful not to over-use the new handshapes-marking feature. I even started using it for a sequence of notes with same handshapes but with more than one note on the same string in the marked area (even if it was just a pull-off) but then I decided to remove the handshape-marking for those instances because the fingerprints in-game would show the fingering at the beginning of the marked handshape and possibly confuse the player when different notes on the same string but in the marked area are to be played.

raynebc's comment to me yesterday about notes sounding out in an arpeggio (and by extension marked handshake) being implied makes me wonder if I should refrain from the new handshapes-marking feature when I don't want the notes to keep ringing out to be implied. Just want to make sure there is a universal understanding of when this handshape-marking feature is to be used. I guess since handshape-marking is borrowing from the in-game notation of a sustained chord, it only makes sense that this new handshapes-marking feature applies only when it is intended to let the notes ring essentially replacing the arpeggio notation and removing the need for sustain tails. Or are there other instances where the new handshape feature would make sense. Perhaps implying no ringing out unless a sustain tail is added by the author. Just asking to make sure I am on the same page as you guys.

[firekorn]

An handshape marking just means your want the player to know that he is playing a chord and that using the handshape indicated would ease the player instead of playing it note by note, arpegios are more equivalent to the let ring function which indicate that you should keep that handshape and even let ring each note.

 

But in Handshape you can add sustain on note you want to be sustained as ubisoft do (sometimes the let ring is just imply by the audio behind too even in DLC).

 

There's no perfect solution. I agree that Arpegios marking can be a pain but Handshape are not always as good as they seems in the first place either. Every case as it's own proper system sometimes no handshape at all can also works fine.

[raynebc]

I can't really think of any good ways to force a chord name to display on the side of the track. It might be possible to trick the game by doing something like defining a chord template with no strings played or fretted and assign it a display name, but using it might have undesired behavior like displaying a blank chord pane or it could break the game or something.

[Tysylio]

I have received an error a couple of times now that I feel I should report.  It has started since I updated to EoF r1366.  It has happened when I try to save my work.  The error reads:

 

Song folder no longer exists.

Recreate folder?

[Yes] [No]

 If I select No, it does not save, and if I select Yes, I get another window that reads:

 

Could not create folder!

{lists path to folder here}

[OK]

The one way I found to not lose all my work is to Save As, and create a new save file and folder.

 

Unfortunately, I'm not sure if I'm doing something to cause this.  It has occurred twice.  The first time It happened almost as soon as I had updated to r1366, so I thought maybe EoF had trouble reading the files created by the earlier version I had been using (r1363).  But this latest time, I had finished finished charting the rhythm track for my latest song in PART REAL_GUITAR, added the vocal track, saved, and then switched to PART REAL_ GUITAR_22 to begin the lead track.  I set the capo, returned to the rhythm track copied 4 notes at the beginning of the song which are the same on both tracks, returned again to the lead track, pasted the notes, and tried to save but got this error again.

 

Like the first time it happened, I Saved As, created a new folder, and it's OK.  But if I open the old notes file, the error will occur every time I try to save that file.

 

Here is my project folder.  The root folder is the one that won't save, the New folder contains the saved as project as mentioned above.

[raynebc]

I've seen this problem reported by people that use dropbox to backup their EOF projects to the cloud. It seems that Dropbox does something that prevents EOF from seeing the project folder. Can you check if this it the cause by closing Dropbox and trying the save again?

[Tysylio]

I gave it a shot, but I don't use DropBox for that.  Same result.

I have another back-up software (Memeo Instant Back-up), I tried closing that, but again I get the same error.  I'll try suspending the software going forward and see if I encounter the error again.

 

Thanks for your help on this.

[droxid]

Hallo there!

 

I got an xml error(malformed xml) when I tried to import a GPA-xml file. I encountered that I had renamed the Guitar Pro file. I opened the xml file wit an editor and changed the name in the file....Now the import starts for one second but then EOF crashes... does sb know this problem?

 

Thanks!

Edit: It also crashes now when I rty to import the guitar pro file itself that belongs to the xml.

 

Edit: Same happened after I completely resynced everything in GPA, exported everything anew, made a new Project and tried to import the xml: CRASH!! wtf??

[raynebc]

Hi, folks. The latest hotfix (r1369) is in the first post. Changes are as follows:

*Fixed a bug where using the CTRL+SHIFT+# keyboard shortcuts to change the active difficulty or the CTRL+SHIFT+Up/Down keyboard shortcuts to change the active track during playback would not update the sound cues to reflect the contents of the correct difficulty.

*Added "Beat>Double BPM" and "Beat>Halve BPM" menus so the user can specify whether to double or halve the tempo of just the selected beat, or to do so for all beats in the project.

*Fixed a crash that could occur when deleting tech notes.

*Potentially fixed a GP import issue where math rounding errors may cause the "GP import truncates short notes" preference to incorrectly truncate quarter notes in the right conditions.

*Improved logging and error handling in the preview audio creation function.

*Added save logic to avoid a scenario where EOF cannot detect the presence of the project folder, which generally results from unknown causes external to the editor.

 

I gave it a shot, but I don't use DropBox for that.  Same result.

The new hotfix tries a different means of verifying that the project folder still exists, let me know if the problem still happens with the new EOF.

 

It also crashes now when I rty to import the guitar pro file itself that belongs to the xml.

The problem is probably specific to the GP file, if you can send me a download link to it I'll test it out.

[Azrael]

*Added save logic to avoid a scenario where EOF cannot detect the presence of the project folder, which generally results from unknown causes external to the editor.

 

YES! Thank you VERY much!

I tested it, and now I am finally able to move my EOF project files back into Dropbox where the rest of my project files are. I had two project folders all the time, which was really frustrating - now that doesn't seem necessary anymore :D