MusE - Linux Music Editor

Hi Florian,

2011/5/29 Florian Jung <florian.a.jung@...>:
> Hi
>
> i find the fact, that if you resize a clones part, the other clone
> doesn't get resized, pretty unintuitive; i find it even more unintuitive
> that then there are "hidden" events, which are stored in the eventlist,
> but not shown (except in my score editor, bug xD).
>
> and i find it really strange that if you resize a non-clones track to a
> too-small size, the "too-much" events get erased.
> if you resize a clone, they get not erased but only hidden
>
>
> i think, we should stick to one way: and i think we should stick to the
> "also resize part-clones"-way
>
> this is simply much more intuitive for the user, as he expects a "clone"
> behave, yeah, like a clone, and not like only a part with the same
> eventlist; also, hidden stuff isn't good at all, as most users don't
> know about this, or simply don't think about it, and then get confused,
> or huge files with unneccessary events.
> or glitches if they extend a part, expect it be empty, but it isn't
>
>
> in contrast, when resizing a part also resizes its clones and erases
> events, this may be a thing worth to note; i think, when doing this, a
> dialog should inform the user about this changed behaviour; of course,
> there is a "don't show again"-checkbox.
>
> changing the behaviour involves a small change to loading files, as we
> need to detect now-impossible parts (clones with different length), and
> we need to split them (into the cloned beginning which is the same, and
> then the extended sub-part of the longer). this will also involve some
> warning, that there may be a loss of hidden events.
>
>
> i know that this is really new behaviour. but we should not argue like
> "this was always the way we've done it, we'll do it still that way today!".
>
>
> i'd change this, if you consider this a good idea.
>
> please discuss (or simply agree ;) )

I use clones quite a lot actually, for drums mainly, and what you
write above has kind of already been true for me in spirit so I forsee
no big problems. My clones are always the same size so I think this
change will be good.

There is the issue with old songs if anyone has taken advantage of
this fact. I see you are suggesting to split the parts into a clone
bit and an "extended bit" ?
May I offer that we do the reverse and only the longest clones, e.g.
the "full clones" are kept as clones the others are converted to
normal parts (with a dialog warning), with the extra events removed ?

Regards,
Robert

On Sun, May 29, 2011 at 5:36 AM, Florian Jung <florian.a.jung@...> wrote:

> Hi
>
> i find the fact, that if you resize a clones part, the other clone
> doesn't get resized, pretty unintuitive; i find it even more unintuitive
> that then there are "hidden" events, which are stored in the eventlist,
> but not shown (except in my score editor, bug xD).
>
>

I too find this unintuitive and would like some of these changes.

