Latest EOF releases (9-26-2020)

[raynebc]

I'll take a look at it in the near future.

[Chlipouni]

Hi raynebc,

 

  Is there a way to move the beats in EOF without moving the notes ?

 

Thanks

[Alex360]

@@Chlipouni, 2 ways:
1) disable in settings(f11) option "Note auto-adjust"
2) shift click markers and move it

[raynebc]

Without double checking, I think holding shift while you click and drag beats just toggles (ie. enables it if you have that preference disabled) the auto-adjust setting for that operation. Clicking and dragging the first beat marker will always move everything in the track, so if you needed to adjust it, you may need to use the Beat>Add or "Beat>Push offset back" functions to get another beat marker before any notes occur, then you can anchor that beat so the notes stay put while you move earlier beats around.

[SmellyOrc]

Raynebc, I have a small feature request. You know those highlighted noteways with handshapes like this:

(35s in)? I'd like to be able to create this in Eof without editing the XML. I've rummaged about a bit and it seems it should be very easy for you to implement. Thing is, there's already a function like it in EoF: the arpeggio function. To get the above effect, all one needs to do is remove "-arp" from the display name you get when using an arpeggio.

So to implement this function, you'd probably just copy the arpeggio function, and in the output for the display name, you'd just remove "-arp". This would get the desired effect: a handshape and the noteway is highlighted.

 

The only hard part would be to think of a name for it :)

[firekorn]

"Chord highlight" or "Chord shape indication"?

[raynebc]

That's been on the to do list for a while. You're right, it's similar to the logic as the arpeggio stuff, but maybe it could be much simpler and just use a dummy chord template that has nothing to do with the notes played? I haven't looked into this in a while though, can you confirm that it only needs a hand shape tag and that no chord tag is needed? Can you check whether the chord template used in the handshape/chord tags for this need to reflect the notes in the highlighted area?

[SmellyOrc]

1) can you confirm that it only needs a hand shape tag and that no chord tag is needed?

2) Can you check whether the chord template used in the handshape/chord tags for this need to reflect the notes in the highlighted area?

1) I have no idea how to check this

2) It does not. You can use whatever fret number you want. It can even be outside the width of the highlighted area:

 

http://puu.sh/cX7jX/6db6376cad.png

[raynebc]

XML samples from somebody who edits their files to add this feature would verify whether the chord tag needed to be designated for the duration where the highlighted area was displayed or whether just the handshape tag was enough.

[SmellyOrc]

Normal EoF output:

 

http://puu.sh/cXv8s/a4e2815da1.png

 

I tried:

 

1) Deleting everything in the above picture. Didn't work. No highlighted area.

2) Setting the chord templates count to 0 and deleting the chord template part (with display name etc). Toolkit refused to generate a file.

 

Then I set up another arpeggio thingy in EoF, and compared the output. It looks like each chord is given an id. The handshape tag references the chordID:

 

http://puu.sh/cXvHX/164b7ffa1a.png

 

There is no information in the handshape tag themselves, except for start time, end time, and which chord to display. So, chordIDs are not hardcoded. Which chordID refers to which chord, and the fingers needed to play that chord, differs per song/arrangement/xml output. While there is an inherited order (e.g. An A chord comes before an E chord, no matter which chord comes up first in the arrangement), the chordIDs are still dependent on which chords are actually in the XML.

 

So my conclusion would be this: Chord tag IS needed.

[Rockfirstlast]

