Latest EOF releases (9-26-2020)

[SmellyOrc]

Obviously this sticky key with the ctrl and shift button is a windows problem.

So I finally did the obvious and checked windows sticky keys,

on win8.1 called "Make the keyboard easier to use" (ease of access center).

They somehow turned on "Toggle keys by holding down NUM Lock for 5 seconds)

 

They have some kind of humor, as I never asked for this.

The sticky keys have gone, for a while ...

 

So I take it that uninstalling that windows update didn't fix it for you?

[TomSawyer2112]

 

So I take it that uninstalling that windows update didn't fix it for you?

 

 

I didn't uninstall all back to the 14 august, as this could only be a temporary solution.

I wanted to know the reason and hopefully found that in the "Make the keyboard easier to use" settings

 

No, uninstalling  Security Update for Windows 8.1 for x64-based Systems KB299365 did not work for me.

 

Unchecking all options in "Make the keyboard easier to use" (ease of access center) still resolved problem

Edited September 6, 2014 by TomSawyer2112

[SmellyOrc]

I wasn't talking about all updates, just a specific one.

[MadMaxx]

If nothing can be done it can't be done, at least I understand a bit about what's going on now and can maybe bend a few tempos around to suit myself :)

 

rounding issues on normal and tech notes is nothing unusual, it was actually a lot worse a few month ago but raynebc improved the rounding a lot. It will still happen but in a lesser extent now, you should still  use the "Highlight  non Grid snapped notes" setting in the song menu to track down the notes that are not grid snapped, same goes for tech notes. A red tech notes mean that it does not touch the note head or its sustain.

[raynebc]

Did you change the behaviour for the selection of multiple notes ?

 

  Now I need to [shift+click] the first gem and [click] the last one. Then when I select another gem for a new sequence of notes, it extends the previous selection

This Windows update is starting to affect more and more people, which is unfortunate. I haven't heard back from the other EOF developer yet, so I'll ask about it on the Allegro forum. If somebody who is affected by this problem is willing to try a version of EOF before the major keyboard handling changes (1.8RC8 or older) just to rule that out? If so, here's 1.8RC8:

http://www.mediafire.com/download/3hssc9s2ogbx3b8/eof1.8RC8(r1198).zip

 

I am predicting that the red tech notes are simply maths rounding errors, or indeed the difference between using milliseconds for calculations and beats for calculation.

I haven't had time to test your files out yet, but my first thought was also rounding errors, like maybe I forgot to have the tech notes round up to the nearest millisecond instead of just rounding down or something.

 

for what ever reason im no longer able to cut and paste certain sections of riffs i cant select all and whenever i drag sometthing it slows the song down half speed. anyone know what the hell im doing wrong?

Could be the Windows 8.1 update issue if that's your OS. One way to tell would be to watch the information panel to see if it's properly indicating when you're pressing the CTRL, SHIFT and ALT keys. Clicking and dragging wouldn't slow the audio down, do you mean it's changing the tempo of a beat marker?

[firekorn]

The CTRL/SHIFT/ALT key work normally in the RC8 that you gave.

[raynebc]

But were those keys not working for you in RC10?

[Chlipouni]

@@raynebc,

 

  CTRL/SHIFT/ALT keys work as expected with the v1.8RC8 (1197) under Windows 8.1.

 

  This is not the case for the last releases of EOF ...

 

Hope that helps to solve this issue

[raynebc]

I reverted the keyboard handling of the modifier keys to how it used to be to see if that resolves the problem. Anybody that still has the offending Windows update installed, please give this hotfix a try and let me know if the modifier keys work properly:

http://www.mediafire.com/download/ixslvik2f26wcn2/eof_hotfix_(r1350b).zip

[Chlipouni]

The keys work fine for me with the r1350b ...

 

Thank you

[firekorn]

Yes i did say it work because i did have the issue and it works perfectly fine with 1350b

[Azrael]

I reverted the keyboard handling of the modifier keys to how it used to be to see if that resolves the problem. Anybody that still has the offending Windows update installed, please give this hotfix a try and let me know if the modifier keys work properly:

http://www.mediafire.com/download/ixslvik2f26wcn2/eof_hotfix_(r1350b).zip

Solves the issue for me as well, thanks!

[TomSawyer2112]

I've test r1350 with options checked in Win8.1

"Make the keyboard easier to use (ease of access center)",

In EOF these options don't influence the behavior of shift/ctrl anymore, except if you turn on

"Sticky Keys". So don't.

 

Another Question (resulting from the Sticky Keys Syndrome):

EOF allows a lot of undo's and they often happen out of current display view.

Would it be possible to see in the information panel what was the last action (to undo / or redo) 

[raynebc]