Am 28.05.2011 09:59, schrieb Tim E. Real:
> On May 28, 2011 12:07:31 am Geoff Beasley wrote:
>    
>> In file included from /root/CODE/lmuse/trunk/muse2/muse/functions.h:16:0,
>> from /root/CODE/lmuse/trunk/muse2/muse/midiedit/drumedit.cpp:46:
>> /root/CODE/lmuse/trunk/muse2/muse/widgets/function_dialogs/transpose.h:17:1
>> : error: expected class-name before ‘{’ token
>> make[2]: *** [muse/midiedit/CMakeFiles/midiedit.dir/drumedit.o] Error 1
>> make[1]: *** [muse/midiedit/CMakeFiles/midiedit.dir/all] Error 2
>> make: *** [all] Error 2
>>
>>
>> cheers
>>
>> g.
>>      
> I got that error too. It's cmake leftover cruft from changes.
>
> Wipe out the cmake directory for /widgets in the build directory.
>
> Or just rebuild the whole thing.
>    
where "rebuild" does _not_ mean "make clean; make", but really deleting 
the whole build directory: "rm -rf build/"
flo
> Tim.
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Lmuse-developer mailing list
> Lmuse-developer@...
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer
>
>

I had that problem, too.

Tim is right, 
removing the buid dir and making a fresh cmake should fix the problem!
Yours,
	Willy

Am Samstag 28 Mai 2011, 11:23:10 schrieb Florian Jung:
> Am 28.05.2011 09:59, schrieb Tim E. Real:
> > On May 28, 2011 12:07:31 am Geoff Beasley wrote:
> >    
> >> In file included from /root/CODE/lmuse/trunk/muse2/muse/functions.h:16:0,
> >> from /root/CODE/lmuse/trunk/muse2/muse/midiedit/drumedit.cpp:46:
> >> /root/CODE/lmuse/trunk/muse2/muse/widgets/function_dialogs/transpose.h:17:1
> >> : error: expected class-name before ‘{’ token
> >> make[2]: *** [muse/midiedit/CMakeFiles/midiedit.dir/drumedit.o] Error 1
> >> make[1]: *** [muse/midiedit/CMakeFiles/midiedit.dir/all] Error 2
> >> make: *** [all] Error 2
> >>
> >>
> >> cheers
> >>
> >> g.
> >>      
> > I got that error too. It's cmake leftover cruft from changes.
> >
> > Wipe out the cmake directory for /widgets in the build directory.
> >
> > Or just rebuild the whole thing.
> >    
> where "rebuild" does _not_ mean "make clean; make", but really deleting 
> the whole build directory: "rm -rf build/"
> flo
> > Tim.
> >
> > ------------------------------------------------------------------------------
> > vRanger cuts backup time in half-while increasing security.
> > With the market-leading solution for virtual backup and recovery,
> > you get blazing-fast, flexible, and affordable data protection.
> > Download your free trial now.
> > http://p.sf.net/sfu/quest-d2dcopy1
> > _______________________________________________
> > Lmuse-developer mailing list
> > Lmuse-developer@...
> > https://lists.sourceforge.net/lists/listinfo/lmuse-developer
> >
> >    
> 
> 
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery, 
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now. 
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Lmuse-developer mailing list
> Lmuse-developer@...
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer
>

Thanks everyone ;)

i'll do that now

g

Am 27.05.2011 19:27, schrieb Robert Jonsson:
> Ok, sounds interesting to test then. Since it works for undo I think
> we should give it a serious test.
> I have too wondered how to check or work around such timing issues.
>    
well, that's what mutexes are for ;)

i'm still not fully convinced that mutexes are bad, but i've never done 
realtime-audio-stuff.
i've written a soft synthesizer which communicates with the jack thread 
via a mutex-locked communication structure, (however, communication is 
seldom neccessary here), and i never could lead back crackles to the 
mutexes (but to my slow cpu; i had 100% usage ;) )

i don't want to propose something which breaks muse afterwards, but i 
want to ask you to take this into serious consideration; but, i also 
think we should first investigate where these segfaults really come 
from; i only assumed!

> I just wanted to add that if this is the case, that the processing of
> operations in the sequencer/audio thread causes crashes due to timing,
> it negates the whole idea of processing it there. Need to get to the
> bottom of this.
>    
well, it was there before that undo and redo is processed inside the 
realtime thread.
why should the audio thread _crash_ because of timing issues? it should 
maybe crackle, if at all, but never crash?
i think it's a good idea to put processing into the realtime thread:
first, the single operations were already there; for such single 
operations, my operation groups change nothing.
second, if someone does "large operations", that is, quantizing etc., 
which lock the seq thread for more than 10 milliseconds, i think muse is 
allowed to crackle then. i mean, who performs such operation realtime?

i think, we must find a compromise between good realtime and good 
non-realtime performance; atm, realtime is extremely good, but 
non-realtime is really, really crappy; my solution pushes non-realtime 
to "pretty good", and realtime to "overall good, but sometimes there may 
be crackles". this "sometimes" however should never occur when there's a 
sane user.



>> i also noticed that first track1 is loaded, then the score window
>> (containing tracks 1 AND 2) is opened, and THEN tracj2 is loaded. wtf?
>>      
> In which order are they stored in the song file? We should be able to
> influence this.
>    
will check that in the next time



> About beta status. You are probably correct we are still a bit away
> from a release, still that is the goal.
>    
of course it's the goal!
> The unstableness of loading from commandline and similar, possibly
> timing, issues must be minimized.
>    
yes. if that works, we could make it stable, with a hint that the score 
editor is still beta.




greetings
flo

