Distrho Plugins crash in Muse

MusE is a MIDI/Audio sequencer with recording and editing capabilities, aiming to be a complete multitrack virtual studio for Linux. http://muse-sequencer.org/

Moderators: khz, MattKingUSA, spamatica

artofmusic
Established Member
Posts: 64
Joined: Mon Mar 17, 2014 8:01 pm

Distrho Plugins crash in Muse

Postby artofmusic » Sat Jan 26, 2019 6:54 pm

I seem to get a crash every time I load any of the LV2 dpf-plugins created by falktx (in this case 3 Band Splitter) in Muse. However, they are perfectly stable in Ardour. Before the crash, the plugins native GUI is completely black and unresponsive. Although on the generic GUI it loads up fine. I'm using the git build of Muse on Archlinux, but this also happened to me on Ubuntu Studio 18.04. It keeps looping with this:

Code: Select all

focusChanged: old:0x56402cc99430 now:0x56402cbf2470 activeWindow:0x56402c9f90f0
 old type: 9QComboBox
 now type: 11QTreeWidget
 activeWindow type: P7QWidget

 activeTopWin: N7MusEGui12ArrangerViewE
focusChanged: at widget 0x56402cbf2470 with type 11QTreeWidget
focusChanged: at widget 0x56402c9f90f0 with type N7MusEGui12PluginDialogE
focusChanged: at widget 0x56402c95ad70 with type N7MusEGui10EffectRackE
focusChanged: at widget 0x7fbc90000bc0 with type N7MusEGui10AudioStripE
focusChanged: at widget 0x56401dc88de0 with type N7MusEGui15TrackInfoWidgetE
focusChanged: at widget 0x56401dc88590 with type N7MusEGui8SplitterE
focusChanged: at widget 0x56401dac3ee0 with type N7MusEGui8ArrangerE
focusChanged: at widget 0x56401d9c9c20 with type N7MusEGui12ArrangerViewE

It fails with this message:

Code: Select all

focusChanged: old:0x56401dc318f0 now:0x56401dace540 activeWindow:0x56401dacdfa0
 old type: 13QMdiSubWindow
 now type: N7MusEGui10PartCanvasE
 activeWindow type: P7QWidget

 activeTopWin: N7MusEGui12ArrangerViewE
focusChanged: at widget 0x56401dace540 with type N7MusEGui10PartCanvasE
focusChanged: at widget 0x56401dc8a130 with type 7QWidget
focusChanged: at widget 0x56401dc88590 with type N7MusEGui8SplitterE
focusChanged: at widget 0x56401dac3ee0 with type N7MusEGui8ArrangerE
focusChanged: at widget 0x56401d9c9c20 with type N7MusEGui12ArrangerViewE

focusChanged: old:0x56401dace540 now:0x56401dc318f0 activeWindow:0x56401dacdfa0
 old type: N7MusEGui10PartCanvasE
 now type: 13QMdiSubWindow
  subwin contains 0x56401d9c9c20 which is a N7MusEGui12ArrangerViewE
 activeWindow type: P7QWidget

 activeTopWin: N7MusEGui12ArrangerViewE
focusChanged: at widget 0x56401d9c9c20 with type N7MusEGui12ArrangerViewE

focusChanged: old:0x56401dace540 now:(nil) activeWindow:0x56402d309f60
 old type: N7MusEGui10PartCanvasE
 activeWindow type: P7QWidget

 activeTopWin: N7MusEGui12ArrangerViewE
ACTIVE TOPWIN CHANGED to '<None>' ((nil))

The full log of muse3 -DD is attached below
output_crash_3_band_splitter.zip
You do not have the required permissions to view the files attached to this post.

rghvdberg
Established Member
Posts: 828
Joined: Mon May 12, 2014 7:11 am

Re: Distrho Plugins crash in Muse

Postby rghvdberg » Sat Jan 26, 2019 7:29 pm

Could you try other dpf plugins ?
Zam plugins & Dragonfly reverb for example. Also DPF but from other 'makers'
Also try X42 plugins.

artofmusic
Established Member
Posts: 64
Joined: Mon Mar 17, 2014 8:01 pm

Re: Distrho Plugins crash in Muse

Postby artofmusic » Sat Jan 26, 2019 11:43 pm

