muse3 crashes when adding more than one midi track.

MusE is a DAW for Linux with both MIDI and Audio editing. https://muse-sequencer.github.io

Moderators: MattKingUSA, khz, spamatica

alex stone
Established Member
Posts: 350
Joined: Fri Jun 06, 2008 7:39 am
Has thanked: 61 times
Been thanked: 53 times

muse3 crashes when adding more than one midi track.

Post by alex stone »

Hello all. Tried building muse3 from git, and that seemed to go ok eventually.

I have a challenge though with adding midi tracks. I can load one, but if i try to load a second track muse crashes hard, every time.

Before i investigate this further, is this a known issue that's already being worked on?
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: muse3 crashes when adding more than one midi track.

Post by Tim E. Real »

Hi, that's a strange one.
Such a fundamental thing adding a midi track, I don't think we've had that complaint before.
I've not noticed anything with the git, but it's possible we did something that opened a crack.

One thing I can think of, just off the top of my head:
Mind your midi devices: Check if the list of midi devices being used in the Midi Configuration dialog
includes any named midi 'Through (or thru)'.
If you see any ALSA midi thru devices listed, ensure they are effectively disabled - that the two
little green LEDs for allowing input/output on the device are not illuminated.
If you see any JACK midi thru devices listed, remove them or ensure they are not connected
at all to any real Jack ports and are not used in the song, or disable them with the two green LEDs.

What happens is that an infinite recursion can occur. The instant you add a new midi track,
MusE wants to send a few initializing midi messages to the device (mode sysex and a few controllers).
If that device happens to be a 'thru' device, the message comes right back again to the device
and is then sent out again and returns again and again, ad infinitum.

I have seen that, it does happen. MusE will crash as it is flooded with this infinite recursion condition.

ALSA fortunately allows us to know that a device is a thru device and thus we are able to
automatically disable them in the device list right away, and push them to the bottom of the list,
and if the user really wants them they can enable them. However with Jack it is not so easy to
tell that the device is a thru, so we are forced to just list them as is, enabled.

Hope that helps. If not, try to post some debug info or a dump and we'll take a look!

Tim.
alex stone
Established Member
Posts: 350
Joined: Fri Jun 06, 2008 7:39 am
Has thanked: 61 times
Been thanked: 53 times

Re: muse3 crashes when adding more than one midi track.

Post by alex stone »

Tim, a follow up to this challenge.

I completely removed all reference to Muse3 (and Muse) and rebuilt and installed from git.

The problem seemed to be building from a git source that wasn't on my machine. (I'd pulled git onto a removable hard drive, and attempted to build from there. My audio boxes are not connected to the interlink) When i copied the git folder to my machine proper, then Muse3 built "more" correctly as far as i can tell, and i can add as many tracks as i want. Maybe something to do with direct paths? Who knows. The problem has gone.

There is another challenge that reared its head when i initially opened muse3 and started testing with linuxsampler.lv2.

I can build and save a preset using Fantasia as a front end. But when i close and open Muse3 again, and attempt to load the preset, it fails, and tells me it can't find the gig files. (No such directory)

When i examine the preset folder, it shows the symlinks that were created as paths to the gig files elsewhere on my machine, so that bit seems ok. Any clues why this might be happening? I'm using UbuntuStudio with it's default xfce environment for this test.

Alex.
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: muse3 crashes when adding more than one midi track.

Post by Tim E. Real »

Hi. Well I finally got some sound out of the LS LV2 plugin in MusE, for the very first time I think.
For years, I had assumed the LV2 plugin would naturally gain some controls and a GUI.
But that's not how it is supposed to be used.

Sooo.... Lacking Fantasia, I used QSampler and created a new MusE preset in that little context popup
"Presets > Preset actions". I assume that is what you must be talking about, Alex? Because...
Yep, I think i definitely see a problem.
A soon as I simply re-select my new preset, bam! QSampler says ERR, and the previously
loaded GIG filename which was just fine in the channel properties box, now says some sort of
nonsense. In my case it says:
/file:/home/me/.lv2/LinuxSampler_LV2_MyPreset1.lv2/Tic Tok Men Moogdrums1.gig
It should say:
/home/me/moogdrums-giga/Tic Tok Men Moogdrums1.gig
Yikes!

Can't promise when it'll be fixed (TM), but at least I think there's something wrong.
Please file this on the bug tracker.
It'll help track the progress. Mention that it was confirmed, eh?

Thanks!
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: muse3 crashes when adding more than one midi track.

Post by Tim E. Real »

Strange, possibly was a red herring, possibly some other problem is happening.
It turns out:
/file:/home/me/.lv2/LinuxSampler_LV2_MyPreset1.lv2/Tic Tok Men Moogdrums1.gig
is actually a (valid) link to the true GIG file:
/home/me/moogdrums-giga/Tic Tok Men Moogdrums1.gig
To confirm a suspicion I had, I manually pointed QSampler to that link file,
even though it was already showing in QSampler's channel setup Filename box.
It worked. So we know the link itself works.
Hm, maybe something else happening...
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: muse3 crashes when adding more than one midi track.

Post by Tim E. Real »

Hey there! Still with us? I've got news!

1: Yep, that filename being passed to linuxsampler is wrong:
/file:/home/me/.lv2/LinuxSampler_LV2_MyPreset1.lv2/Tic Tok Men Moogdrums1.gig
The "/file:/" part should not be there. Actually the URI being passed to LS is "file:///home..."
but those 3 slashes get messed up by the time LS stores it.

2: Ardour does the same thing. I tested presets using QSampler and sure enough, exact same problem.
So it is definitely not MusE's fault.

3: A patch for lilv source code. This took me a long freakin' time to fix!
It's insane traversing all that code in three different domains: MusE, LV2, and LS.

Anyone reading this, please test it if you can.
I'd like independent confirmation before I submit a patch for review to LV2.

I tested the fix with MusE by using QSampler to load different gig files and
creating presets in MusE for each one, then stress-tested by switching among them.
Please stress-test with different gigs and presets. We want to catch any memory errors and so on.

It's kinda cool. Now QSampler shows the proper, absolute gig filename - not the messed up
URI link to the filename. I can select among different gigs that way.
Interesting, it appears LS itself takes the link we pass it and turns it into an absolute filename.

But I must say again, I expected that LV2 plugin to gain a UI and some controls by now
in its history. Is it not possible to just put all of QSampler or Fantasia inside the actual LV2 plugin?
So I can see better now, why built-in host support for LS is so crucial.
We could sure use something in MusE to, at the very least, load the filenames and set up LS channels.
Similar to our FluidSynth MESS plugin having the luxury of working so closely with the file
and being able to garner a lot of information from it, much more than any other plugin
architecture we support.

One last observation:
I believe we are missing two items in our LV2 presets popup menu:
"Remove" and "Modify".
There may need to be a 'current' highlighted preset, simply because
"remove" and "modify" need something to point to! Or else we'll need some
popup list where you choose which one to remove or modify.
Ardour appears to have all three of those above features.

Save this text as a file named [some_path]/lilv_state.pat
Go to the folder where lilv source code is. Type patch -p1 -i [some_path]/lilv_state.pat
Note: After applying this patch to lilv, if you were fooling around with using those gig filename links as instruments
like I was, those presets may be no good. Use Ardour for now to remove those presets.

Please test, lemme know. Thanks.

Code: Select all

--- a/src/state.c	2018-07-22 14:53:18.000000000 -0400
+++ b/src/state.c	2018-08-09 02:32:26.133966189 -0400
@@ -495,7 +495,12 @@ new_state_from_model(LilvWorld*       wo
 		const SordNode* graph  = sord_iter_get_node(i, SORD_GRAPH);
 		state->plugin_uri = lilv_node_new_from_node(world, object);
 		if (!state->dir && graph) {
-			state->dir = lilv_strdup((const char*)sord_node_get_string(graph));
+			const char *lfp = lilv_file_uri_parse((const char*)sord_node_get_string(graph), NULL);
+			if(lfp)
+			{
+				state->dir = lilv_strdup(lfp);
+				lilv_free((void*)lfp);
+			}
 		}
 		sord_iter_free(i);
 	} else if (sord_ask(model,
@@ -516,7 +521,12 @@ new_state_from_model(LilvWorld*       wo
 		const SordNode* graph  = sord_iter_get_node(i, SORD_GRAPH);
 		state->label = lilv_strdup((const char*)sord_node_get_string(object));
 		if (!state->dir && graph) {
-			state->dir = lilv_strdup((const char*)sord_node_get_string(graph));
+			const char *lfp = lilv_file_uri_parse((const char*)sord_node_get_string(graph), NULL);
+			if(lfp)
+			{
+				state->dir = lilv_strdup(lfp);
+				lilv_free((void*)lfp);
+			}
 		}
 		sord_iter_free(i);
 	}
alex stone
Established Member
Posts: 350
Joined: Fri Jun 06, 2008 7:39 am
Has thanked: 61 times
Been thanked: 53 times

Re: muse3 crashes when adding more than one midi track.

Post by alex stone »

Tim, i'm assuming you want me to patch the lilv code in a folder in muse, which i have located.

alex@alextone:~/github/muse/muse3/muse/lv2Support/lilv-0.22.0/src$ ls

collections.c lilv_internal.h pluginclass.c scalepoint.c util.c
instance.c node.c port.c state.c world.c
lib.c plugin.c query.c ui.c zix

alex@alextone:~/github/muse/muse3/muse/lv2Support/lilv-0.22.0/src$ patch -p1 -i ~/lilv_state.pat
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- a/src/state.c 2018-07-22 14:53:18.000000000 -0400
|+++ b/src/state.c 2018-08-09 02:32:26.133966189 -0400
--------------------------



I will assume by default this is my error. Am i in the right place?

And thanks in advance for fixing this.

Alex.
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: muse3 crashes when adding more than one midi track.

Post by Tim E. Real »

Oh, sorry, no the patch should be applied to some external lilv source tree.

You tried to apply it to the built-in LV2 support files.
That is actually OK, you just need to open a terminal and navigate to
the folder "muse3/muse/Lv2Support/lilv-0.22.0"
and then try that patch command again exactly as suggested.
It would have no effect unless you are using the built-in LV2 support,
which is enabled in the cmake configuration under ENABLE_LV2_SUPPLIED,
but is also enabled if LV2 developer libraries are not found on the system.

Actually, if you wait a while, I will apply the patch to our internal support,
and then push to git. However, it would be great if you first apply the patch
yourself to either an external lilv tree or the built-in one and test it
so that I can know if it works.

Hope that didn't confuse more...
alex stone
Established Member
Posts: 350
Joined: Fri Jun 06, 2008 7:39 am
Has thanked: 61 times
Been thanked: 53 times

Re: muse3 crashes when adding more than one midi track.

Post by alex stone »

I had the same failure with the system lilv as i described above.

My attempt to patch the internal failed as well with a different message:


alex@alextone:~/github/muse/muse3/muse/lv2Support/lilv-0.22.0$ patch -p1 -i /home/alex/lilv_state.pat
patching file src/state.c
Hunk #1 FAILED at 495.
Hunk #2 FAILED at 516.
2 out of 2 hunks FAILED -- saving rejects to file src/state.c.rej

Alex.
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: muse3 crashes when adding more than one midi track.

Post by Tim E. Real »

Hm, make sure for the system version that you navigate to just
.../lilv-xxx not .../lilv-xxx/src.

The neat thing about the patch command is that by adjusting
the -p number, say to -p2, the patch can be applied within the
.../lilv-xxx/src folder if you wish.

I applied the patch last night to the git lilv version just fine.
Hopefully it will apply to the latest release as well.
I guess our internal version is too different for the patch command
to locate the correct places.

I'll tell you what, I'll take care of our internal version and push,
likely today sometime soon.
alex stone
Established Member
Posts: 350
Joined: Fri Jun 06, 2008 7:39 am
Has thanked: 61 times
Been thanked: 53 times

Re: muse3 crashes when adding more than one midi track.

Post by alex stone »

Ok, thanks.
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: muse3 crashes when adding more than one midi track.

Post by Tim E. Real »

OK done. In git master now. From the ChangeLog:

Code: Select all

09.08.2018
      - Fixed compile error when using internal LV2 support. (Tim)
        System LV2 include paths were being included, taking priority,
         fixed in top CMakeLists.txt file.
      - Fixed internal LV2 lilv state.c new_state_from_model() (Tim)
        I found state->dir should be a file path, not a URI.
        Symptom: With linuxsampler LV2 plugin for example,
         the filename sent to it was wrong, it was a full URI.
        Prepared a patch for submission to LV2, pending testing the fix.
      - Fixed internal LV2 compiler warning "unneccessary parentheses"
         treated as as error in LV2 util.h LV2_ATOM_OBJECT_FOREACH, 
         LV2_ATOM_OBJECT_BODY_FOREACH, LV2_ATOM_SEQUENCE_FOREACH, 
         LV2_ATOM_SEQUENCE_BODY_FOREACH, and in lilv.h LILV_FOREACH.
You should be able to build MusE with internal LV2 support without errors now.

Also the internal LV2 support has been patched with the above fix for
the linuxsampler problem. Tested OK.

It's your choice whether you want to just use our internal LV2 support,
or use system versions with this patch applied to lilv.
alex stone
Established Member
Posts: 350
Joined: Fri Jun 06, 2008 7:39 am
Has thanked: 61 times
Been thanked: 53 times

Re: muse3 crashes when adding more than one midi track.

Post by alex stone »

Thanks.

I'll test it and see what happens. I'm going to use the internal lv2 support for now as i still can't get that patch to work on the system files.

I appreciate you doing this quickly.

Alex.
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: muse3 crashes when adding more than one midi track.

Post by Tim E. Real »

The cmake configuration flag for building internal LV2 support is ENABLE_LV2_SUPPLIED.

Remember that when making such high-level changes, it may be necessary
to purge the build directory and clean the build, to avoid weird errors from left-over stuff.

When cmake configuration is done, you'll get this message:
"Building and linking internal LV2 support libraries (lv2, lilv, sord etc.)"
or a different one if using the system versions.
That's how you'll know for sure what is being built.

Good luck.
T.
alex stone
Established Member
Posts: 350
Joined: Fri Jun 06, 2008 7:39 am
Has thanked: 61 times
Been thanked: 53 times

Re: muse3 crashes when adding more than one midi track.

Post by alex stone »

It works.

I successfully built using the internal lv2 libs, and successfully saved 3 presets.

I agree with you that "remove" and "modify" would be useful additions to the preset window. I can manually remove presets from the directory they're stored in, so there's an option already there, but having the options in the preset window is an obvious default.

Can this work for DSSI plugins as well? I have LS16 installed as a front end for linuxsampler, and it would be useful to save presets for that, in the absence of a dedicated lv2 plugin gui.

Thanks again for doing this.

Alex.
Post Reply