On May 28, 2011 05:22:08 am Florian Jung wrote:
> Am 27.05.2011 23:30, schrieb Tim E. Real:
> > On May 27, 2011 01:07:03 pm Florian Jung wrote:
> >> Hi
> >>
> >> in case you ever want to declare muse as stable, _please_ check the bugs
> >> and todo section in scoreeditor.cpp
> >>
> >> i'm writing this because i just tried to really USE muse (till now, i
> >> only developed); most things go really well, but there are reproducible
> >> and non-reproducible segfaults; most are related to my score editor, but
> >> others aren't (!)
> >
> > As I said, got to be highly aware of the whole picture of MusE. It's
> > huge. Make sure you try it once in a while, will ya? Audio too, eh :)
> >
> > ----
> > To this I would like to add some important new *crashes*:
> > Some of the softsynths are crashing because of the switch to default
> >   'GM' song type.
> > Remember way back when I argued with Geoff that doing this might cause
> >   some instruments to freak out? Well, it's happening here with
> > softsynths. VAM synth is the worst offender - it blindly treats ALL
> > incoming sysexes as midistate local initialization data.
> > With 'GM' song type, MusE sends a Gm-On sysex to all instruments,
> > including VAM, and VAM *crashes* because it thinks that this is midistate
> > init data.
>
> well, honestly, this really sucks then ;)
> and even if vam _crashes_ then (and is not only confused due to
> unexpected data), this is really bad programming style. a program (or
> part of it) should always can process unexpected stuff without crashing
> (for example my score editor: most parts output an error (this should
> never happen...) if something unexpected occurs, and try to ignore this,
> resulting in incorrect or no rendering, loss of functions or whatever.
> but ideally no crashes)
>
> > So right now I am working on wrapping all the saved softsynth midistate
> > sysex data into the defined 'Manufacturer Code' 0x7C "MusE Softsynth",
> > with a consistent secondary ID byte and command byte maybe some other
> > stuff, maybe padding.
> > This will provide consistency and protect all the synths from unknown
> > sysexes.
>
> would simply not using sysexes defined in some standard also help? i
> mean, if a synth uses a well known sysex for its own purposes, that
> almost certainly cannot work.

Well I did warn everyone that this would happen.
My concern at the time was actually external HW freaking out over
 receiving these Gm-on or Gs-on or Xg-on sysexes from MusE.
Turns out our own softsynths didn't like it.

You see, technically I gather long ago a song with a MusE softsynth 
 was not /supposed/ to be a GM or GS or XG song. 

Look, the history is reeeal old. Likely nobody conceived it would go this far.

That said, I admit I was surprised to find that of all softsynths, only Fluid 
 properly wraps its *own* custom sysexes in a MusE M.F. ID and synth ID. 
Even with 'NO' song type some of the other synths might crash if fed 
 certain /external/ sysex. That's why I'm correcting this. 
Gimme standard sysex headers - at least a M.F. ID please !

Info Briefing:
----------------
Each MESS synth's gui can send custom sysexes back to the synth itself 
 via the normal event methods, as if it came from outside from song or 
 ext HW (and very well might). Other synths (dssi) use other methods.
Example: Selecting a soundfont in the Fluid gui informs the synth this way.
A MESS synth can have a sysex handler, while other synths (dssi) handle 
 them in processing. Here it MUST recognize or reject the sysex.

There is a special sysex called "midistate" used for storing and reloading the 
 /complete/ state in the song. MESS synths can implement ::getInitData(). 
DSSI synths use string/float param lists instead of a "midistate" sysex, but
 ATM our dssi vst synth code /can/ save some data in the "midistate" sysex.

And then there are of course all the other 'standard' external sysexes
 that a synth *might* want to deal with (or reject). This includes selecting
 a GM or GS or XG song type which sends out those sysexes. Fluid uses this.

Thus, I believe, to sort out all of these sysexes is going to require 
 standardization by adding standard headers to all of the sysex used in MusE.
That includes Deicsonze which uses a whackload of custom sysexes!

Was majorly trying last night. Verrrrrry tricky from all the angles involved. 
Will post when more info. 
I actually have a fix for VAM (copy the only slightly less dangerous sysex 
 handler from Organ). But naaah, want do this right.

Cheers. Tim.

Hi Willy,

I tried this too now and I fear ZynAdd (or MusE) still causes some
memory corruption.
I get the following backtrace now with your ZynAdd fix.