It only does this black screen with the zam compressors, 3 band eq/splitter and helm. This is only in the LV2 plugin format. Also, in the case of Helm LV2 you open it twice in its native GUI and then it pops up a black window and instead of crashing Muse it locks up the application. Below are the logs. Lastly, the x42 plugins work fine and most other zam plugins work fine, (all of the 5 plugins I use anyway).
output_crash_LV2.zip
You do not have the required permissions to view the files attached to this post.

Tim E. Real
Established Member
Posts: 181
Joined: Sat Sep 15, 2012 12:36 am

Re: Distrho Plugins crash in Muse

Postby Tim E. Real » Sun Jan 27, 2019 1:59 am

Hi, briefly looking at the post.
Couple of things I noticed:
...
User RtAudio backend - backend selected through configuration: RtAudio Pulse Audio
...
WARNING: Cannot lock memory:: Cannot allocate memory


System is not running real time with good mem limits? Due to the above warning, and this missing line:
"RtAudio pulse: running realtime scheduling" should be there.
Although much work ensured MusE should be OK without realtime, it's still possible something's not right.

Also, does it still fail with the Jack driver instead of Pulse?
Busy now, will try to test the plugins later...
Thanks.
Tim.

artofmusic
Established Member
Posts: 64
Joined: Mon Mar 17, 2014 8:01 pm

Re: Distrho Plugins crash in Muse

Postby artofmusic » Sun Jan 27, 2019 4:10 am

I fixed the realtime issue on the output by using xterm, gnome-terminal doesn't allow you to run applications from it and allow that app to lock memory/unlock memory. Also, I ran the jack backend this time and no dice. It does the same exact thing this time as last time again attached below is the output of muse3 -DD. Also, attached below is an image of the output in my terminal while redirecting standard error to the output files.
more_output.png

output-LV2-crash.zip
You do not have the required permissions to view the files attached to this post.

Tim E. Real
Established Member
Posts: 181
Joined: Sat Sep 15, 2012 12:36 am

Re: Distrho Plugins crash in Muse

Postby Tim E. Real » Sun Jan 27, 2019 5:24 am

OK Thanks. I will try to look into those plugins later.

(I had a suspicion about that Gnome terminal, there's currently a discussion
on LAU mailing list about that very topic.)

artofmusic
Established Member
Posts: 64
Joined: Mon Mar 17, 2014 8:01 pm

Re: Distrho Plugins crash in Muse

Postby artofmusic » Sun Jan 27, 2019 5:31 am

It does the same thing whether you use the stable plugins https://distrho.sourceforge.io/plugins.php or build them from git. VST, LADPSA, DSSI variants don't crash though. It also seems like your vestige header implementation is the best of all the free daws. Anyway, good luck looking into this one.

artofmusic
Established Member
Posts: 64
Joined: Mon Mar 17, 2014 8:01 pm

Re: Distrho Plugins crash in Muse

Postby artofmusic » Fri Feb 01, 2019 3:45 pm

I found another crashing plugin its zynaddsubfx with the zyn-fusion ruby based GUI. It is only the LV2 variant that crashes. Same output scrolls down the terminal screen that is not caught by stderr redirection as the other crashes. Ardour loads the zyn-fusion LV2 variant just fine. I wonder if you had time to look at the other crashing plugins.
output-zynfusion.zip
You do not have the required permissions to view the files attached to this post.

Tim E. Real
Established Member
Posts: 181
Joined: Sat Sep 15, 2012 12:36 am

Re: Distrho Plugins crash in Muse

Postby Tim E. Real » Thu Feb 21, 2019 11:20 pm

Hey ho. I have pushed a possible fix to git master.

Tested OK with the aforementioned 3-band EQ and distrho friends, Zyn (the original) and ZynEcho and friends,
AVLinux drum kits, DrumGizmo, and good ol' standard synthv1 and friends.

I had a year-or-two old hack in there I believe for one particular synth, possibly Zyn Fusion
which I don't have at the moment and was using an older version of that time.

Caveats:
1) My version of Zyn is older and it seems to have problems with setting presets. Must update. The other synths have no problem.

2) Speaking of Zyn presets, it seems to have revealed a problem with our popup menu LV2 preset saver/selector:
Zyn having many available presets just happened to separate them into "<more>" popup menu categories.
At which point I noticed that only the presets NOT in "<more>" sections seem to work.

3) My older version of Zyn requires me to open the UI twice because the first time there may be garbage on the background. Minor problem.
However it seems to load and display just fine when opening it from a saved song.

