LinuxMusicians

asbak wrote:Before compiling a new version of Muse I usually

rm -rf build

Hmm, must try that.

funkmuscle wrote:

asbak wrote:Before compiling a new version of Muse I usually

rm -rf build

Hmm, must try that.

that failed too.. I will not find most of the plugins except things like EQs and Delays.. No lv2 synths or native VST synths.

It works fine on my system, with a very recent muse3 build from git.

Where are your LV2 plugins installed?
Try putting them in /usr/local/lib/lv2 and/or /usr/lib/lv2
Do the same thing for the vsts

If that still fails try:

export LV2_PATH=/usr/local/lib/lv2:/usr/lib/lv2
(Do same for vsts)
muse3

If that still fails, delete the git clone on your system, clone a new one and recompile and install.

asbak wrote:It works fine on my system, with a very recent muse3 build from git.

Where are your LV2 plugins installed?
Try putting them in /usr/local/lib/lv2 and/or /usr/lib/lv2
Do the same thing for the vsts

If that still fails try:

export LV2_PATH=/usr/local/lib/lv2:/usr/lib/lv2
(Do same for vsts)
muse3

If that still fails, delete the git clone on your system, clone a new one and recompile and install.

trust me, I've done it all, well except deleting the git clone.
remember, all this worked until recently and all this works with Qtractor and Ardour. I do have plugins in both directory and the environment paths are correct. I even moved a few lv2 plugins into the /usr/local/lib/lv2 and they were found until the next pull then muse would not find them.
I will try to delete the git clone.

Maybe obvious questions, but are you install or working from userspace? (I don't know if muse can work from userspace).

If installing are you doing an uninstall before trying to build and install the new one?

Do you somehow have more than one version installed?

You might need to hunt around and clean out stale files.

folderol wrote:Maybe obvious questions, but are you install or working from userspace? (I don't know if muse can work from userspace).

If installing are you doing an uninstall before trying to build and install the new one?

Do you somehow have more than one version installed?

You might need to hunt around and clean out stale files.

did all.. now trying a clean git clone.. will update once completed.

Has anyone got a segmentation fault when trying to launch drumkv1 as an LV2 plugin? The version number for drumkv1 is 0.7.1-2 in Arch and I am up-to-date in MusE Sequencer 3.

I can launch drumkv1 only with Carla stand-alone. If I try to use Carla-Rack with MusE3 and launch drumkv1 from there, MusE3 will crash and carry Carla-Rack along with it. Carla-Rack is not dead, so I can't bring up MusE3 unless I kill Carla-Rack (PID number) first.

samplv1 crashed as well.

Calf MonoSynth/Organ, Helm, and ZynAddSubFX ran just fine.

Thanks. Then they may need to compile QT5 LV2 plugins for MusE3 to work.

But why are the plugins using QT frameworks? I do not know I cannot mix QT4 and QT5. I guess developers favor lack of backwards-compatibility, like not being able to run Windows 2000 applications in Windows 10.

GraysonPeddie:

I know samplv1 would be nice to have and it really should work but there's not much need for it under MusE because you can use the integrated SimpleDrums MESS plugin if all you need is a simple sample playback plugin.

Please report your plugin probs on GitHub.

falkTX:

That's a shame about Qt5 dropping a few (important, for Carla) features!

when danboid first mentioned Muse3. I got it working and tested it with drumgizmo. Easiest work with midi and drums on Linux... I usually us Hydrogen but like the kits from drumgizmo but Ardour and Qtractor took very very long.
Muse3 once they've fixed the issue I've reported to GitHub for me will be awesome.. Problem is I don't think they will find it.

GraysonPeddie wrote:Thanks. Then they may need to compile QT5 LV2 plugins for MusE3 to work.

But why are the plugins using QT frameworks? I do not know I cannot mix QT4 and QT5. I guess developers favor lack of backwards-compatibility, like not being able to run Windows 2000 applications in Windows 10.

fwiw.

the v1's are built to qt5 by default now and the same is true for qtractor and all yours truly q-stuff

if you could build muse3 (qt5) then it's just a matter of rebuilding drumkv1 (or samplv1, or synthv1) as well, provided you drop the --enable-qt4 from configure line.

the issue here is about that any object linked to libQtGui.so.4 (qt4) cannot be loaded onto another one linked to libQt5Widgets.so.5 (qt5) and vice-versa--an immediate segfault crash happens as soon you dlopen() one into the others process address space.

hth.
cheers

Off-topic--

from what I'm reading on this forum, it sounds like the new Qt5 is really creating a serious division, at least as far as audio applications go. I can't understand why they didn't make the two more "compatible.."

Back on topic..


brian

briandc wrote:Off-topic--

from what I'm reading on this forum, it sounds like the new Qt5 is really creating a serious division, at least as far as audio applications go. I can't understand why they didn't make the two more "compatible.."

qt5 is not that new anymore. you may say that is qt4 that's getting old and bit-rotten

the division here starts when falktx is keeping carla-vst locked to qt4 still. fwiw. every other major audio application is moving to qt5 and sooner all distros will make it the preferred level default, if not already.

cheers

off-topic:

falkTX wrote:I'll move to Qt5 when KDE5 gets stable.

*it is* stable enough

fwiw. i'm on plasma5 aka. kde5 and have no argument about to say it isn't "stabler" than kde4.

byee

Hi!
I just found this thread - after completely verifying everything said here
the hard way.

Yesterday I set out to find out why stock synthv1 + friends were crashing MusE here on KUbuntu 15.10.

I suspected it was library symbol conflicts but had thought is was OUR symbols.
When we added namespaces to MusE that seemed to cure some problems.
No luck using them in this situation here though. I tried.

Eventually I reasoned it was Qt conflicts, and whittled it down to a simple Qt5 Creator application:
dlopen(path-to-synthv1, RTLD_NOW);

Crash. That sucks.
Funny, as soon as I suspected it was a Qt problem, I had very uneasy feelings about the whole thing.

So... I may have a solution here
In our LV2 code, I hacked lilv_lib_open() and added the RTLD_DEEPBIND.

Success! I am at this moment playing synthv1. Nice sound from the start. Old school.

However, attempting to open the GUI crashes, of course
But I can still use the MusE generic GUI instead

Anyway at least now I can poke around the library + ttls and determine if the
native-GUI open menu item should be greyed out.

I will commit something if this works OK. Stay tuned.

If you guys think this is a bad idea, like if you think some synths might still
crash upon load, let me know what you think.

Thank you very much to all for the concise information I was looking for here.
It's eye-opening for sure.

Tim.
The MusE project.