Yup, add the handshape to the chordtemplate, bump the count up by 1, then add the handshape start/endtime (start time in chronological order or it doesn't work) and bump it's count up by 1.

 

On a related note, here are some things i've noticed:

 

If a handshape is being held, single notes in or outside of the handshape will still be displayed.

 

Chords (after the initial one) will be a high density pane (doesn't matter what chord it is; it'll be a pane)

 

If you change the fret hand position while a handshape is being held, the fingering will still be displayed on the fretboard but the blue highway will disappear.  No reason for this to happen, but I've done it on accident.

[SmellyOrc]

Chords (after the initial one) will be a high density pane (doesn't matter what chord it is; it'll be a pane)

 

Mhh, maybe it's because we're doing it differently, but if/when I add a chord in an arpeggio marked area, I don't get a pane:

 

http://thumbnails109.imagebam.com/36550/67d88e365494953.jpg

[raynebc]

It's sounding like a tag for the highlighted section is not needed, just a tag that references a valid chord template. Can anybody confirm that? Now the only thing that would determine how I implement this is whether anybody else can confirm whether it matters what chord template is used for these sections. I'm guessing the template should still be accurate enough to have the game show correct fingering at the bottom of the screen. So if each highlight phrase needs to reflect correct fingering I may just make a new arpeggio type or something so most of the existing logic can be put to use.

[SmellyOrc]

It's sounding like a <chord> tag for the highlighted section is not needed, just a <handshape> tag that references a valid chord template. Can anybody confirm that? Now the only thing that would determine how I implement this is whether anybody else can confirm whether it matters what chord template is used for these sections. I'm guessing the template should still be accurate enough to have the game show correct fingering at the bottom of the screen. So if each highlight phrase needs to reflect correct fingering I may just make a new arpeggio type or something so most of the existing logic can be put to use.

 

I've looked over the whole xml document, and the only <chord>  tags I can find are:

 

<chordtemplates count>

<chordtemplate>

<chordscount> (which eof has set to 0 in this case. Don't know if that tells you anything?)

 

chordcount = 0 means that it's not important/not used.

<chordtemplates count>  is necessary, otherwise the toolkit does not generate a file

<chordtemplate>  is necessary for the chordID that the <handshape>  tag refers to, and has information on the fingering/handshape.

 

Now, in official DLC, the highlighted phrase only has notes that are in that chord/handshape. However, it still works if it has notes that either don't conform to the handshape, or are even completely out of the highlighted area (width. So if the highlighted area's width is from fret 2 to 5, if you have a note on fret 6, it still works. The note will just appear outside of it.)

 

I hope this clears anything up. If not, I don't know what you mean with the <chord>  tag, as I can't find any other instances of <chord>  in the XML file, other than the ones listed above.

 

So as I said before, it looks like it's using the same logic as arpeggios, with the only difference being the display name? That is assuming the EoF arpeggio logic isn't using anything that's not important ;)

[Alex360]

Hi Raynebc, I'd like to say that it's cool that eof can handle unicode paths when you use "save as" and bad that It can't do it all the time :)

[raynebc]

I've been working on the new highlight phrase type a little bit, but it's not quite ready yet.

 

Hi Raynebc, I'd like to say that it's cool that eof can handle unicode paths when you use "save as" and bad that It can't do it all the time :)

I'm not quite sure what you mean here though, if a project is located in a path that includes Unicode characters, do other save operations (Save, quick save) not work?

[Alex360]

I'm not quite sure what you mean here though, if a project is located in a path that includes Unicode characters, do other save operations (Save, quick save) not work?

 

 

yup works only "save as" save and quick save don't :)

[raynebc]

Does the log give any reason for the failure?

[Alex360]

@@raynebc, it probably just fail to get string and count it as empty here is log for save funstion:

342: eof_save_song() entered
342: Saving to file "eof342-000.undo"
342: 	Save completed
342: 	Saving chart
342: eof_save_helper() entered
342: eof_sort_notes() entered
342: eof_fixup_notes() entered
342: eof_check_fret_hand_positions_option() entered
342: eof_detect_difficulties() entered
342: 		eof_loaded_song_name string is empty
342: 	Error code 3 during "Save"

r1360 from svn repo.

[raynebc]

That string variable is maintained outside the save function and should be accurate as soon as the project is loaded. Can this problem be produced by opening the project and immediately using the save function without making any changes/undos/redos to the project?

[Alex360]

@@raynebc, I did one change before I saved project.

[raynebc]

If you can test without doing any changes, I can rule out things like the undo code.

[Alex360]

@@raynebc here we go:
 

955: 	Project loaded
955: eof_import_ini() entered
955: 	Buffering INI file into memory
955: 	Tokenizing INI file buffer
955: 	Parsing INI file buffer
955: 	Processing INI file contents
955: 	Freeing INI buffer
955: eof_load_ogg_quick() entered
955: eof_destroy_ogg() entered
955: eof_truncate_chart() entered
955: 	Deleting beats
955: eof_truncate_chart() exiting
955: 	Initializing after load
955: eof_init_after_load() entered
955: 	Changing active track
955: eof_menu_track_selected_track_number() entered
955: eof_detect_difficulties() entered
955: eof_scale_fretboard() entered
955: eof_set_color_set() entered
955: eof_calculate_beats() entered
955: eof_truncate_chart() entered
955: 	Deleting beats
955: eof_truncate_chart() exiting
955: eof_select_beat() entered
955: eof_undo_reset() entered
955: eof_detect_difficulties() entered
955: eof_detect_difficulties() entered
955: eof_sort_notes() entered
955: eof_fixup_notes() entered
955: eof_cleanup_beat_flags() entered
955: eof_sort_events() entered
955: 	Initialization after load complete
955: 	Saving chart
955: eof_save_helper() entered
955: eof_sort_notes() entered
955: eof_fixup_notes() entered
955: eof_check_fret_hand_positions_option() entered
955: eof_detect_difficulties() entered
955: 		eof_loaded_song_name string is empty
955: 	Error code 3 during "Save"

[raynebc]

I couldn't reproduce that. I made a project folder with Unicode characters in the filename ("ĹōĻ") and I was able to use File>Save without issue. I added notes, saved, closed and re-opened the project and the changes were there. Can you post the path of one of your project folders that exhibits this issue?

[Alex360]

@raynebc 

D:\Anvil\Workshop\ЧайфChaif-Argentina-Jamaica5-0\notes.eof

all good when cyrilic symbos are gone. i now that it's just useless work, since EOF cli tools can't handle this path but I prefer to enccode oggs by myself :)