From: Viktor M. <vi...@ma...> - 2009-06-16 23:08:21
|
Ok, So far, Muse has been perfect and stable. Trouble started when I wanted to load simpleDrums. I can get to Settings/Midi Ports and load the synth, but as soon as I set a midi or drum channel to use simpledrums (the O-port), Muse crashes with a 'segmentation fault' The same happens if I try to open a new file > template > audio.med Here, as soon as I click Settings/Midi Ports the program crashes with a 'segmentation fault' Constantly, all the time. I am using UbuntuStudio 9.04, 64-bit, default installation. (is there a distro/setup that is specifically Muse-friendly?) Here's what I get in the terminal: viktor@ubuntustudio:~$ muse SSE2 detected no locale <muse_en_GB.UTF-8>/</usr/local/share/muse/locale> VST_PATH not set, defaulting to /home/viktor/vst:/usr/local/lib/vst:/usr/lib/vst Trying RTC timer... fatal error: open /dev/rtc failed: Permission denied hint: check if 'rtc' kernel module is loaded, or used by something else Trying ALSA timer... AlsaTimer::initTimer(): best available ALSA timer: system timer got timer = 47 fluidsynth sampleRate 48000 fluidsynth sampleRate 48000 AlsaTimer::setTimerTicks(): requested freq 1024 Hz too high for timer (max is 1000) freq stays at 1000 Hz SimpleSynth sampleRate 48000 Segmentation fault viktor@ubuntustudio:~$ any help, please? Viktor |
From: Tim <ter...@ro...> - 2009-06-17 00:10:38
|
Hello, Viktor... On Tuesday 16 June 2009 19:07:48 Viktor Mastoridis wrote: > Ok, > > So far, Muse has been perfect and stable. > > Trouble started when I wanted to load simpleDrums. > > I can get to Settings/Midi Ports and load the synth, but as soon as I set a > midi or drum channel to use simpledrums (the O-port), Muse crashes with a > 'segmentation fault' Yes, I confirmed the bug here! With both Jack-1 and Jack-2. Simply add a simpledrums instance, then simply attempt to add a midi track, and we get a segfault. I will investigate. Be patient... Lots going on... > The same happens if I try to open a new file > template > audio.med > Here, as soon as I click Settings/Midi Ports the program crashes with a > 'segmentation fault' > Constantly, all the time. Er, well, I didn't see that one, but I'll try again. Was simpledrums involved here? Did you restart Muse and try again? > I am using UbuntuStudio 9.04, 64-bit, default installation. > (is there a distro/setup that is specifically Muse-friendly?) At the moment, distros using libtool2 have one problem compiling Muse from CVS, regarding musewidgetsplugin.so I think maybe you got around it with the famous "-c" trick? After that Muse should be Ok. But as for 64-bit platform, sorry I'm still running 32-bit. It should be Ok, several people out there are using 64-bit, and they have reported, and helped fix, some issues. Robert reported static noise with his new multi-core system, we'll see if my latest Muse CVS fix helps him there, or whether it's his system... > > Here's what I get in the terminal: > viktor@ubuntustudio:~$ muse > SSE2 detected Ok, so you are using around Jack-0.116.2 or so (Jack '1'), right? Good so far... > no locale <muse_en_GB.UTF-8>/</usr/local/share/muse/locale> > VST_PATH not set, defaulting to > /home/viktor/vst:/usr/local/lib/vst:/usr/lib/vst Hmm, just curious, did you configure muse with VST support? (Not recommended any more). Or do you have DSSI installed? > Trying RTC timer... > fatal error: open /dev/rtc failed: Permission denied > hint: check if 'rtc' kernel module is loaded, or used by something else > Trying ALSA timer... > AlsaTimer::initTimer(): best available ALSA timer: system timer > got timer = 47 > fluidsynth sampleRate 48000 > fluidsynth sampleRate 48000 > AlsaTimer::setTimerTicks(): requested freq 1024 Hz too high for timer (max > is 1000) > freq stays at 1000 Hz > SimpleSynth sampleRate 48000 > Segmentation fault > viktor@ubuntustudio:~$ > > any help, please? > Viktor |
From: Tim <ter...@ro...> - 2009-06-17 17:56:04
|
On Wednesday 17 June 2009 01:52:32 Viktor Mastoridis wrote: > > > I am using UbuntuStudio 9.04, 64-bit, default installation. > > > (is there a distro/setup that is specifically Muse-friendly?) > > At the moment, distros using libtool2 have one problem compiling > > Muse from CVS, regarding musewidgetsplugin.so > > I think maybe you got around it with the famous "-c" trick? > No, I am not compiling from CVS, I use the 1.0rc2 version that I downloaded > from the website. I don't know what the -c trick is anyway... It's just a little fix to get CVS to compile. CVS has the very latest fixes before a tarball release is put out. It's relatively easy to do... > > Hmm, just curious, did you configure muse with VST support? > > (Not recommended any more). Or do you have DSSI installed? > I didn't configure Muse specifically with VST. But yes, DSSI is installed > by default on UbubtuStudio (can't remove it) and yes, I was trying to get > some VST plugins running via DSSI but gave up... I got it working painlessly, just installed DSSI, pointed it at all my VST plugins, and it works amazingly with just about every VST I throw at it. And with the DSSI-LADSPA package, VST effect plugins actually show up in Muse's list of LADSPA plugins. Real cool. > Lastly, I should probably mention here that I can't save any preset in/from > Deicsonze... When I press Save - nothing really happens.... I think that's been reported too, but I haven't had time to investigate, been concentrating mostly on the application proper itself, delving into the softsynths when time permits. Time heals all wounds... Thanks for the reporting. Tim. |
From: Viktor M. <vi...@ma...> - 2009-06-17 23:15:51
|
> > (-c trick) It's just a little fix to get CVS to compile. > CVS has the very latest fixes before a tarball release is put out. > It's relatively easy to do... Any links with instructions for this? > > > (VST) I got it working painlessly, just installed DSSI, pointed it at all > my > VST plugins, and it works amazingly with just about every VST > I throw at it. And with the DSSI-LADSPA package, VST effect plugins > actually show up in Muse's list of LADSPA plugins. Real cool. Will try again, thanks for encouraging VM |
From: Geoff B. <ge...@la...> - 2009-06-17 23:58:09
|
On Thu, 18 Jun 2009 09:14:24 +1000, Viktor Mastoridis <vi...@ma...> wrote: >> >> (-c trick) It's just a little fix to get CVS to compile. >> CVS has the very latest fixes before a tarball release is put out. >> It's relatively easy to do... > > Any links with instructions for this? welcome Viktor ;) http://muse-sequencer.org/index.php/Cvs ensure that cvs is installed in your distro first,then follow the instructions after you've done the ./configure prefix=/usr --enable-optimize --enable-arch=i686 (or whatever your arch is) you'll need to go to the directory you installed muse, to open /muse/widgets/Makefile (not Makefiel.in or Makefile.am) with a text editor and go to line 309 (MUSECXXFLAGS= ) and add '-c' before the '-g' with a space between, save then run make. then as root user (sudo) run make install and you're done. one more thing you'd best uninstall your existing muse beforehand. sounds hard if you havn't done it before, but it aint really. good luck call out if you're stuck g. |
From: Viktor M. <vi...@ma...> - 2009-06-18 05:31:13
|
> > call out if you're stuck Thanks Geoff, I'll give it a try VM |
From: Robert J. <spa...@gm...> - 2009-06-18 10:42:03
|
Howdy, > > I am using UbuntuStudio 9.04, 64-bit, default installation. > > (is there a distro/setup that is specifically Muse-friendly?) > At the moment, distros using libtool2 have one problem compiling > Muse from CVS, regarding musewidgetsplugin.so > I think maybe you got around it with the famous "-c" trick? > After that Muse should be Ok. > But as for 64-bit platform, sorry I'm still running 32-bit. > It should be Ok, several people out there are using 64-bit, > and they have reported, and helped fix, some issues. > Robert reported static noise with his new multi-core system, > we'll see if my latest Muse CVS fix helps him there, or whether > it's his system... I will try to upgrade to your latest fixes as soon as possible. Just some notes. The code that you removed, setting SCHED_FIFO. As I said this was added as a cludge for some NPTL threading issue where this property was not inherited from Jack. Now I'm confused that it made a difference to remove it. This piece of code has not needed to be run on my system for many years. Either I remember wrong or there is some other way this can be triggered... Either way it is probably good that it is removed. As for 64 bit. I have tried running 64-bit from time to time over the years but have always found it more buggy than 32 bit so I went back. This goes both for the system as a whole, graphics drivers, what not, and also MusE. Last I tried, some months ago, I recall MusE had trouble shutting down. This error didn't bother me much so didn't report it. I think however it is safe to say that there may lurk some 64-bit specific bugs in MusE. Running 32-bit with my own workflow MusE is solid as a rock, the worst that happens is that jack kicks you out from time to time, but MusE handles that quite gracefully. Also, I'm curious, I read the other mail concerning DSSI :) Did MusE get the ability to load DSSIs??? Regards, Robert |
From: Tim <ter...@ro...> - 2009-06-18 23:31:44
|
On Thursday 18 June 2009 06:40:53 Robert Jonsson wrote: > Howdy, > > > > I am using UbuntuStudio 9.04, 64-bit, default installation. > > > (is there a distro/setup that is specifically Muse-friendly?) > > > > At the moment, distros using libtool2 have one problem compiling > > Muse from CVS, regarding musewidgetsplugin.so > > I think maybe you got around it with the famous "-c" trick? > > After that Muse should be Ok. > > But as for 64-bit platform, sorry I'm still running 32-bit. > > It should be Ok, several people out there are using 64-bit, > > and they have reported, and helped fix, some issues. > > Robert reported static noise with his new multi-core system, > > we'll see if my latest Muse CVS fix helps him there, or whether > > it's his system... > > I will try to upgrade to your latest fixes as soon as possible. > > Just some notes. > The code that you removed, setting SCHED_FIFO. As I said this was added as > a cludge for some NPTL threading issue where this property was not > inherited from Jack. > Now I'm confused that it made a difference to remove it. This piece of code > has not needed to be run on my system for many years. Er, what do you mean, it runs the code anyways, or it doesn't run? Or it never seemed to make any difference for you? Maybe now it will... > Either I remember wrong or there is some other way this can be triggered... > Either way it is probably good that it is removed. I would certainly say so! Muse was never this stable! No shutdowns or static in four night of heavy testing and playing. For years I looked for this fix... I guess I have a lot to learn about scheduling, realtime, and threads... I never realized that piece of code was apparently doing it. Just on another plane... The last few times I tried Muse-2 was just before Werner cleaned up the code (Nov 08). Muse-2 would always frequently jack-zombify, similar to Muse-1. That SCHED code is in Muse-2, too ! Now, I just tried Muse-2 again and let me say that it looks and feels much much better now! What a nice job he did. If we remove the SCHED code, maybe Muse-2 also will be more stable. I wonder what he would think about all this... I must ask him... > > As for 64 bit. I have tried running 64-bit from time to time over the years > but have always found it more buggy than 32 bit so I went back. > This goes both for the system as a whole, graphics drivers, what not, and > also MusE. Last I tried, some months ago, I recall MusE had trouble > shutting down. > This error didn't bother me much so didn't report it. > I think however it is safe to say that there may lurk some 64-bit specific > bugs in MusE. If true, we should be hearing about it from all the people in the lists many of whom are using 64-bit. Ok, maybe they just gave up, but I doubt it... Or maybe it doesn't happen as often, being faster machines than mine. > Running 32-bit with my own workflow MusE is solid as a rock, the worst that > happens is that jack kicks you out from time to time, but MusE handles that > quite gracefully. Ah, try removing the SCHED code. Then see how stable it is... I'll bet "from time to time" goes away. Consider this: My machine is old and Muse would frequently shutdown Jack. So if the SCHED fix did wonders for me, imagine what it will do on a screaming new machine on which Muse shuts down only once in a while... Would be ultra rock-solid... Or conversely, it should really help on my relatively old, slow laptop... > > > Also, I'm curious, I read the other mail concerning DSSI :) > Did MusE get the ability to load DSSIs??? Through DSSI-LADSPA, VST effects show up in Muse's list of LADSPA plugins. Cool, eh? Yep, they load and run. Trouble is, my distro's a bit old and there's a problem that none of the VSTs will give me audio, just howling feedback. Must investigate... Could it be Muse's fault? Maybe, but I figure it's because of my older DSSI and LADSPA packages. Tim. |
From: Tim <ter...@ro...> - 2009-06-19 07:08:20
|
On Thursday 18 June 2009 18:50:43 Tim wrote: > On Thursday 18 June 2009 06:40:53 Robert Jonsson wrote: > > Just some notes. > > The code that you removed, setting SCHED_FIFO. As I said this was added > > as a cludge for some NPTL threading issue where this property was not > > inherited from Jack. > > Now I'm confused that it made a difference to remove it. This piece of > > code has not needed to be run on my system for many years. > Er, what do you mean, it runs the code anyways, or it doesn't run? > Or it never seemed to make any difference for you? Maybe now it will... Oh, I see what you mean. The section of code simply didn't run because Jack was already running SCHED_FIFO. So you're confused as to why it's running here. Me, too. It may be fault my playing around with different versions of Jack without fully reconfiguring and rebuilding Muse. Weird, but my last rebuild was with Jack-2, and with it, the SCHED code runs, but now when I reinstall an earlier version of Jack-1 without rebuilding Muse, the SCHED code doesn't run. Whereas my second last rebuild used Jack-1 and the SCHED code ran. Well, don't try to make sense of all that, but it might be the cause. Using 'ps' I see my different versions of Jack using FF or RR scheduling. Trolling through old list messages I see a couple of other users' log postings showed the scheduling code running, too. (Recently, from Emanuel, who was using Jack-2 which runs as RR scheduling). For me it begs the question "Why was the scheduling code running at all, if I never even installed Jack-2 before. Which policy WAS my Jack-1 using before? Must have been NORMAL or RR. And why is it FF now when I reinstall Jack-1?". This whole scheduling code episode is like some weird "comedy of errors", eh? "JACK thread not running SCHED_FIFO, try to set..." "JACK thread succesfully set to SCHED_FIFO" Does anyone else out there find those messages when running Muse-1 RC1, RC2 etc. or from CVS (BEFORE my latest commit which removed the SCHED code)? "My brain hurts" (Monty Python) Caio for now... Tim. > > > Either I remember wrong or there is some other way this can be > > triggered... Either way it is probably good that it is removed. > > I would certainly say so! Muse was never this stable! > No shutdowns or static in four night of heavy testing and playing. > For years I looked for this fix... > I guess I have a lot to learn about scheduling, realtime, and threads... > I never realized that piece of code was apparently doing it. > > Just on another plane... The last few times I tried Muse-2 was > just before Werner cleaned up the code (Nov 08). > Muse-2 would always frequently jack-zombify, similar to Muse-1. > That SCHED code is in Muse-2, too ! > Now, I just tried Muse-2 again and let me say that it looks and feels > much much better now! What a nice job he did. > If we remove the SCHED code, maybe Muse-2 also will be more stable. > I wonder what he would think about all this... I must ask him... > > > As for 64 bit. I have tried running 64-bit from time to time over the > > years but have always found it more buggy than 32 bit so I went back. > > This goes both for the system as a whole, graphics drivers, what not, and > > also MusE. Last I tried, some months ago, I recall MusE had trouble > > shutting down. > > This error didn't bother me much so didn't report it. > > I think however it is safe to say that there may lurk some 64-bit > > specific bugs in MusE. > > If true, we should be hearing about it from all the people in the lists > many of whom are using 64-bit. Ok, maybe they just gave up, but I doubt > it... Or maybe it doesn't happen as often, being faster machines than mine. > > > Running 32-bit with my own workflow MusE is solid as a rock, the worst > > that happens is that jack kicks you out from time to time, but MusE > > handles that quite gracefully. > > Ah, try removing the SCHED code. Then see how stable it is... > I'll bet "from time to time" goes away. > Consider this: My machine is old and Muse would frequently shutdown Jack. > So if the SCHED fix did wonders for me, imagine what it will do on a > screaming new machine on which Muse shuts down only once in a while... > Would be ultra rock-solid... > Or conversely, it should really help on my relatively old, slow laptop... > > > Also, I'm curious, I read the other mail concerning DSSI :) > > Did MusE get the ability to load DSSIs??? > > Through DSSI-LADSPA, VST effects show up in Muse's list of > LADSPA plugins. Cool, eh? Yep, they load and run. > Trouble is, my distro's a bit old and there's a problem that > none of the VSTs will give me audio, just howling feedback. > Must investigate... Could it be Muse's fault? Maybe, but > I figure it's because of my older DSSI and LADSPA packages. > > Tim. > > --------------------------------------------------------------------------- >--- Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Lmuse-user mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-user |