4) Users please test with your plugins - especially Zyn Fusion 'cause I don't have it - and lemme know if any trouble.

Tim.

Tim E. Real
Established Member
Posts: 181
Joined: Sat Sep 15, 2012 12:36 am

Re: Distrho Plugins crash in Muse

Postby Tim E. Real » Fri Feb 22, 2019 12:17 am

5) Also I discovered that if you store an LV2 preset in any app, since by default
the directory ~/.lv2 is where LV2 presets are stored, and ~/.lv2 is getting included
in the MusE list of LV2 path to search for plugins (See Settings > Global Settings > Plugin Paths),
our lengthy automatic plugin re-scan kicks in upon next MusE restart !

So this presents a problem.
If ~/.lv2 is a place where plugins are installed AND their ever-changing settings, that's not good for us. Plugin re-scan will happen.

So maybe ~/lv2 instead of ~/.lv2 should be the place where plugins can be installed?

Please adjust your Settings > Global Settings > Plugin Paths accordingly, possibly replace ~/.lv2 with ~/lv2.

Should I change our hard-coded first-time default LV2 path from ~/.lv2:/usr/local/lib/lv2:/usr/lib/lv2 to ~/lv2:/usr/local/lib/lv2:/usr/lib/lv2 ?

Thanks.

artofmusic
Established Member
Posts: 64
Joined: Mon Mar 17, 2014 8:01 pm

Re: Distrho Plugins crash in Muse

Postby artofmusic » Fri Feb 22, 2019 2:31 am

Sounds like you should?

tramp
Established Member
Posts: 1355
Joined: Mon Jul 01, 2013 8:13 am

Re: Distrho Plugins crash in Muse

Postby tramp » Fri Feb 22, 2019 4:06 am

Tim E. Real wrote:So this presents a problem.
If ~/.lv2 is a place where plugins are installed AND their ever-changing settings, that's not good for us. Plugin re-scan will happen.

So maybe ~/lv2 instead of ~/.lv2 should be the place where plugins can be installed?

Please adjust your Settings > Global Settings > Plugin Paths accordingly, possibly replace ~/.lv2 with ~/lv2.


Sorry, but I don't think that is a good idea to do so.
In the long run, you've to fix your scanner anyway to cover the standard path of LV2 specs.
http://lv2plug.in/pages/filesystem-hier ... ndard.html
On the road again.

Tim E. Real
Established Member
Posts: 181
Joined: Sat Sep 15, 2012 12:36 am

Re: Distrho Plugins crash in Muse

Postby Tim E. Real » Fri Feb 22, 2019 4:12 am

Yes absolutely, as I just found out right now by testing it.
We must include ~./lv2.

Meaning I must fix my scanner.

Thanks.

artofmusic
Established Member
Posts: 64
Joined: Mon Mar 17, 2014 8:01 pm

Re: Distrho Plugins crash in Muse

Postby artofmusic » Sun Feb 24, 2019 3:13 am

Helm's LV2 still crashes on Arch after opening, closing and reopening it in Muse. And it also hangs Muse the same way. :( However, it still works in Ardour. The dpf plugins now work though yeah :D

Tim E. Real
Established Member
Posts: 181
Joined: Sat Sep 15, 2012 12:36 am

Re: Distrho Plugins crash in Muse

Postby Tim E. Real » Sat Mar 02, 2019 11:03 pm

Howdy. Here's my contribution form the last few days. In git master now.

Please give it a twirl.
Thanks. Will test other plugin mentioned later.

Code: Select all

      - Plugin scanner: Redesign fixes problems with 'auto-rescan' trigger. (Tim)
        Significant changes: Previously folders were scanned for date/time differences
         compared to the cache file's date/time. This caused unwanted rescans if ANY
         file or folder inside changed. Now it is all *.so file centric. Now, ALL *.so
         files found are registered in our caches, and a new 'file timestamp' member
         was added, and a new "unknown_plugins.scan" cache file added. Then on next start
         it compares date/time of what exists in our cache with what is actually on the system.
      - Fixed remaining compile issues with various options disabled.
        Tested by turning off ALL cmake options. Revealed an error: We never linked
         pthreads into the core! With cross-platform in mind, this was followed:
        https://stackoverflow.com/questions/49768454/whats-the-differences-between
         -pthread-and-pthread-options-in-cmake (the 'modern' answer at bottom).


Return to “MusE Sequencer”

Who is online

Users browsing this forum: No registered users and 1 guest