From: Dennis S. <mus...@wi...> - 2012-01-06 18:08:23
|
Hi all, Awakened by Florian's posts I checked out trunk yesterday and tried to compile it. Until now I've been using Muse 1.1 but some odd behavior made me try if version 2.0 would work for me. Indeed I've been very impressed with the new version and the new qt4 UI and Tim's MDI changes work great. At first I was concerned that the new version would have poor performance because I'm using Muse as a pure MIDI sequencer on a rather weak (but silent) machine. My concerns soon proved wrong and Muse runs as good as ever. Well done and congratulations! The new version is a winner for me. Here are some of my findings, though. All tests have been done on XUbuntu 10.10. * The CMake configuration doesn't check for all needed libraries. e.g. compilation fails is libso for OSC is missing * Compilation also fails if DSSI support is disabled. Probably there are some #IFDEFs missing somewhere * I'm not sure about that anymore, but I think liblash headers are also needed for compilation, even if LASH is disabled * There's a resize bug in the arranger. If you create a new song the contents of the arranger don't fill the arranger window. You have to minimize and maximize the arranger window in order to have the content take the full space. This only happens when a new song is created. When an existing song is opened the bug doesn't occur. * The new qt4 UI looks great but I never understood why Muse overrides the system theme of qt. IMHO this is evil and shouldn't be done. The widget theme should only be set outside all applications. No program should be more clever than the user about that. (This is one of the things which bugs me about Rosegarden, too: Its Franken-UI :-)) * If you make changes inside the global configuration dialog but don't apply them (close the dialog with cancel) and then reopen the dialog you still see your old values even though the configuration hasn't changed. The reason here is that inside widgets/genset.cpp all calls to updateSettings() have been commented. Also I would just call updateSettings() inside the constructor instead of having the same code twice. * This one is particular nasty. It is also in Muse 1.1 but I couldn't really find out what's going on. Inside midi.cpp we have the method Audio::initDevices(). It seems to me that here the devices are initialized with the first controller events of all tracks (?) and that GM/XG/GS reset commands are triggered. However initialization often doesn't occur, because this method isn't called. When you open a song all devices are automatically initialized but this seems to be done by any other method. I couldn't even find the method call for that. When the transport location seeks to zero however the method Audio::initDevices() is called. All my midi tracks have a part with needed initialization values like program changes and so on. But when the song is played they are omitted more often than not. My problem here is that I'm working with hardware synthesizers exclusively but often I forget to switch them to Multi/Receive Mode before loading a song. So I want to repeat the initialization by starting playback or reloading the song. Most often it just doesn't work and all I get are a lot of GrandPianos playing. BTW: Inside Audio::initDevices() is a German comment by Werner. Here is the translation: // damit Midi-Devices, die mehrere Ports besitzen, wie z.B. // das Korg NS5R, nicht mehrmals zwischen GM und XG/GS hin und // hergeschaltet werden, wird zunächhst auf allen Ports GM // initialisiert, und dann erst XG/GS // First all ports are initialized to GM and then are changed // to XG/GS in order to prevent that devices with more than one // port, e.g. Korg NS5R, toggle between GM and XG/GS several times. Yours sincerely, Dennis Schulmeister -- Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany Tel: +49 721/5978883 - Fax: +49 721/5978882 - Mob: +49 152/01994400 eMail: de...@wi... - web: there-is.no-ip.org <GnuPG KeyIDs: B8382C97, 01AD62DE> |
From: Tim E. R. <ter...@ro...> - 2012-01-06 20:49:16
|
On January 6, 2012 6:48:14 PM Dennis Schulmeister wrote: > Hi all, > > Awakened by Florian's posts I checked out trunk yesterday and tried to > compile it. Until now I've been using Muse 1.1 but some odd behavior > made me try if version 2.0 would work for me. Indeed I've been very > impressed with the new version and the new qt4 UI and Tim's MDI changes Did you mean MIDI, or Multiple Document Interface? MDI/Mac/Borland interfaces are Florian's work. Neat stuff. I remarked to someone yesterday that we must be the only Linux app which has three selectable user interfaces! > work great. At first I was concerned that the new version would have > poor performance because I'm using Muse as a pure MIDI sequencer on a > rather weak (but silent) machine. My concerns soon proved wrong and Muse > runs as good as ever. Well done and congratulations! The new version is > a winner for me. > > Here are some of my findings, though. All tests have been done on > XUbuntu 10.10. > > * The CMake configuration doesn't check for all needed libraries. > e.g. compilation fails is libso for OSC is missing This was reported by someone else, and fixed last week in SVN. Should compile and work now without OSC. > * Compilation also fails if DSSI support is disabled. Probably there > are some #IFDEFs missing somewhere Oops, thanks, will check! > * I'm not sure about that anymore, but I think liblash headers are > also needed for compilation, even if LASH is disabled Will check - we've got #ifdefs in there for LASH - maybe missing something. LASH isn't available anymore at least here on Ubuntu. LADISH has stepped in as a replacement. By now, LADISH may be fully functional as a replacement for LASH, if I recall recent announcements on LAD. > * There's a resize bug in the arranger. If you create a new song the > contents of the arranger don't fill the arranger window. You have to > minimize and maximize the arranger window in order to have the > content take the full space. This only happens when a new song is > created. When an existing song is opened the bug doesn't occur. I've noticed that. Florian have you seen this? > * The new qt4 UI looks great but I never understood why Muse overrides > the system theme of qt. IMHO this is evil and shouldn't be done. The > widget theme should only be set outside all applications. No program > should be more clever than the user about that. (This is one of the > things which bugs me about Rosegarden, too: Its Franken-UI :-)) Interesting. Never heard that suggestion before. Been like that forever. I guess it's given the user somewhat of a choice in MusE ui outside of the main theme so they don't have to change the main theme. Robert, Florian, Orcan, Geoff, what do you think? > * If you make changes inside the global configuration dialog but don't > apply them (close the dialog with cancel) and then reopen the dialog > you still see your old values even though the configuration hasn't > changed. The reason here is that inside widgets/genset.cpp all calls > to updateSettings() have been commented. Also I would just call > updateSettings() inside the constructor instead of having the same > code twice. Hm, I see. Will check. Thanks! (Configuration has some bugs we hope to iron out - songs may overwrite global settings.) > * This one is particular nasty. It is also in Muse 1.1 but I couldn't > really find out what's going on. Inside midi.cpp we have the method > Audio::initDevices(). It seems to me that here the devices are > initialized with the first controller events of all tracks (?) and > that GM/XG/GS reset commands are triggered. However initialization > often doesn't occur, because this method isn't called. When you > open a song all devices are automatically initialized but this seems > to be done by any other method. I couldn't even find the method call > for that. When the transport location seeks to zero however the > method Audio::initDevices() is called. > > All my midi tracks have a part with needed initialization values > like program changes and so on. But when the song is played they are > omitted more often than not. My problem here is that I'm working with > hardware synthesizers exclusively but often I forget to switch them > to Multi/Receive Mode before loading a song. So I want to repeat the > initialization by starting playback or reloading the song. Most often > it just doesn't work and all I get are a lot of GrandPianos playing. Hm, yes, when transport is moved to song start the initialization values are sent out again, in order to completely reset the devices to some initial state so that the song plays exactly the same each time, regardless of what changes may have happened throughout the song. The consequence of this is that you must have one desired program change at the very beginning of the song. Rewind the song, choose your patch and click one of the 'Add' buttons on the track info panel, in order to add the setting to the song (the setting is placed inside a part). It should work. Failure to do this results in the patch being reset to some default value (say Grand Piano, depends on the chosen instrument) every time the song is rewound. All of this is a result of the song type box being set to 'GM' by default. It used to be on 'NO' song type but was changed to help new users. If you find song type gets in the way, you can set it to 'NO' song type, and then MusE will not attempt to quietly send out any initialization values, and should not reset your patch selections even if rewound. Another thing about that initialization routine is that it tends to send out a lot of info at once - patches, controller values etc. We've noticed that this can overload some instruments with too much information, too fast. Florian reported this, and I notice that my very old (1986) keyboard tends to freak out with a complete system reset sometimes. I guess we'll have to find a way to reduce the info or slow it down. (We're discussing removal of song type, and device initializations being moved to the actual instruments. This might help reduce unnecessary sending of info.) Tim. > > BTW: Inside Audio::initDevices() is a German comment by Werner. Here is > the translation: > > // damit Midi-Devices, die mehrere Ports besitzen, wie z.B. > // das Korg NS5R, nicht mehrmals zwischen GM und XG/GS hin und > // hergeschaltet werden, wird zunächhst auf allen Ports GM > // initialisiert, und dann erst XG/GS > > // First all ports are initialized to GM and then are changed > // to XG/GS in order to prevent that devices with more than one > // port, e.g. Korg NS5R, toggle between GM and XG/GS several times. > > > Yours sincerely, > Dennis Schulmeister |
From: Dennis S. <mus...@wi...> - 2012-01-06 22:56:25
|
Hi Tim, On Fri, 06 Jan 2012 15:48:55 -0500 "Tim E. Real" <ter...@ro...> wrote: > Did you mean MIDI, or Multiple Document Interface? > MDI/Mac/Borland interfaces are Florian's work. Neat stuff. > I remarked to someone yesterday that we must be the only Linux app > which has three selectable user interfaces! Multiple Document Interface. I didn't realize it was Florian's work. :-) > > * I'm not sure about that anymore, but I think liblash headers are > > also needed for compilation, even if LASH is disabled > Will check - we've got #ifdefs in there for LASH - maybe missing something. > LASH isn't available anymore at least here on Ubuntu. > LADISH has stepped in as a replacement. > By now, LADISH may be fully functional as a replacement for LASH, > if I recall recent announcements on LAD. I think it's currently discussed there in a thread about sending midi events. Like I said I'm not sure anymore if compilation really failed due to missing lash headers. > Hm, yes, when transport is moved to song start the initialization values > are sent out again, in order to completely reset the devices to some > initial state so that the song plays exactly the same each time, > regardless of what changes may have happened throughout the song. > ... > All of this is a result of the song type box being set to 'GM' by default. > It used to be on 'NO' song type but was changed to help new users. I always wondered what difference the song types make. Therefor I always use 'NO'. When I open a song the initialization values are sent even if song type is 'NO'. On rewind no initialization is sent which is fine for me. But they aren't played back either though they are definitely present. Usually I fire up the list editor and enter all needed PC#, CC# by hand. > Another thing about that initialization routine is that it tends > to send out a lot of info at once - patches, controller values etc. I never had a problem with that. The instruments I use (though up to 10 - 13 years old) tend to create a lot of information themselves, so they can definitely handle it. :-) Actually it has been the other way round for me. Until last year I used to record with Steinberg Cubase on ATARI and the poor little machine sometimes struggled to process all the incoming MIDI data even when only one of the instruments sent 8 channels at once. Yours sincerely, Dennis Schulmeister -- Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany Tel: +49 721/5978883 - Fax: +49 721/5978882 - Mob: +49 152/01994400 eMail: de...@wi... - web: there-is.no-ip.org <GnuPG KeyIDs: B8382C97, 01AD62DE> |
From: Tim E. R. <ter...@ro...> - 2012-01-07 01:05:00
|
On January 6, 2012 3:48:55 PM Tim E. Real wrote: > On January 6, 2012 6:48:14 PM Dennis Schulmeister wrote: > > Hi all, > > > > Awakened by Florian's posts I checked out trunk yesterday and tried to > > compile it. Until now I've been using Muse 1.1 but some odd behavior > > made me try if version 2.0 would work for me. Indeed I've been very > > impressed with the new version and the new qt4 UI and Tim's MDI changes A (veteran) power user? Digging in the code? Nice to have your opinion. >... > If you find song type gets in the way, you can set it to 'NO' song type, > and then MusE will not attempt to quietly send out any initialization > values, and should not reset your patch selections even if rewound. Clarify: When init'ing controllers, it uses a 'fall back' system: If a user-set controller value is found in a part, use it. If not, look to the instrument itself - any 'default' value set there? If not - leave the controller alone, don't send anything, leave at last setting. This applies to all controllers including program. > > Another thing about that initialization routine is that it tends > to send out a lot of info at once - patches, controller values etc. It also sends out initialization SYSEXs depending on song type, It does this without respect to instrument ATM, we have to fix that. Some devices might not like it. I was reluctant to change song type to default GM and default instrument type to GM because of that. But it was probably for the better. >... Tim |
From: Tim E. R. <ter...@ro...> - 2012-01-07 03:38:15
|
On January 6, 2012 3:48:55 PM Tim E. Real wrote: > On January 6, 2012 6:48:14 PM Dennis Schulmeister wrote: >> ... > > * The CMake configuration doesn't check for all needed libraries. > > > > e.g. compilation fails is libso for OSC is missing > > This was reported by someone else, and fixed last week in SVN. > Should compile and work now without OSC. Jeepers! My old bad mistake. Non OSC was /still/ not fixed and non DSSI was broken. I wrapped dssihost.h with DSSI_SUPPORT, and osc.h with OSC_SUPPORT. Thus bypassing class definitions, and lo or dssi #includes, altogether. Then fixed some resulting errors in audiotrack.cpp Then searched for any further <lo...> or <dssi...> #includes and found and removed some weird usages of lo_types.h which were dependant on the HAVE_LASH macro in app.cpp, and one in main.cpp. I tested as much as I could, configuring for no LASH, OSC or DSSI, then OSC, then DSSI, then both, then with LASH. Each time I tried an old song with dssi synths and plugins. But if OSC and/or DSSI are not installed on your system, could you be so kind as to test again? Because I cannot easily remove OSC or DSSI. Completely bypassing the class definitions and hunting down #includes though is a pretty good indicator... Thanks. Tim. |
From: Florian J. <flo...@we...> - 2012-01-06 21:13:16
|
Am 06.01.2012 21:48, schrieb Tim E. Real: >> * There's a resize bug in the arranger. If you create a new song the >> contents of the arranger don't fill the arranger window. You have to >> minimize and maximize the arranger window in order to have the >> content take the full space. This only happens when a new song is >> created. When an existing song is opened the bug doesn't occur. >> > I've noticed that. Florian have you seen this? > > nope. might be related to my prefence to use MDI mode... will recheck on sunday >> * The new qt4 UI looks great but I never understood why Muse overrides >> the system theme of qt. IMHO this is evil and shouldn't be done. The >> widget theme should only be set outside all applications. No program >> should be more clever than the user about that. (This is one of the >> things which bugs me about Rosegarden, too: Its Franken-UI :-)) >> > Interesting. Never heard that suggestion before. Been like that forever. > I guess it's given the user somewhat of a choice in MusE ui outside of > the main theme so they don't have to change the main theme. > Robert, Florian, Orcan, Geoff, what do you think? > i think we should offer the possibility to change the theme (i like using the windows theme in muse, but gtk+ everywhere else), but muse indeed should not overwrite it without asking. greetings flo |
From: Robert J. <spa...@gm...> - 2012-01-07 14:57:43
|
Thanks for the comments and flowers Dennis :) >>> * The new qt4 UI looks great but I never understood why Muse overrides >>> the system theme of qt. IMHO this is evil and shouldn't be done. The >>> widget theme should only be set outside all applications. No program >>> should be more clever than the user about that. (This is one of the >>> things which bugs me about Rosegarden, too: Its Franken-UI :-)) >> Interesting. Never heard that suggestion before. Been like that forever. >> I guess it's given the user somewhat of a choice in MusE ui outside of >> the main theme so they don't have to change the main theme. >> Robert, Florian, Orcan, Geoff, what do you think? >> > i think we should offer the possibility to change the theme (i like > using the windows theme in muse, but gtk+ everywhere else), but muse > indeed should not overwrite it without asking. I've changed it now so there is an alternative in the dropbox to keep whatever is set systemwide, I hope that will suffice, let me know if it doesn't work right. Regards, Robert |
From: Dennis S. <mus...@wi...> - 2012-01-07 20:21:40
|
On Sat, 07 Jan 2012 14:27:02 -0500 "Tim E. Real" <ter...@ro...> wrote: > Er... what's in the patch was already done by me yesterday. > Maybe I neglected to mention: > The SVN branch you want is release_2_0. > Did you try the branch, or you tried it but it didn't work? Woops. I checked out trunk. Thanks, will try again. Yours sincerely, Dennis Schulmeister -- Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany Tel: +49 721/5978883 - Fax: +49 721/5978882 - Mob: +49 152/01994400 eMail: de...@wi... - web: there-is.no-ip.org <GnuPG KeyIDs: B8382C97, 01AD62DE> |
From: Florian J. <flo...@we...> - 2012-03-14 16:30:13
|
just to bring that bug report to life again: (btw: thanks, dennis ;) ) Am 06.01.2012 18:48, schrieb Dennis Schulmeister: > Hi all, > > Awakened by Florian's posts I checked out trunk yesterday and tried to > compile it. Until now I've been using Muse 1.1 but some odd behavior > made me try if version 2.0 would work for me. Indeed I've been very > impressed with the new version and the new qt4 UI and Tim's MDI changes > work great. At first I was concerned that the new version would have > poor performance because I'm using Muse as a pure MIDI sequencer on a > rather weak (but silent) machine. My concerns soon proved wrong and Muse > runs as good as ever. Well done and congratulations! The new version is > a winner for me. > > Here are some of my findings, though. All tests have been done on > XUbuntu 10.10. > > are the following bugs still an issue? > * The CMake configuration doesn't check for all needed libraries. > e.g. compilation fails is libso for OSC is missing > * Compilation also fails if DSSI support is disabled. Probably there > are some #IFDEFs missing somewhere > * I'm not sure about that anymore, but I think liblash headers are > also needed for compilation, even if LASH is disabled > * There's a resize bug in the arranger. If you create a new song the > contents of the arranger don't fill the arranger window. You have to > minimize and maximize the arranger window in order to have the > content take the full space. This only happens when a new song is > created. When an existing song is opened the bug doesn't occur. > the resize-bug in the arranger seems to be fixed, i cannot reproduce it. dennis? > * This one is particular nasty. It is also in Muse 1.1 but I couldn't > really find out what's going on. Inside midi.cpp we have the method > Audio::initDevices(). It seems to me that here the devices are > initialized with the first controller events of all tracks (?) and > that GM/XG/GS reset commands are triggered. However initialization > often doesn't occur, because this method isn't called. When you > open a song all devices are automatically initialized but this seems > to be done by any other method. I couldn't even find the method call > for that. When the transport location seeks to zero however the > method Audio::initDevices() is called. > > All my midi tracks have a part with needed initialization values > like program changes and so on. But when the song is played they are > omitted more often than not. My problem here is that I'm working with > hardware synthesizers exclusively but often I forget to switch them > to Multi/Receive Mode before loading a song. So I want to repeat the > initialization by starting playback or reloading the song. Most often > it just doesn't work and all I get are a lot of GrandPianos playing. > ---------------------------------------------- fixed stuff: > * The new qt4 UI looks great but I never understood why Muse overrides > the system theme of qt. IMHO this is evil and shouldn't be done. The > widget theme should only be set outside all applications. No program > should be more clever than the user about that. (This is one of the > things which bugs me about Rosegarden, too: Its Franken-UI :-)) > fixed by robert some time ago. > * If you make changes inside the global configuration dialog but don't > apply them (close the dialog with cancel) and then reopen the dialog > you still see your old values even though the configuration hasn't > changed. The reason here is that inside widgets/genset.cpp all calls > to updateSettings() have been commented. Also I would just call > updateSettings() inside the constructor instead of having the same > code twice. > just fixed that one. > BTW: Inside Audio::initDevices() is a German comment by Werner. Here is > the translation: > > // damit Midi-Devices, die mehrere Ports besitzen, wie z.B. > // das Korg NS5R, nicht mehrmals zwischen GM und XG/GS hin und > // hergeschaltet werden, wird zunächhst auf allen Ports GM > // initialisiert, und dann erst XG/GS > > // First all ports are initialized to GM and then are changed > // to XG/GS in order to prevent that devices with more than one > // port, e.g. Korg NS5R, toggle between GM and XG/GS several times. > fixed some time ago. > > Yours sincerely, > Dennis Schulmeister > > greetings flo |
From: Tim E. R. <ter...@ro...> - 2012-03-19 04:30:38
|
On March 14, 2012 5:30:01 PM Florian Jung wrote: > just to bring that bug report to life again: (btw: thanks, dennis ;) ) > > Am 06.01.2012 18:48, schrieb Dennis Schulmeister: > > * There's a resize bug in the arranger. If you create a new song the > > contents of the arranger don't fill the arranger window. You > > have to > > minimize and maximize the arranger window in order to have the > > content take the full space. This only happens when a new song > > is > > created. When an existing song is opened the bug doesn't occur. > > the resize-bug in the arranger seems to be fixed, i cannot reproduce it. > dennis? This bug's been there for a while. I just committed a fix to release_2_0 branch. - Song load: Arranger MDI window: Fixed size restoration. In TopWin::readStatus(), if mdisubwin is maximized, restore it before setting its position and height. Florian for some reason I had to do that. Here's the code: if(mdisubwin->isMaximized()) <<-- Added mdisubwin->showNormal(); <<-- mdisubwin->move(x, y); mdisubwin->resize(width, height); Look OK to you? In MusE::loadProjectFile1(), for templates you did: "maximize the arranger when in traditional SDI mode" so that the arranger opens maximized. But for some reason the maximized window didn't like the move() and resize() by themselves. Can anyone explain it? Also, why doesn't MusE seem to restore other maximized SDI windows upon reload? Store a song with maximized pianoroll and reload. it opens normally, not maximized. I thought that would be part of the stored Qt window settings ?? Cheers. Tim. |
From: Florian J. <flo...@we...> - 2012-03-19 13:46:28
|
Am 19.03.2012 05:29, schrieb Tim E. Real: > On March 14, 2012 5:30:01 PM Florian Jung wrote: > >> just to bring that bug report to life again: (btw: thanks, dennis ;) ) >> >> Am 06.01.2012 18:48, schrieb Dennis Schulmeister: >> >>> * There's a resize bug in the arranger. If you create a new song the >>> contents of the arranger don't fill the arranger window. You >>> have to >>> minimize and maximize the arranger window in order to have the >>> content take the full space. This only happens when a new song >>> is >>> created. When an existing song is opened the bug doesn't occur. >>> >> the resize-bug in the arranger seems to be fixed, i cannot reproduce it. >> dennis? >> > This bug's been there for a while. > > I just committed a fix to release_2_0 branch. > > - Song load: Arranger MDI window: Fixed size restoration. > In TopWin::readStatus(), if mdisubwin is maximized, restore it before > setting its position and height. > > Florian for some reason I had to do that. > Here's the code: > > if(mdisubwin->isMaximized()) <<-- Added > mdisubwin->showNormal(); <<-- > mdisubwin->move(x, y); > mdisubwin->resize(width, height); > > Look OK to you? > should be fine, will check. > In MusE::loadProjectFile1(), for templates you did: > "maximize the arranger when in traditional SDI mode" > so that the arranger opens maximized. > > But for some reason the maximized window didn't like the move() and resize() > by themselves. > > Can anyone explain it? > > Also, why doesn't MusE seem to restore other maximized SDI windows upon > reload? Store a song with maximized pianoroll and reload. it opens normally, > not maximized. > I thought that would be part of the stored Qt window settings ?? > qt has no way to determine whether a window is maximized, or just large. there is no standard interface to the WMs to do that. the doc says something like "it's impossible to find it out, and if you could hack something together, there will be some user using some windowmanager which breaks your expectations". greetings flo > Cheers. Tim. > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > |
From: Florian J. <flo...@we...> - 2012-03-20 18:57:01
|
is this still an issue? it looks release-critical, so i'm asking. and if it is, can you please give some steps to reproduce, with expected and actual result? thanks >> * This one is particular nasty. It is also in Muse 1.1 but I couldn't >> really find out what's going on. Inside midi.cpp we have the method >> Audio::initDevices(). It seems to me that here the devices are >> initialized with the first controller events of all tracks (?) and >> that GM/XG/GS reset commands are triggered. However initialization >> often doesn't occur, because this method isn't called. When you >> open a song all devices are automatically initialized but this seems >> to be done by any other method. I couldn't even find the method call >> for that. When the transport location seeks to zero however the >> method Audio::initDevices() is called. >> >> All my midi tracks have a part with needed initialization values >> like program changes and so on. But when the song is played they are >> omitted more often than not. My problem here is that I'm working with >> hardware synthesizers exclusively but often I forget to switch them >> to Multi/Receive Mode before loading a song. So I want to repeat the >> initialization by starting playback or reloading the song. Most often >> it just doesn't work and all I get are a lot of GrandPianos playing. >> >> > |
From: Robert J. <spa...@gm...> - 2012-03-21 20:18:34
|
Hi, indeed feels like it should be fixed... I think I was bitten by something similar with one of my projects. Two of the midi tracks just would not set their initial volume right. More recent saves of it started working though... Not sure how to go about verifying this... I think I have some old saves of this song though, so if it's the same issue perhaps I can reproduce it. Regards, Robert Den 20 mars 2012 19:56 skrev Florian Jung <flo...@we...>: > is this still an issue? it looks release-critical, so i'm asking. > and if it is, can you please give some steps to reproduce, with expected > and actual result? > thanks > >>> * This one is particular nasty. It is also in Muse 1.1 but I couldn't >>> really find out what's going on. Inside midi.cpp we have the method >>> Audio::initDevices(). It seems to me that here the devices are >>> initialized with the first controller events of all tracks (?) and >>> that GM/XG/GS reset commands are triggered. However initialization >>> often doesn't occur, because this method isn't called. When you >>> open a song all devices are automatically initialized but this seems >>> to be done by any other method. I couldn't even find the method call >>> for that. When the transport location seeks to zero however the >>> method Audio::initDevices() is called. >>> >>> All my midi tracks have a part with needed initialization values >>> like program changes and so on. But when the song is played they are >>> omitted more often than not. My problem here is that I'm working with >>> hardware synthesizers exclusively but often I forget to switch them >>> to Multi/Receive Mode before loading a song. So I want to repeat the >>> initialization by starting playback or reloading the song. Most often >>> it just doesn't work and all I get are a lot of GrandPianos playing. >>> >>> >> > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer |
From: Florian J. <flo...@we...> - 2012-03-22 15:54:32
|
Am 21.03.2012 21:18, schrieb Robert Jonsson: > Hi, > > indeed feels like it should be fixed... > I think I was bitten by something similar with one of my projects. Two > of the midi tracks just would not set their initial volume right. More > recent saves of it started working though... > Not sure how to go about verifying this... > I think I have some old saves of this song though, so if it's the same > issue perhaps I can reproduce it. > please try to do so. greetings flo > Regards, > Robert > > Den 20 mars 2012 19:56 skrev Florian Jung<flo...@we...>: > >> is this still an issue? it looks release-critical, so i'm asking. >> and if it is, can you please give some steps to reproduce, with expected >> and actual result? >> thanks >> >> >>>> * This one is particular nasty. It is also in Muse 1.1 but I couldn't >>>> really find out what's going on. Inside midi.cpp we have the method >>>> Audio::initDevices(). It seems to me that here the devices are >>>> initialized with the first controller events of all tracks (?) and >>>> that GM/XG/GS reset commands are triggered. However initialization >>>> often doesn't occur, because this method isn't called. When you >>>> open a song all devices are automatically initialized but this seems >>>> to be done by any other method. I couldn't even find the method call >>>> for that. When the transport location seeks to zero however the >>>> method Audio::initDevices() is called. >>>> >>>> All my midi tracks have a part with needed initialization values >>>> like program changes and so on. But when the song is played they are >>>> omitted more often than not. My problem here is that I'm working with >>>> hardware synthesizers exclusively but often I forget to switch them >>>> to Multi/Receive Mode before loading a song. So I want to repeat the >>>> initialization by starting playback or reloading the song. Most often >>>> it just doesn't work and all I get are a lot of GrandPianos playing. >>>> >>>> >>>> >>> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> Lmuse-developer mailing list >> Lmu...@li... >> https://lists.sourceforge.net/lists/listinfo/lmuse-developer >> > |