From: Florian J. <flo...@we...> - 2011-11-24 10:07:51
|
Am 24.11.2011 08:09, schrieb Tim E. Real: > Florian, can you review this at songfile.cpp: MusE::read() : > > readConfiguration(xml, false, false /* do NOT read global settings */); > > I changed it to 'true' to read song configuration, and committed. > > Not sure where you were headed there, but MusE songs contain > a configuration section which must be loaded. > > I tried it with some songs and it seems to work OK. > i think that this is NOT okay. i'm not exactly sure, but i think i made that change to protect the global stuff (like window configuration, etc) be overwritten by a songfile. i think muse's configuration storing system is broken by design, and my fix was as well probably. the problem is that some (but not all ;) ) _global_ config settings get stored in the songfile, but in the global configuration as well. they SHOULD be only loaded from the global config. apart from that they should never get into the songfile at all, when a song contains such global config options, these should be NOT read. otherwise robert's configuration (which fits him) will be destroyed as soon as i email robert one of my .med files and he opens it (because then partially his config will be overwritten by MINE, which is (but should not be) in the songfile). get the problem? my approach to fixing this was to have that doReadGlobalConfig parameter ignore all global config variables, when readConfig is called from some song-file-loading-routine. i had to group between "stuff which should be read from a songfile as well" and "stuff which shouldn't". i probably made the one or other mistake in there. tim, i reverted your fix. please look at conf.cpp, line 555 and later. in line 633, there's a comment "Global and/or per-song config stuff ends here" and one "Global config stuff begins here". the mixer stuff is in the second part. note in line 628, there is checked "tag was neither "sequencer" nor "midiInputDevice" nor.... AND we should not overwrite the global stuff? then skip this tag and proceed with the next one." i think your mixer settings are skipped by (my) mistake, so you only need to move the corresponding else if (foo) {} branch from the second up into the first part, so that it IS read when loading a song. nothing more does your fix do as well, just with unwanted side effects. probably the same with similar problems greetings flo > We still have some arranger restoring issues, though, and that darn > MarkerView is still misbehaving (phht, will it ever be fixed?) > what exactly is the problem? (expected behaviour, actual behaviour?) how to reproduce? what is MarkerView supposed to do in the code? is there some custom loading/storing routine only for MarkerView which doesn't work, or is it done like in any other TopWin (that is, with TopWin::read/writeconfig called from MarkerView::read/write and some additional readings/writings; same for state)? greetings flo > I'll take a look at that one. > > Tim. > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > |