From: <gs...@gm...> - 2010-06-27 18:00:05
|
Hello, Once again thanks for Muse. I've been learning how to use some of the audio features better now that I've got a multi-channel card (1010LT). Here's a few of my thoughts on possible bugs, wishlist items or other comments. -WishList - For my workflow, I find it tedious to have twice to change the audio track input and would find it useful only allow one input was selected per wave track at a time. For Example, I click lower left button to select audio input and say I want to change from Audio Input 1 to Audio Input 2. Input 1 is already selected and I add Input 2, but then have to go thorugh the process again to disable Input 1. I would prefer that only one can be selected at a time. Alternatively, maybe the dialog could be kept open until I'm done changing the inputs. Does anyone use this to select 2 inputs? -Bug? - For midi - I can't figure out why when two of my external synths keep getting set to local=off when using muse. (I have to go into the synths' menu and change local=on to use the keyboard). I think this happens at startup. I've checked the list viewer and don't see any obvious commands/sysex that would do this (but I'm not an expert on midi sysex or commands). Anyone else seeing this or have ideas on how to fix. -Bug? User Error? The mixer window size settings doesn't seem to stay set. When I re-open the program, the mixer starts out small and needs to be re-sized. I've never bothered to learn lash, maybe that would fix it? Other thoughts? Not really a big deal. -Bug? - This is probably the most serious - When playing back some audio tracks I can trigger a horrible screeching sound. Basically everything works fine until I click on the play button (on the toolbar) or the forward button (on the toolbar or transport window) again while it is already playing. This does not cause xruns or any other adverse affects except horrible sound out the speakers. It is worked around, by being careful to not click the play or forward buttons when playing. I can provide an audiofile and screenshot if you like. I have the same issue on both the current Fedora12 kernel or CCRMA realtime kernel. I'm running realtime and with the rtc clock and using a recent SVN. I also get these messages in the terminal during the screech. WaveTrack::getData(More ) fifo underrun JackAudioDevice::dummySync Sync timeout - audio not ready! FIFO 0x9581430 underrun... 0 WaveTrack::getData(More ) fifo underrun FIFO 0x9581430 underrun... 0 WaveTrack::getData(More ) fifo underrun FIFO 0x9581430 underrun... 0 WaveTrack::getData(More ) fifo underrun FIFO 0x9581430 underrun... 0 WaveTrack::getData(More ) fifo underrun FIFO 0x9581430 underrun... 0 -Anyway I hope this helps and is intended to be constructive. Thanks, Geoff K. |
From: Robert J. <spa...@gm...> - 2010-06-27 19:59:45
|
Hi Geoff, I have a long list of reported issues that I'm slowly trying to weed through coming the next release. I've added this to this list. Some comments below 2010/6/27 <gs...@gm...>: > Hello, > Once again thanks for Muse. I've been learning how to use some of the audio > features better now that I've got a multi-channel card (1010LT). Here's a > few of my thoughts on possible bugs, wishlist items or other comments. > > -WishList - For my workflow, I find it tedious to have twice to change the > audio track input and would find it useful only allow one input was selected > per wave track at a time. For Example, I click lower left button to select > audio input and say I want to change from Audio Input 1 to Audio Input 2. > Input 1 is already selected and I add Input 2, but then have to go thorugh > the process again to disable Input 1. I would prefer that only one can be > selected at a time. Alternatively, maybe the dialog could be kept open until > I'm done changing the inputs. Does anyone use this to select 2 inputs? Quite right, selecting several happens very seldom. Though since it is technically possible to select several I'd prefer not to remove the possibiltiy. > > -Bug? - For midi - I can't figure out why when two of my external synths > keep getting set to local=off when using muse. (I have to go into the > synths' menu and change local=on to use the keyboard). I think this happens > at startup. I've checked the list viewer and don't see any obvious > commands/sysex that would do this (but I'm not an expert on midi sysex or > commands). Anyone else seeing this or have ideas on how to fix. Would be interesting with more info here, does muse send out some midi when you start it up? I don't think it does.. I think there is some external alsa-midi-monitor that could be used to analyse, not sure though. > > -Bug? User Error? The mixer window size settings doesn't seem to stay set. > When I re-open the program, the mixer starts out small and needs to be > re-sized. I've never bothered to learn lash, maybe that would fix it? Other > thoughts? Not really a big deal. Muse should set the window size for the mixer, there are settings for this in the global config dialog. > -Bug? - This is probably the most serious - When playing back some audio > tracks I can trigger a horrible screeching sound. Basically everything works > fine until I click on the play button (on the toolbar) or the forward button > (on the toolbar or transport window) again while it is already playing. This > does not cause xruns or any other adverse affects except horrible sound out > the speakers. It is worked around, by being careful to not click the play or > forward buttons when playing. I can provide an audiofile and screenshot if > you like. I have the same issue on both the current Fedora12 kernel or CCRMA > realtime kernel. I'm running realtime and with the rtc clock and using a > recent SVN. I also get these messages in the terminal during the screech. > WaveTrack::getData(More ) fifo underrun > JackAudioDevice::dummySync Sync timeout - audio not ready! > FIFO 0x9581430 underrun... 0 > WaveTrack::getData(More ) fifo underrun > FIFO 0x9581430 underrun... 0 > WaveTrack::getData(More ) fifo underrun > FIFO 0x9581430 underrun... 0 > WaveTrack::getData(More ) fifo underrun > FIFO 0x9581430 underrun... 0 > WaveTrack::getData(More ) fifo underrun > FIFO 0x9581430 underrun... 0 That sync message looks odd. Will try to provoke, though I don't think I have seen this error, atleast not in a reproducible way as I understand you mean? > > -Anyway I hope this helps and is intended to be constructive. Yes, very good and constuctive thanks! :) Regards, Robert > Thanks, Geoff K. > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Lmuse-user mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-user > > |
From: Geoff K. <gs...@gm...> - 2010-06-27 20:58:23
|
Hi. concerning this the mixer.. >> -Bug? User Error? The mixer window size settings doesn't seem to stay set. >> When I re-open the program, the mixer starts out small and needs to be >> re-sized. I've never bothered to learn lash, maybe that would fix it? Other >> thoughts? Not really a big deal. >Muse should set the window size for the mixer, there are settings for >this in the global config dialog. I should have mentioned I already tried these settings. It works for the main view and transport, but not mixers. Those always end up in the top left corner of the screen. According to the Global settings this would be at 4, 49, 77, 518 |
From: Geoff K. <gs...@gm...> - 2010-06-28 02:14:36
|
I tried setting the mixer window size gui settings a few more times and it is now working! Not sure why it didn't stick before. On Sun, Jun 27, 2010 at 4:58 PM, Geoff King <gs...@gm...> wrote: > Hi. concerning this the mixer.. > >>> -Bug? User Error? The mixer window size settings doesn't seem to stay set. >>> When I re-open the program, the mixer starts out small and needs to be >>> re-sized. I've never bothered to learn lash, maybe that would fix it? Other >>> thoughts? Not really a big deal. > >>Muse should set the window size for the mixer, there are settings for >>this in the global config dialog. > > I should have mentioned I already tried these settings. It works for > the main view and transport, but not mixers. Those always end up in > the top left corner of the screen. According to the Global settings > this would be at 4, 49, 77, 518 > |
From: Tim E. R. <ter...@ro...> - 2010-06-28 20:30:08
|
On June 27, 2010 01:59:59 pm gs...@gm... wrote: > Hello, > Once again thanks for Muse. I've been learning how to use some of the audio > features better now that I've got a multi-channel card (1010LT). Here's a > few of my thoughts on possible bugs, wishlist items or other comments. > > -WishList - For my workflow, I find it tedious to have twice to change the > audio track input and would find it useful only allow one input was > selected per wave track at a time. For Example, I click lower left button > to select audio input and say I want to change from Audio Input 1 to Audio > Input 2. Input 1 is already selected and I add Input 2, but then have to go > thorugh the process again to disable Input 1. I would prefer that only one > can be selected at a time. Alternatively, maybe the dialog could be kept > open until I'm done changing the inputs. Does anyone use this to select 2 > inputs? No, most likely not, for wave tracks. But for other track types, yes. I agree, selection of routes for a track is very tedious, and the default for some track types is to automatically connect to the first available input or output, which really just gets in the way. When I just want to add 5 wave tracks so I can quickly go ahead with 5 recording takes, it becomes very annoying to have to click the routing menus and undo all the defaults AND do all the desired routes. In the midi/softsynth device settings window, do you see the new Jack midi column labelled 'routes'? When you click on it and choose 'show first (or second) aliases' the menu *stays* open. I threw that little touch in there because I knew that having the menu disappear each time would be clumsy. So, I plan to do the same for each of the track routing menus. Those menus should stay open until the user clicks elsewhere. This way the routing menus will stay open and you can just click-click-click quickly. It'll take time, but it is high on my to-do list because it is so annoying. > > -Bug? - For midi - I can't figure out why when two of my external synths > keep getting set to local=off when using muse. (I have to go into the > synths' menu and change local=on to use the keyboard). I think this happens > at startup. I've checked the list viewer and don't see any obvious > commands/sysex that would do this (but I'm not an expert on midi sysex or > commands). Anyone else seeing this or have ideas on how to fix. MusE will send out sysex commands automatically upon loading a song, and each time upon rewinding to start, *if* the 'song type' list box in the arranger is set to 'GM', 'GS', or 'XG'. Each of those settings sends out appropriate sysex initialization commands. You can try setting it to 'NO', so it will not send anything (it shouldn't). But then, that that will affect the behaviour of the song. So if you need the song type to be other than 'NO', you can try storing a sysex in the song which would set your synth's local setting. You would need to look up the appropriate sysex in your manual and enter in MusE's midi event list. I hope that's the problem we're talking about here. If you want, you can send me the song(s) .med file and I will examine it to make sure nothing is stored there and being sent out which shouldn't be. > > -Bug? User Error? The mixer window size settings doesn't seem to stay set. > When I re-open the program, the mixer starts out small and needs to be > re-sized. I've never bothered to learn lash, maybe that would fix it? Other > thoughts? Not really a big deal. Yep, it's a bug. I'm trying to fix these mixer window issues. Sometimes they don't return to their original size when reloading a song. (Also, in some cases, they're BOTH labelled as 'Mixer B'.) I'm having some trouble with resizing them if they're already created. A workaround, as Robert said, is to start MusE blank, and if the mixers appear, then immediately go to the settings dialog and tell it not to show the mixers. Then restart MusE with a song, and the mixers should show and resize OK. > > -Bug? - This is probably the most serious - When playing back some audio > tracks I can trigger a horrible screeching sound. Basically everything > works fine until I click on the play button (on the toolbar) or the forward > button (on the toolbar or transport window) again while it is already > playing. This does not cause xruns or any other adverse affects except > horrible sound out the speakers. It is worked around, by being careful to > not click the play or forward buttons when playing. I can provide an > audiofile and screenshot if you like. I have the same issue on both the > current Fedora12 kernel or CCRMA realtime kernel. I'm running realtime and > with the rtc clock and using a recent SVN. I also get these messages in the > terminal during the screech. > WaveTrack::getData(More ) fifo underrun > JackAudioDevice::dummySync Sync timeout - audio not ready! > FIFO 0x9581430 underrun... 0 > WaveTrack::getData(More ) fifo underrun > FIFO 0x9581430 underrun... 0 > WaveTrack::getData(More ) fifo underrun > FIFO 0x9581430 underrun... 0 > WaveTrack::getData(More ) fifo underrun > FIFO 0x9581430 underrun... 0 > WaveTrack::getData(More ) fifo underrun > FIFO 0x9581430 underrun... 0 > > -Anyway I hope this helps and is intended to be constructive. > Thanks, Geoff K. Ah, I can tell you've turned off the 'Use Jack transport' option in the sync settings. There are still some issues with that option. I don't recall audio screeching being one of them, though. I recall it can cause sluggishness or slowdowns. Maybe it is affecting the ability of the audio to keep up... Try to avoid turning it off if you can, at least for these tests. However, audio screeching was one bug I fixed recently in SVN a few weeks ago. It involved unconnected Audio Inputs. Make sure you use the very latest SVN. And yes, please provide some audio or video for us so we can see what's going on, as I would consider this a serious bug worthy of my immediate attention. Tim. |
From: Geoff K. <gs...@gm...> - 2010-06-29 02:46:13
|
I've a few more comments below. > So, I plan to do the same for each of the track routing menus. > Those menus should stay open until the user clicks elsewhere. > This way the routing menus will stay open and you can just click-click-click > quickly. > It'll take time, but it is high on my to-do list because it is so annoying. That would be good. >> -Bug? - For midi - I can't figure out why when two of my external synths >> keep getting set to local=off when using muse. (I have to go into the >> synths' menu and change local=on to use the keyboard). I think this happens >> at startup. I've checked the list viewer and don't see any obvious >> commands/sysex that would do this (but I'm not an expert on midi sysex or >> commands). Anyone else seeing this or have ideas on how to fix. > MusE will send out sysex commands automatically upon loading a song, > and each time upon rewinding to start, *if* the 'song type' list box > in the arranger is set to 'GM', 'GS', or 'XG'. > Each of those settings sends out appropriate sysex initialization commands. > You can try setting it to 'NO', so it will not send anything (it shouldn't). > But then, that that will affect the behaviour of the song. > So if you need the song type to be other than 'NO', you can try > storing a sysex in the song which would set your synth's local setting. > You would need to look up the appropriate sysex in your manual and > enter in MusE's midi event list. > I hope that's the problem we're talking about here. > If you want, you can send me the song(s) .med file and I will examine > it to make sure nothing is stored there and being sent out which > shouldn't be. This one is still a mystery. I do use the NO setting. If I can't figure it out I'll send you something or just keep changing the synth settings now that I know what is going on. >> -Bug? User Error? The mixer window size settings doesn't seem to stay set. >> When I re-open the program, the mixer starts out small and needs to be >> re-sized. I've never bothered to learn lash, maybe that would fix it? Other >> thoughts? Not really a big deal. > Yep, it's a bug. I'm trying to fix these mixer window issues. > Sometimes they don't return to their original size when reloading a song. > (Also, in some cases, they're BOTH labelled as 'Mixer B'.) > I'm having some trouble with resizing them if they're already created. > A workaround, as Robert said, is to start MusE blank, and if the > mixers appear, then immediately go to the settings dialog and tell it > not to show the mixers. Then restart MusE with a song, and the mixers > should show and resize OK. Seems to be working okay for the moment. Good to know this workaround if I need it. >> -Bug? - This is probably the most serious - When playing back some audio >> tracks I can trigger a horrible screeching sound. Basically everything >> works fine until I click on the play button (on the toolbar) or the forward >>[removed part] > Ah, I can tell you've turned off the 'Use Jack transport' option > in the sync settings. There are still some issues with that option. > I don't recall audio screeching being one of them, though. > I recall it can cause sluggishness or slowdowns. > Maybe it is affecting the ability of the audio to keep up... > Try to avoid turning it off if you can, at least for these tests. > > However, audio screeching was one bug I fixed recently in SVN > a few weeks ago. It involved unconnected Audio Inputs. > Make sure you use the very latest SVN. > And yes, please provide some audio or video for us so we can see > what's going on, as I would consider this a serious bug > worthy of my immediate attention. > Setting the 'Use Jack transport' option fixed this and there is no more screeching sound. This version is from 22.06.2010 |
From: Tim E. R. <ter...@ro...> - 2010-06-29 20:50:31
|
On June 28, 2010 10:31:30 pm you wrote: > I've a few more comments below. > > > So, I plan to do the same for each of the track routing menus. > > Those menus should stay open until the user clicks elsewhere. > > This way the routing menus will stay open and you can just > > click-click-click quickly. > > It'll take time, but it is high on my to-do list because it is so > > annoying. > > That would be good. Yesterday I did just that. I made all the menus stay open. It worked well, but then I realized, not so fast... I have to make it more complex because the menus have to wait until messages which add or remove a route have been processed before the menus can read the routes again and re-display them. I have a workaround compromise, will try it when I get a chance. > > >> -Bug? - For midi - I can't figure out why when two of my external synths > >> keep getting set to local=off when using muse. (I have to go into the > >> synths' menu and change local=on to use the keyboard). I think this > >> happens at startup. I've checked the list viewer and don't see any > >> obvious commands/sysex that would do this (but I'm not an expert on midi > >> sysex or commands). Anyone else seeing this or have ideas on how to fix. > > > > MusE will send out sysex commands automatically upon loading a song, > > and each time upon rewinding to start, *if* the 'song type' list box > > in the arranger is set to 'GM', 'GS', or 'XG'. > > Each of those settings sends out appropriate sysex initialization > > commands. You can try setting it to 'NO', so it will not send anything > > (it shouldn't). But then, that that will affect the behaviour of the > > song. > > So if you need the song type to be other than 'NO', you can try > > storing a sysex in the song which would set your synth's local setting. > > You would need to look up the appropriate sysex in your manual and > > enter in MusE's midi event list. > > I hope that's the problem we're talking about here. > > If you want, you can send me the song(s) .med file and I will examine > > it to make sure nothing is stored there and being sent out which > > shouldn't be. > > This one is still a mystery. I do use the NO setting. If I can't > figure it out I'll send you something or just keep changing the synth > settings now that I know what is going on. It's possible MusE sends out something upon startup. I must check this... > > >> -Bug? User Error? The mixer window size settings doesn't seem to stay > >> set. When I re-open the program, the mixer starts out small and needs to > >> be re-sized. I've never bothered to learn lash, maybe that would fix it? > >> Other thoughts? Not really a big deal. > > > > Yep, it's a bug. I'm trying to fix these mixer window issues. > > Sometimes they don't return to their original size when reloading a song. > > (Also, in some cases, they're BOTH labelled as 'Mixer B'.) > > I'm having some trouble with resizing them if they're already created. > > A workaround, as Robert said, is to start MusE blank, and if the > > mixers appear, then immediately go to the settings dialog and tell it > > not to show the mixers. Then restart MusE with a song, and the mixers > > should show and resize OK. > > Seems to be working okay for the moment. Good to know this > workaround if I need it. Yeah, bit of a pain those mixer windows. We'll get it right eventually... > > >> -Bug? - This is probably the most serious - When playing back some audio > >> tracks I can trigger a horrible screeching sound. Basically everything > >> works fine until I click on the play button (on the toolbar) or the > >> forward button (on the toolbar or transport window) again while it is > >> already playing. This does not cause xruns or any other adverse affects > >> except horrible sound out the speakers. It is worked around, by being > >> careful to not click the play or forward buttons when playing. I can > >> provide an audiofile and screenshot if you like. I have the same issue > >> on both the current Fedora12 kernel or CCRMA realtime kernel. I'm > >> running realtime and with the rtc clock and using a recent SVN. I also > >> get these messages in the terminal during the screech. > >> WaveTrack::getData(More ) fifo underrun > >> JackAudioDevice::dummySync Sync timeout - audio not ready! > >> FIFO 0x9581430 underrun... 0 > >> WaveTrack::getData(More ) fifo underrun > >> FIFO 0x9581430 underrun... 0 > >> WaveTrack::getData(More ) fifo underrun > >> FIFO 0x9581430 underrun... 0 > >> WaveTrack::getData(More ) fifo underrun > >> FIFO 0x9581430 underrun... 0 > >> WaveTrack::getData(More ) fifo underrun > >> FIFO 0x9581430 underrun... 0 > >> > >> -Anyway I hope this helps and is intended to be constructive. > >> Thanks, Geoff K. > > > > Ah, I can tell you've turned off the 'Use Jack transport' option > > in the sync settings. There are still some issues with that option. > > I don't recall audio screeching being one of them, though. > > I recall it can cause sluggishness or slowdowns. > > Maybe it is affecting the ability of the audio to keep up... > > Try to avoid turning it off if you can, at least for these tests. > > > > However, audio screeching was one bug I fixed recently in SVN > > a few weeks ago. It involved unconnected Audio Inputs. > > Make sure you use the very latest SVN. > > And yes, please provide some audio or video for us so we can see > > what's going on, as I would consider this a serious bug > > worthy of my immediate attention. > > Setting the 'Use Jack transport' option fixed this and there is no > more screeching sound. > I've attached a sound file in case you still want to hear it. This > version is from 22.06.2010 > > Thanks, Geoff K. I listened to the file. Wow, that glitch is a good imitation of morse code over a ham radio ! Yeah, the Jack transport option is a pain for a few users, including the other Geoff. Must get around to reviewing and fixing it someday... I was going to mention that I did observe momentary audio glitches while hitting FF or REW or moving the cursor, whether playing or just idle with incoming live audio. It may be sounding nonsense data while it takes the time to locate to a new position. I will try to make it deliver silence instead, during those times. Thanks for the reports ! Hope you're still able to use and enjoy MusE in its current state. Tim. |