raynebc

By any chance would you have enough time to kill to try to debug where the crash is occurring (ie. set a breakpoint within set_window_title() and step through until the system driver eventually gets called? This would probably involve re-building with the -ggdb option so GDB can work fully when debugging it.

I'm not sure why GCC with the same compiler and linker options would result in a crashy executable in one Linux distro and a normal executable in another.

@@Mricco89 EOF can't open GPX files, you'll need to have Guitar Pro export them as GP5 files. If you don't have the Guitar Pro program, you can use the free Tux Guitar program (http://www.tuxguitar.com.ar/) to do so. @@Kicker0429 If it's crashing in one of Allegro's functions, there's nothing I can directly do about it. EOF is only calling set_window_title() with constant strings or with arrays with properly-formed C strings. It cannot be getting called with a NULL pointer or anything like that. You might try changing the makefile to build without optimization and see if that gets rid of the problem, then we can work from there.

I'm still guessing it's a GCC issue with it behaving differently than on other platforms. That compiler warning in Append() looks like another false positive. It might not be understanding my malloc_err() wrapper function that guarantees the string is large enough to append the two input strings together. I guess you could check eof_log.txt and see how far it gets. You could also open eof.cfg when EOF isn't running and change the eof_log_level value to 2 or 3 to increase the amount of logging performed and possibly better identify how far the program gets before entering the normal loop waiting for user input.

That first warning is technically true in terms of code style, but it's ultimately a false positive since the destination buffer (eof_chord_shape[num_eof_chord_shapes].name) is in fact allocated to store strlen(name) + 1 bytes nine lines of code earlier. I'll adjust that line to better reflect this and sooth the compiler's warning. The second series of warnings about strncpy seem like they're all false positives. Almost like the compiler doesn't know what strncpy() really is, since it guarantees no overflow when the last parameter specifies a size that isn't larger than the first parameter's buffer size. And the string being copied into the destination buffer is never larger than 2 characters while the destination buffer can accommodate 5 characters. So those compiler warnings are not relevant, but it's weird that a segfault is happening. I've been sticking to an older version of MinGW since at some point the gcc compiler had a drastic optimization change where it could remove NULL pointer checks depending on code style. You might try adding the -fno-delete-null-pointer-checks compiler flag to see if that helps. Otherwise I haven't tested this in Linux in a while but the last time I did in Ubuntu it did not crash on launch. Also, the line numbers cited in the warnings seem wildly different from the line numbers in the current version of the source code. Are you building off the latest git version of it?

Keep in mind that MIDI import is meant to import a rhythm game MIDI, not a generic MIDI file, although you can import the time signatures and tempo changes. You're going to want to import a Guitar Pro file instead in order to bring the tablature into EOF. That error is not a problem with MIDI import specifically, but a problem with where EOF is installed or third party software interfering with EOF (ie. antivirus or cloud syncing programs).

There's no harmonies support in EOF. It's been on the to-do list for a while, but so have a great number of things. I'll basically never run out of features to work on.

I have nothing against it. Knock yourself out.

The "Makefile" file isn't one I ever use. The only one I've ever tested in *nix is makefile.linux in the /src folder. I've updated the link in the Wiki article.

I studied the code a bit and fixed a few bugs. Please try this patch and let me know if it's fixed for you: http://www.mediafire.com/file/qebe83e58svt0w2/spectrogram_fix.patch/file

What kind of error does the OS cite?

http://customsforge.com/topic/1529-latest-eof-releases-1-14-2020/page-131?p=327233&do=findComment&comment=327233

There's not necessarily a good way for me to implement this, there's no way I know of for EOF to detect when you've changed the default audio device in the OS. The very best case scenario would be an on-demand function you'd have to do to re-initialize the audio in EOF, which doesn't save much time versus just restarting the program.

You have to increase the fret count in "Track>Pro guitar>Set number of frets/strings". But if you're using any recent build of EOF (this requires applying the hotfix to now quite-old release candidate), EOF will automatically offer to increase the fret count any time you use the "Edit pro guitar note" or "Edit note frets/fingering" dialogs to set a fret value higher than the track's current fret limit.

I didn't write the spectrogram code, but it was largely written similarly in design as my waveform graph code. Does it crash when rendering the waveform? Did you have another Linux computer on which the spectrogram does not crash? Does it crash regardless of which OGG file you're using as the chart audio? Can you provide the EOF log file as it is immediately after the crash occurs?

Hi, folks. The latest hotfix (1-14-2020) is in the first post. Changes are as follows: *Added "Edit timing" functions to the "Note>Lyric>Lyric lines>", "Note>Solos>", "Note>Star Power", "Note>Trill>", "Note>Tremolo>", "Note>Slider>", "Note>Pro guitar>Arpeggio>" and "Note>Rocksmith>Handshape>" menus that allow the timing of the phrase (determined by the last clicked note/lyric) to be manually changed without having to manipulate note/lyric lengths and re-marking the phrase. *Fixed a bug with the previous hotfix where tom markers were allowed to write for the BRE difficulty, which could cause the normal drum notes to incorrectly export as toms. *Added error detection to the creation of undo/redo files. *Changed Feedback import so that notes are always padded to a minimum of 1ms length during the import instead of afterward, to better ensure slider phrases export to MIDI in a way that is supported by differing rhythm games. *Added macros to display the start and end timestamps of whichever lyric line, slider phrase, star power, solo, trill, trmolo, special drum roll, drum roll, arpeggio or handshape phrase phrase the seek position is in, if any. The Clone Hero panel was updated with these. *Fixed a bug with Feedback import where if the chart file specified an MP3 file for the audio, and it was converted to OGG, EOF wouldn't try to open the converted file and the import would fail. *Fixed an issue with Queen Bee import of beat timings where the tempos weren't displayed above the beat markers immediately after the import, requiring some action such as changing the active track. *Updated Queen Bee imports to support section names (one or more sections each defined as the timestamp on one line and the name defined on the next line). *Updated INI export to warn if a GHL track's difficulty is being overridden by a manually defined INI tag in "Song>INI Settings". *Fixed an RS export bug introduced from the 12-6-2019 hotfix that prevented sections from exporting. *Improved the warning during RS export when a populated track difficulty has no fret hand positions by having it cite the name of one of the tracks missing definitions.

If you can send me a project file that gives these messages during save I'll take a look.

I've used Nvidia's Shadow Play recording functionality before. Pretty easy to use and makes high quality video.

That is Apple's fault. They intentionally chose to disable the ability to run all 32 bit software in Catalina. Some people are trying to get EOF to build in OS X as 64 bit, but unless that works, there will be no workarounds other than virtualization or simply keeping an older OS X around to use.

That is intentional behavior. EOF does not track which octave each string is in, just its note. The demand for this kind of thing would have to immensely increase for me to change the tuning system so drastically.

Hi, folks. The latest hotfix (12-12-2019) is in the first post. Changes are as follows: *Added functions to seek to the previous/next time signature changes, which are assigned the ALT+Pg Dn and ALT+Pg Up keyboard shortcuts, respectively. *Updated MIDI export of legacy and vocal tracks to use the manually given name (applied with Track>Rename) for all tracks, regardless of the track's format (ie. normal vs. GHL mode). This should make it a little easier to author a different harmony part in different projects and merge them into one MIDI file outside of EOF. *Added a "Note>Slider>Copy from" menu that will allow slider phrases to be copied from another track. *Fixed a bug with INI export where if any tags contained Unicode characters, the file would be written incompletely. *Added the ability to mark expert difficulty drum notes as flams (Note>Drum>Flam), for potential future use in Clone Hero or Strikeline. The SHIFT+F shortcut was assigned to Note>Drum>Flam>Toggle. If a guitar pro track is being imported as a percussion track, EOF will offer to treat a grace note that precedes a drum note as a flam drum marker for the later note. *Added logic to prevent cloning between dance and non dance tracks, since the dance track cannot increase its lane count. *Improved MIDI import to ignore open strum Sysex markers in the dance track, which are not valid. *Fixed a bug with MIDI import where files containing an SMPTE Offset meta event would not be handled correctly. *Fixed a bug with MIDI import where in some cases, RB3 tracks (ie. pro keys, harmonies) that aren't directly supported in EOF weren't offered to be stored in the project as raw MIDI data. *Added additional error logging to MIDI export. *Added functions to move selected notes forward or backward by one millisecond at a time, by using CTRL+] or CTRL+[ respectively when grid snap is disabled (at which time the "Note>Grid snap" menu will be replaced with a "Note>Move by millisecond" menu to make the functions visible). *Fixed a bug where a fret hand position did not automatically reposition correctly when the note at its position is moved earlier than notes in a lower difficulty. *Added additional error checking and logging for the creation of the config file (eof.cfg) during exit. *Adds a warning at the end of MIDI/Feedback import if there were beats that were inserted and not deleted to store mid-beat tempo/TS changes in the imported file, alerting the author to the need to make corrections to the beats or time signatures. *Fixed a bug with Feedback import where text events could be assigned to the incorrect beat marker if the chart contained non #/4 time signatures. *Removed old Frets on Fire related warnings about the chart audio's sample rate and channel count, since most if not all EOF users have moved on to authoring for other rhythm games by now. *Disabled the ability to toggle an anchor off if the beat's tempo changes and would automatically have the anchor re-added later by other logic. *Greatly improved the efficiency of processing beat information, especially where displaying the secondary piano roll on a large chart with many text events. *Fixed a bug where unsnapped notes would be highlighted in a few scenarios even when that feature was not enabled. *Renamed the "Create image sequence" function to "Export image sequence" and moved it to the File menu with the other export functions. *Added a "Song>Place floating event" function allowing a text event to be placed at an arbitrary millisecond position (the function defaults the event's time to the current seek position) instead of being assigned to a beat marker. For now, if a floating text event exists at the current seek position when the function is used, the existing event is edited instead of a new event being placed. These events will display at the top of the piano roll with a red background (if the "top of 2d pane shows" preference is set to display sections) and appear with an "f" indicator in the "All events" dialog. GH, Feedback and MIDI imports were updated to be able to handle floating text events. *Changed MIDI export to allow the normal notes.mid (which isn't required to be Rock Band standards compliant) to have tom markers in difficulties other than expert (ie. a tom note in hard that doesn't exist in expert).

A response you got in one of your multiple threads on this issue (http://customsforge.com/topic/56384-exporting-to-go-playalong/?do=findComment&comment=324650) is probably your best bet. EOF doesn't create a GP5 file so it can't make assumptions about a file created by a separate program like RocksmithToTab.

For each note: You have to place a tech note, apply pre-bend status to it and define the bend strength. It should look something like this:

Make sure you're using the latest hotfix (10-30-2019), as at one point, the ability to load REALLY old projects was broken and has been fixed. If it still doesn't load in the latest hotfix, please send me the .eof project file so I can troubleshoot. The OGG sample rate warning only matters for Frets on Fire. You can ignore it unless you're really authoring for that game. I'll probably disable that warning since FoF is dead and was never revived.

The fret values in parentheses () are ghost notes. By design, they are not playable notes and are only used to control certain authoring mechanisms like for arpeggios. If you remove the ghost status by selecting the notes and use "Note>Pro guitar>Remove ghost", it might resolve the problem.