LinuxMusicians

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. - Plugin scanner: Redesign fixes problems with 'auto-rescan' trigger. (Tim) Significant changes: Previously folders were scanned for date/time differences ...

Thank you Robert.
You da man!

I've got a scanner fix as discussed in another thread. Should be done soon.
It should make it into the final release.

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

Meaning I must fix my scanner.

Thanks.

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-s...

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...

OK If you are actually counting seconds, then there is this in main.cpp at line 1086: // WARNING Must do it this way. Call registerClient long AFTER Jack client is created and MusE ALSA client is // created (in initMidiDevices), otherwise random crashes can occur within Jack <= 1.9.8. Fixed in Jack ...

Mm, not much else I can think of.
If you are building MusE from source you can ensure that the build type
is 'Release' rather than 'Debug' which could help with speed.

Hello. There are command-line switches available to disable loading of various plugin support, which can help improve loading time. Type muse3 -h to see the options. Also if you are using the latest git version of MusE, there is now a plugin scanner which does add considerable loading time - but onl...

Hi, the patch would not apply cleanly. The patch contains changes that were already applied to master. Try to update your branch from our latest master, resorting even to diff files if necessary. Then submit the difference between yours and ours. I think the difference was mainly only removal of the...

Wow, that's neat. PC just works. Hm, wonder why I had trouble...
Carry on, then.

Thanks.

Notepad++? Oh no. :shock: Normally I'd have nothing to say about that, to each his own. But MusE is a huge program with a lot of inter-connected parts. One must be absolutely sure, if changing one thing, that any other things using that thing are examined. Geez, get an IDE just for the project-wide ...

Yeah it was about 2 years ago when I last tried. Maybe it wasn't mature or I just didn't do it right. At the time I was experimenting with KDevelop (my fav IDE) for Windows. But QTCreator fared much better than KDevelop at this game. Today, encouraged by just being in Windows, I tried to install the...

Yes that was it. You can continue to compile simply by replacing the HAVE_M_PI in muse_math.h like this: #ifndef HAVE_M_PI Change to: #ifndef M_PI I have not fixed this in master yet... But you can simply change it to continue. [Edit:] Fixed in master now. BTW Do I understand correctly that the fixe...

Hey ho, rappin' at ya from Windows here! And yeah, I get the same error. My fault, sort of. Kinda dumb. The top Cmake file is telling me M_PI would in fact defined after an inclusion of <cmath>, and thus is dutifully defining HAVE_M_PI, which muse_math.h looks at and says "oh well it's already ...

Hm, weird. At the top of simplechorusmodel.cpp I have "#include muse_math.h". And in muse_math.h I have: #include <cmath> #include "config.h" #ifndef HAVE_M_PI #define M_PI 3.14159265358979323846 #endif What is supposed to happen is that cmake will detect if there is no M_PI supp...