Adding a text description to every undo state is possible, but it would take a fair amount of work. I'll need to consider it a bit, it could be useful to allow the display of a log showing the action each undo would reverse.

[raynebc]

Not perfect (some beats are still off compared to the note gems) but there were no tech notes going on to the next note.

I had time to look at this and it indeed turned out to be a rounding error, it's sorted out now. Almost all the tech notes import green. The others import red because the half dozen or so notes they are associated with aren't importing from that lead guitar track for various reasons and I'm going to try to see what I can do about that.

[Azrael]

When I use "Alt"-"Tab" on my keyboard to bring EOF back into the foreground, it happens quite often (about every second time I do it) that EOF gets stuck in a state where it thinks the "Tab"-Key is kept beeing pressed.

The result is that the currently open menu cycles through all its options at high-speed, normaly this is the difficulty selection.

 

Luckily the cycling stops when I press left or right and then spacebar to play the song, but it is still very irritating :-)

 

Win 8.1, r1350b

 

I have to use the beta to make "Shift" and "Ctrl" work

[Alex360]

@@Azrael, never use unstable beta for you everyday work xD

and never say never again :)

[PC Plum]

 

I had time to look at this and it indeed turned out to be a rounding error, it's sorted out now.

Thanks very much :D

[raynebc]

When I use "Alt"-"Tab" on my keyboard to bring EOF back into the foreground, it happens quite often (about every second time I do it) that EOF gets stuck in a state where it thinks the "Tab"-Key is kept beeing pressed.

This happens to me, but only rarely and not for a while. I had previously added extra code to try to clear the keyboard buffer every time EOF regains focus but if that doesn't prevent the problem it may be a bug with Allegro and in that case would be out of EOF's control. I'll try to add another little bit that will cause EOF to wait until Tab is no longer being held when the user ALT+Tabs EOF back into the foreground.

[PC Plum]

Man you're a star :D

 

Tried 1350b and used my normal workflow i.e. set bpm then import.  I was gutted to see red tech notes everywhere.

 

Incidentally, I used this

 

http://tabs.ultimate-guitar.com/q/queen/princes_of_the_universe_guitar_pro.htm

 

 

Then I imported again at 120 (which imported perfectly) and adjusted to 85 bpm, and it came out perfect.  Not a red tech note in the entire arrangement.

 

I am so happy :D

 

 

 

I think that it's important to note that there is a difference between importing on 85bpm (for instance) and adjusting to 85bpm from an import on 120bpm.

 

If there is any chance to expand this "fix" to imports on bpms other than 120 then that would be grand, as a lot of time I like to set a complex beat map (songs that go slow, fast, faster, real slow, etc etc) and then re-import as...  well when you change bpm a lot it kind of messes up the end of the chart.

 

That's another problem though, thanks a bunch for this fix :D

[Alex360]

Damn, I just did my first build of EOF from sources. took me half of the day, but I did it, thank you, also build instructions slightly off ;)

[raynebc]

If you have corrections to the wiki, I can add them.

[raynebc]

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

*Improved Guitar Pro import so that bend points are correctly interpreted on a per-string basis as they are defined in Guitar Pro.

*Restored the pre-r1282 detection for modifier keys, since a recent Windows 8.1 update seems to break the functionality of Allegro's key_shifts mechanism so the new logic wouldn't work. This broke detection of modifier keys only and required removing the offending Windows security update to fix.

*Fixed a rounding error of bend points during GP import, instances of which would only manifest itself depending on the beat map.

*Improved the auto-adjust feature by forcing all grid snapped tech notes to resnap to their correct position after notes are adjusted.

*Minor change to switch in callback that will loop until user is no longer holding the Tab key. This should permanently resolve the occasional issue where EOF will think the Tab key is stuck when using ALT+Tab to return EOF to the foreground.

*Fixed a bug where bend tech notes may not export correctly in some conditions.

[MadMaxx]

I have noticed on a lot of occasions that in solos hopos are sometimes not imported correctly, in most cases instead of a pull off a hammer on is imported.

 

Here is the tab, in bar 91 directly at the beginning of the solo the 19 on the third string should be a pull off but its imported as a hammer on. This type of error repeats. Not sure if its authored wrong in the tab or there is a bug in EOF.

 

For example the part in measure 107 also gets completely imported only as hammer ons without pull offs

 

http://tabs.ultimate-guitar.com/m/metallica/through_the_never_ver4_guitar_pro.htm

[Alex360]

Hey, Raynebc, I'm using key_code as key_char when key_char > 255 works great for qwerty keyboards(anyway eof won't accept my non ASCII chars..)

if(eof_key_uchar < 255)
	eof_key_char = tolower(eof_key_uchar);
else
	eof_key_char = eof_key_code + 96;

hue hue