Page 3 of 3

Re: MusE 3 git updates

Posted: Mon Jan 11, 2016 10:43 am
by briandc
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

Re: MusE 3 git updates

Posted: Mon Jan 11, 2016 11:04 am
by rncbc
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

Re: MusE 3 git updates

Posted: Mon Jan 11, 2016 11:10 am
by rncbc
off-topic:
falkTX wrote:I'll move to Qt5 when KDE5 gets stable. :lol:
*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

Re: MusE 3 git updates

Posted: Wed Mar 23, 2016 7:04 pm
by Tim E. Real
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 :D

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.

Re: MusE 3 git updates

Posted: Wed Mar 23, 2016 7:11 pm
by funkmuscle
why not! I'm still having the same issues on Arch64 that I mentioned under 'Issues' in Git,
Did a fresh pull last night and still only get LV2 and VST synths by going into the /build/usr/bin/ dir.

Maybe what you've just mentioned here could be the fix.

cheers

Harvey

Re: MusE 3 git updates

Posted: Wed Mar 23, 2016 8:06 pm
by rncbc
Tim E. Real wrote:Yesterday I set out to find out why stock synthv1 + friends were crashing MusE here on KUbuntu 15.10.
get those vee-ones built to qt5 (the configure default for quite a while)!

you're probably trying to load qt4 versions of a plugin into a qt5 host (muse3). there's no simple way to tell you this: it won't ever work and there's no formidable solution for this situation. sorry--it aborts immediately on dlopen() due to qt astray meta-symbol clashing (my own wordings:)).

you can however scan the lv2-uis (via lilv ofc.) whether a lv2ui::Qt4UI or Qt5UI is there being exposed, being the later the probable sane one to whitelist in your case.

hth.
cheers

Re: MusE 3 git updates

Posted: Wed Mar 23, 2016 9:30 pm
by Tim E. Real
rncbc wrote: get those vee-ones built to qt5 (the configure default for quite a while)!
Got 'em.
rncbc wrote: you're probably trying to load qt4 versions of a plugin into a qt5 host (muse3).
Correct. As I found out, they are Qt4 plugins.

What led me astray at one point was the plugins load fine in QTractor.
But then I realized it is QTractor-Qt4 on this distro !
rncbc wrote: there's no simple way to tell you this: it won't ever work and there's no formidable solution for this situation. sorry--it aborts immediately on dlopen() due to qt astray meta-symbol clashing (my own wordings:)).
Nope. Not any more. At least not with synthv1 and drumk.
As I said I'm playing Qt4 synthv1 in Qt5 MusE right now. Just fine.
Just that the GUI won't open.

And, I verified in my very simple one-line test Qt5 QtCreator program:

dlopen(path_to_synthv1, RTLD_DEEPBIND | RTLD_NOW);

Success.

Of course I still have to try other plugins. Maybe It will fail with some...
Let me go through the ttls and find some more Qt4 ones...
rncbc wrote: you can however scan the lv2-uis (via lilv ofc.) whether a lv2ui::Qt4UI or Qt5UI is there being exposed, being the later the probable sane one to whitelist in your case.
Definitely! That's what I'm going to look at.
It helps decide even whether to make the plugin available at all to the user.

Consider though, that a user opening an old project that used a still-installed Qt4 plugin
will want it to just work, and my option would allow them to still play and edit their song
in MusE, albeit without a native GUI for the plugin. That is, if this fix works OK...

Tim.