Hi guys, I pushed fix to master. Seems to work good :) (I hope, that it will also be so).
-- Regards, Andrew 09.10.2015 09:31, Jens Radloff пишет: > Hi Robert, hi Andrew, > >> Quick question, you are still running a patched version Jens, is that >> right? > Yes. I have compiled my current clone version on 29 September 2015, and > I strongly guess that the source code of that clone version is from the > same day, i.e. updated by the command "git pull". What I reported > yesterday in this email thread, refers to the clone version. > > By the way, I have tested if the behaviour occurs in the official MusE > 2.2.1 version: It does not occur. I tested this five times, i.e. I > started five times the official MusE version, then first loaded > "song_1_distorted_bass.med", then "song_2.med" five times. MusE does not > crash. > > By the way, the behaviour does not always occur in my clone version of > MusE, as I just discovered: My first test today with the clone version > resulted in that the file "song_2.med" was loaded successfully. My second > test today with the clone version resulted in that the file "song_2.med" > was not successfully loaded; MusE crashed. In both cases I first loaded > the other file "song_1_distorted_bass.med". > >> More over, is there something special with these songs > The file "song_2.med" contains a third party VST synth (OXE) and two fluid > synth instances and three MIDI tracks. And a guitarix effect on one of > the fluid synth instances. > The file "song_1_disorted_bass.med" contains two fluid synth instances and > three MIDI tracks. And a guitarix effect on one of the fluid synth > instances. > >> or does it hang if >> you go from other songs also? > The behaviour occurs also if I do the following: > > 1. I start MusE (the clone version) > > 2. I load the file "song_1_distorted_bass.med" > > 3. I load the file "song_1.med", so another file => while the file is > loading, MusE crashes > > The difference between these two files: "song_1.med" contains one fluid > synth instance and three MIDI tracks, and no guitarix effect on one the > fluidsynth instances. "song_1_distorted_bass.med" contains two fluid synth > instances, three MIDI tracks, and the guitarix effect on one of the fluid > synth instances. > > So I think this behaviour is not related to a third party VST synth > (here: OXE), which is part of "song_2.med". > >> If they are special do send them to me and/or Andrew, hopefully that >> will help. > I would like to avoid sending my files to Robert or Andrew. > > Regards, > > Jens > > > Am Donnerstag, 8. Oktober 2015 schrieb Robert Jonsson: >> Hello Jens, Andrew, >> >> Quick question, you are still running a patched version Jens, is that >> right? What is in this patched version? Is there a way to get these >> fixes back to the main line? it's not so good as a long term >> solution. >> >> More over, is there something special with these songs or does it >> hang if you go from other songs also? >> If they are special do send them to me and/or Andrew, hopefully that >> will help. >> >> Regards, >> Robert >> >> 2015-10-08 16:56 GMT+02:00 Jens Radloff <[email protected]>: >>> Hi Andrew, hi @all, >>> >>> I have loaded the file "song_2_distorted_bass.med" in MusE. When I >>> open, while this file is loaded in MusE, another med file, i.e. >>> "song_2.med", then MusE hangs while loading song_2.med. I have to >>> kill MusE with the command "killall muse2" to get out of this >>> situation. >>> >>> To demonstrate at which point MusE hangs, please see the attached >>> screenshot. >>> >>> I can successfully load and play both files in MusE if I start MusE >>> and then either load the file "song_2_distorted_bass.med" or >>> "song_2.med". >>> >>> I have tried to record a debug text with gdb, but when I try to >>> reproduce the behaviour described above with gdb, then it is >>> curious that the behaviour does not appear, i.e. I can >>> successfully first load file "song_2_distorted_bass.med", and then >>> file "song_2.med". I tried to record a debug text with gdb twice, >>> but in both cases I successfully could load both files one after >>> another. >>> >>> Everytime I repeat these steps without the use of gdb, as specified >>> in the first paragraph of this email, then MusE chrashes. >>> >>> So I only could record a debug file with the command "muse2 -DD" in >>> my debug installation. Please see the attached dump file. But it >>> is curious that the behaviour does not appear if I start MusE with >>> the command "./muse2 -DD > dump.txt". But the behaviour appears if >>> I start MusE with the command "./muse2 -DD" (without piping the >>> dump information into a text file). >>> >>> So the attached dump file has been created by the command "./muse2 >>> -DD", and I have copied what was left in the console when MusE >>> crashed. >>> >>> Regards, >>> >>> Jens >>> >>> >>> ------------------------------------------------------------------- >>> ----------- >>> >>> _______________________________________________ >>> Lmuse-developer mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/lmuse-developer ------------------------------------------------------------------------------ _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