Core was generated by `muse2'.
Program terminated with signal 11, Segmentation fault.
#0  0x019b6c20 in QFont::operator==(QFont const&) const () from
/usr/lib/libQtGui.so.4
(gdb) bt
#0  0x019b6c20 in QFont::operator==(QFont const&) const () from
/usr/lib/libQtGui.so.4
#1  0x019b95cc in QFont::resolve(QFont const&) const () from
/usr/lib/libQtGui.so.4
#2  0x017d15a7 in QWidget::setFont(QFont const&) () from /usr/lib/libQtGui.so.4
#3  0x009323aa in MidiTrackInfo::MidiTrackInfo(QWidget*, Track*) ()
from /usr/local/lib/muse-2.0beta/modules/libmuse_widgets.so
#4  0x0044f43b in Arranger::genTrackInfo(QWidget*) () from
/usr/local/lib/muse-2.0beta/modules/libmuse_arranger.so
#5  0x0044cd8d in Arranger::Arranger(QMainWindow*, char const*) ()
from /usr/local/lib/muse-2.0beta/modules/libmuse_arranger.so
#6  0x00d802d7 in MusE::MusE(int, char**) () from
/usr/local/lib/muse-2.0beta/modules/libmuse_core.so
#7  0x0804d93a in main ()

Regards,
Robert

2011/5/28 WillyFoobar <WillyFoobar@...>:
> Hello guys,
>
> Ups the last try was blocked, as the mail out-rules size limitations,
>
> Yours,
>        Willy
>
> ----------  Weitergeleitete Nachricht  ----------
>
> Betreff: mtrackinfo.cpp: missing config.fonts[2]
> Datum: Samstag 28 Mai 2011, 15:19:52
> Von: Willylmuse-developer@... <WillyFoobar@...>
> An:
>
> Hello guys,
>
>
> after the ZynAddSubFX issue is done,
> I still am try to get muse2 up and running.
>
> I am running into another problem, now.
>
> However, I get the next runtime error at muse/widgets/mtrackinfo.cpp
> It looks like the config.fonts array contains no valid fonts!
>
> Yours,
>        Willy
>
> P.S.: might this be related to missing /dev/rtc permissions???
>
>
>
>
>
> //---------------------------------------------------------This is the code
> //   midiTrackInfo
> //---------------------------------------------------------
>
> MidiTrackInfo::MidiTrackInfo(QWidget* parent, Track* sel_track) : QWidget(parent)
> {
>  setupUi(this);
>  _midiDetect = false;
>
>  selected = sel_track;
>
>  // Since program covers 3 controls at once, it is in 'midi controller' units rather than 'gui control' units.
>  //program  = -1;
>  program  = CTRL_VAL_UNKNOWN;
>  pan      = -65;
>  volume   = -1;
>
>  setFont(config.fonts[2]);     // <<----Crashing here
>
> //..
> }
>
> //----------------------------------the muse's xterm output shows this:
>
> PianoRoll: unknown tag <quantLimit> at line 207
> PianoRoll: unknown tag <quantLen> at line 208
> PianoRoll: unknown tag <to> at line 209
> Config file might be corrupted. Unknown shortcut: midi_over_quant
> Config file might be corrupted. Unknown shortcut: midi_quant_noteon
> Config file might be corrupted. Unknown shortcut: midi_quant_noteoff
> Config file might be corrupted. Unknown shortcut: midi_quant_iterative
> Config file might be corrupted. Unknown shortcut: config_quant
> Denormal protection enabled.
> Jack: JackClient::SetupDriverSync driver sem in flush mode
> Jack: JackPosixSemaphore::Connect jack_sem.500_default_MusE
> Jack: Already connected name = MusE
> Jack: Clock source : system clock via clock_gettime
> Jack: JackLibClient::Open name = MusE refnum = 3
> Jack: jack_set_graph_order_callback ext_client 820d220 client 820d220
> Jack: SetGraphOrderCallback
> Jack: jack_set_thread_init_callback ext_client 820d220 client 820d220
> Trying RTC timer...
> fatal error: open /dev/rtc failed: Keine Berechtigung
> 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 = 60
>
>
> //////////////---------------------------------------------------------------
> The  local vardump is attached
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Lmuse-developer mailing list
> Lmuse-developer@...
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer
>
>

Dear Flo,
Hello guys,


per principle, you are right.
in C++, No "scope token" is equal to "scope token" private:

I don't know exactly why,
but the entry Q_OBJECT, that does all the declarations for signals, slots and all of the other Qt stuff
relies on the fact, that Q_OBJECT is the first "entry" in a QT-Class.


I had an old Qt Book, where this was documented,
But I cannot find the reference at teh moment!


Please have a look in 
	http://doc.qt.nokia.com/4.7.1/moc.html


At the current Qt Version 4.7, using "private:" before Q_OBJECT  might work well!
But it cannot be guaranteed for future Qt releases.

So we should use Q_OBJECT without the prior "private:" token as stated below!
(See line 3 of sample MyClass)

Hope this clears the whole stuff!

Yours,
	Willy



Using the Meta-Object Compiler (moc)
The Meta-Object Compiler, moc, is the program that handles Qt's C++ extensions.
The moc tool reads a C++ header file. If it finds one or more class declarations that contain the Q_OBJECT macro, it produces a C++ source file containing the meta-object code for those classes. Among other things, meta-object code is required for the signals and slots mechanism, the run-time type information, and the dynamic property system.
The C++ source file generated by moc must be compiled and linked with the implementation of the class.
If you use qmake to create your makefiles, build rules will be included that call the moc when required, so you will not need to use the moc directly. For more background information on moc, see Why Doesn't Qt Use Templates for Signals and Slots?
Usage
moc is typically used with an input file containing class declarations like this:
 class MyClass : public QObject
 {
     Q_OBJECT

 public:
     MyClass(QObject *parent = 0);
     ~MyClass();

 signals:
     void mySignal();

 public slots:
     void mySlot();
 };

Am Samstag 28 Mai 2011, 11:06:04 schrieb Florian Jung:
> Am 27.05.2011 19:17, schrieb WillyFoobar:
> >
> > nevertheless the "private:" in the line 15 of transpose.
> >
> > h (right before Q_OBJECT) should be dropped!
> >
> why should it?
> i know that c++ defaults to "private:" if i specify nothing; but i find 
> it more clear when there still is a "private:"
> 
> thanks for the patch, btw ;)
> 
> greetings
> flo
>

Am 28.05.2011 13:54, schrieb WillyFoobar:
>
> Dear Flo,
>
> Hello guys,
>
>
>
> per principle, you are right.
>
> in C++, No "scope token" is equal to "scope token" private:
>
>
> I don't know exactly why,
>
> but the entry Q_OBJECT, that does all the declarations for signals, 
> slots and all of the other Qt stuff
>
> relies on the fact, that Q_OBJECT is the first "entry" in a QT-Class.
>
>
>
> I had an old Qt Book, where this was documented,
>
> But I cannot find the reference at teh moment!
>
>
>
> Please have a look in
>
> http://doc.qt.nokia.com/4.7.1/moc.html
>
>
>
> At the current Qt Version 4.7, using "private:" before Q_OBJECT might 
> work well!
>
> But it cannot be guaranteed for future Qt releases.
>
>
> So we should use Q_OBJECT without the prior "private:" token as stated 
> below!
>
> (See line 3 of sample MyClass)
>
>
> Hope this clears the whole stuff!
>
>
> Yours,
>
> Willy
>

uh, that was new to me (in fact, i have had no idea about qt before i 
came to muse ;) )

so, is it correct that Q_OBJECT has to be the first statement after the 
opening bracket of a class then?

greetings
flo

Hi Flo,

> uh, that was new to me (in fact, i have had no idea about qt before i 
> came to muse ;) )
> 
> so, is it correct that Q_OBJECT has to be the first statement after the 
> opening bracket of a class then?
> 
> greetings
> flo
> 

Yes,
you got it right!

On Thu, May 26, 2011 at 4:28 PM, WillyFoobar wrote:
> 2.) Q_OBJECT
>        // should be the first entry in  new Qt-inherited class.
>        //some Q_OBJECTS ware missing
>        /
>

Hi Willy,
As far as I remember, you do not need to use Q_OBJECT on any
Qt-inherited class. You need it only if you are using Qt's signal/slot
framework. No?

Orcan

Wonderful!

Could you send a patch here?
I want to try zyn add again :)

Regards,
Robert


2011/5/28 WillyFoobar <WillyFoobar@...>:
> Hello guys,
>
> I was able to fix the /usr/lib/dssi/zynaddsubfx.so problem.
>
> INSIDE the ZynAddSubFX-2.4.1 tarball
>
> I was able to compile it by the usual
>
> ZynAddSubFX-2.4.1/src> make
>
> but the so file was not not copied during
>
> ZynAddSubFX-2.4.1/build> make install
>
> So I solved it for the moment
>
> by copying it manually to
>
> /usr/lib/dssi/zynaddsubfx.so
>
> So the problem is solved for now.
>
> I have to get in touch with the ZynAddSubFX team,
>
> to fix that finally
>
> Yours,
>
> Willy
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Lmuse-developer mailing list
> Lmuse-developer@...
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer
>
>

Hello Robert,

As the changes are so tiny,
I am sending you the changes, not as a diff,
I send you the changed coda as plain text!

in the file:

	ZynAddSubFX-2.4.1/src/Misc/Config.cpp

do this changes

This is the old code:::::::::::::::::::::::::::::
Config::Config()
{
}
void Config::init()
{
    maxstringsize = MAX_STRING_SIZE; //for ui
//..............................................................

Replace it with:::::::::::::::::::::::::::::::::::::::::::::
Config::Config()
        :maxstringsize(0)
{
        init();
}
void Config::init()
{
    if(maxstringsize!=0) return;

    maxstringsize = MAX_STRING_SIZE; //for ui
//..............................................................


Yours,
	Willy

P.S.: inside the ZynAddSubFX $>make  peration
there is created the required shared object in 

	ZynAddSubFX -2.4.1/src/zynaddsubfx.so

the 
	$>sudo make install
operation is lacking to install it in:

	/usr/lib/dssi/zynaddsubfx.so

My "solution" was to copy it by hand  into the target dir!
Perhaps Am I missing a special (hidden) make optioon???





Am Samstag 28 Mai 2011, 15:12:57 schrieb Robert Jonsson:
> Wonderful!
> 
> Could you send a patch here?
> I want to try zyn add again :)
> 
> Regards,
> Robert
> 
> 
> 2011/5/28 WillyFoobar <WillyFoobar@...>:
> > Hello guys,
> >
> > I was able to fix the /usr/lib/dssi/zynaddsubfx.so problem.
> >
> > INSIDE the ZynAddSubFX-2.4.1 tarball
> >
> > I was able to compile it by the usual
> >
> > ZynAddSubFX-2.4.1/src> make
> >
> > but the so file was not not copied during
> >
> > ZynAddSubFX-2.4.1/build> make install
> >
> > So I solved it for the moment
> >
> > by copying it manually to
> >
> > /usr/lib/dssi/zynaddsubfx.so
> >
> > So the problem is solved for now.
> >
> > I have to get in touch with the ZynAddSubFX team,
> >
> > to fix that finally
> >
> > Yours,
> >
> > Willy
> >
> > ------------------------------------------------------------------------------
> > vRanger cuts backup time in half-while increasing security.
> > With the market-leading solution for virtual backup and recovery,
> > you get blazing-fast, flexible, and affordable data protection.
> > Download your free trial now.
> > http://p.sf.net/sfu/quest-d2dcopy1
> > _______________________________________________
> > Lmuse-developer mailing list
> > Lmuse-developer@...
> > https://lists.sourceforge.net/lists/listinfo/lmuse-developer
> >
> >
>

Am 28.05.2011 13:44, schrieb Robert Jonsson:
> It should resize and move and any column not explicitly found a song
> file should be appended last instead of first, I hope, seems to work.
>    
seems to work mostly, but when i change the order of the columns, and 
save the file:
if i run "muse2 myfile.med", the order is correctly restored
if i however run muse, then do file->open->myfile.med, the order seems 
to be not restored (instead, it still uses the order from default.med, 
or whatever was there before)


> Now I'm gonna make myself some coffee, watch a movie and feel sorry
> for myself for having a cold ;)
>    
poor robert
get well soon ;)

> Regards,
> Robert
>    
greetings
flo

2011/5/28 Florian Jung <florian.a.jung@...>:
> Am 28.05.2011 13:44, schrieb Robert Jonsson:
>> It should resize and move and any column not explicitly found a song
>> file should be appended last instead of first, I hope, seems to work.
>>
> seems to work mostly, but when i change the order of the columns, and
> save the file:
> if i run "muse2 myfile.med", the order is correctly restored
> if i however run muse, then do file->open->myfile.med, the order seems
> to be not restored (instead, it still uses the order from default.med,
> or whatever was there before)

Ah, dammit, I had a hunch... Will look at it after my "siesta".

Regards,
Robert