muse for windows

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

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

Re: muse for windows

Postby Tim E. Real » Mon Feb 18, 2019 12:56 am

Also today I thought about whether we should be hard-coding #ifdef _WIN32 and _WIN64,
or whether it would be better to let cmake tell you what OS it is and define a flag like say HAVE_WIN32 or HAVE_WIN64
and all the code will refer to THAT flag instead of directly embedding those other flags in the code.

I'm a bit weary of hard-coding. It's nice if we can let cmake have total control over all the code with a HAVE_WIN32/64 flag.
We could have three flags: HAVE_WIN (for a general catch-all), and HAVE_WIN32 and HAVE_WIN64.
Not sure. Just some thoughts...

Also today I realized I am confused by something:
Why is _WIN32/64 defined at all in a Ming program? Isn't it supposed to be 'Linux'?
And if _WIN32/64 is defined then how are we supposed juggle knowing how to tell whether we can call
'Linux-y' type stuff or whether to make Windows calls instead?
Seems we have both 'Linux-y' type stuff and 'Windows-y' type stuff in one program?

Thanks.

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

Re: muse for windows

Postby Tim E. Real » Mon Feb 18, 2019 1:07 am

And hopefully just one further note: In a few spots it appeared perhaps you didn't realize that to make use of
our cmake flags within the code (such as the ALSA_SUPPORT define) be sure to include this header:

Code: Select all

#include "config.h"

This header brings in all the variables that are transferred from the top cmake file to the actual code.
If you forget to include it in the code, all the defines (like ALSA_SUPPORT) will be false!

A related file is the file "config.h.in" in the top directory. This file defines what variables are actually transferred
from the top cmake file to the code.

T.

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

Re: muse for windows

Postby Tim E. Real » Mon Feb 18, 2019 1:31 am

Oh man! Looks like I somehow merged the thing into our master!
No wonder your pull request disappeared :shock:

Oh well. It's in master now, eh? Bwha ha ha...

Let's move forward and fix anything I may have broke before you had a chance to test it on Windows.
Sorry if all these changes today cause much headache on your side. I know it's tough.

In theory all you have to do is fork master again and look for all the places containing _WIN32 (about 102)
to see the places you worked on or were working on.
Hopefully you can continue your work from within our master again.

Tim.

aquilarubra
Established Member
Posts: 48
Joined: Sat Nov 24, 2018 8:12 pm

Re: muse for windows

Postby aquilarubra » Mon Feb 18, 2019 8:54 am

Yes, I realized a mess was happening :D Ok, let's fix it. Maybe it's better I wait a moment that you update your changes. Then I will check everything again.

Thanks for cmake tips. I really don't know cmake.

_WIN32 and _WIN64 seem hardcoded also in other libraries that MusE uses. So, maybe it's a good idea to be consistent with those too. Maybe in the future cmake could be dropped in favor of some other build managers.

Mingw defines _WIN32, regardless if it is mingw64. I am compiling under Windows, by the way. If you cross-compile under Linux, you need to set the target host (i.e. you are telling you will compile for a Windows machine), which will be treated as _WIN32 again. Otherwise, you would use gcc, not mingw on Linux. When you compile under MSYS2, it already defaults to a Windows target.

I prefer to make things work natively on Windows before cross-compiling, also because it is an isolated environment. With cross-compiling, you are never certain that compiler, linker, etc. respect the sandbox and you have to take extra care. With Ardour, when it was not finding a library, it was merging with my system libraries sometimes... and it was a mess. There are distros that are more helpful with sandboxing than others. I found Debian (sic!) the worst, Fedora quite ok, Arch best for cross-compiling.

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

Re: muse for windows

Postby Tim E. Real » Mon Feb 18, 2019 5:18 pm

I'm pretty much done with any mods to the pull request.
What matters to me at the moment is that it works fine under Linux as usual.
The rest I will leave to you, as it does not seem to harm it.
It should be safe to start your work again.
In other words at the moment I'm back to comfortably working on a branch I was already working on.
If and when it gets done I'll be committing some more big, good stuff maybe in several days.
Always, big stuff can come down the line from me at any time. It's to be expected :)

T.

aquilarubra
Established Member
Posts: 48
Joined: Sat Nov 24, 2018 8:12 pm

Re: muse for windows

Postby aquilarubra » Tue Feb 19, 2019 11:39 am

I am running tests and there is another couple of fixes. Bear with me.

aquilarubra
Established Member
Posts: 48
Joined: Sat Nov 24, 2018 8:12 pm

Re: muse for windows

Postby aquilarubra » Tue Feb 19, 2019 4:08 pm

Where did you get M_PI from?

Code: Select all

[ 93%] Building CXX object plugins/doublechorus/CMakeFiles/doublechorus.dir/simplechorusmodel.obj
E:\msys64\usr\src\muse\muse3\plugins\doublechorus\simplechorusmodel.cpp: In constructor 'SimpleChorusModel::SimpleChorusModel(float)':
E:\msys64\usr\src\muse\muse3\plugins\doublechorus\simplechorusmodel.cpp:60:49: error: 'M_PI' was not declared in this scope
       sinus[i] = (float)(sin(((double)i * 2.0 * M_PI) /
                                                 ^~~~
mingw32-make[2]: *** [plugins\doublechorus\CMakeFiles\doublechorus.dir\build.make:85: plugins/doublechorus/CMakeFiles/doublechorus.dir/simplechorusmodel.obj] Error 1
mingw32-make[1]: *** [CMakeFiles\Makefile2:1472: plugins/doublechorus/CMakeFiles/doublechorus.dir/all] Error 2
mingw32-make: *** [Makefile:151: all] Error 2

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

Re: muse for windows

Postby Tim E. Real » Tue Feb 19, 2019 4:36 pm

Hm, weird.
At the top of simplechorusmodel.cpp I have "#include muse_math.h".

And in muse_math.h I have:

Code: Select all

#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 support in <cmath>,
and so HAVE_M_PI is not defined (is false).
So if HAVE_M_PI is false it is supposed to define M_PI right there in muse_math.h

Wonder what's wrong...

I am here all day so communication should be relatively fast.
I may disappear as I boot Windows - that'll take a half hour just to start :wink:

aquilarubra
Established Member
Posts: 48
Joined: Sat Nov 24, 2018 8:12 pm

Re: muse for windows

Postby aquilarubra » Tue Feb 19, 2019 7:59 pm

I am not that quick, lol. Will continue tomorrow. Cheers

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

Re: muse for windows

Postby Tim E. Real » Tue Feb 19, 2019 8:44 pm

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 defined".
But it ain't really defined as you can see...

My senses tell me I did this wrong in the top level CMake:

Code: Select all

# Check for GNU-specific math support:
check_cxx_symbol_exists(exp10 cmath HAVE_EXP10)
check_cxx_symbol_exists(exp10f cmath HAVE_EXP10F)
check_cxx_symbol_exists(exp10l cmath HAVE_EXP10L)
check_cxx_symbol_exists(M_PI cmath HAVE_M_PI)


The first three are working fine. The M_PI one is not. Falsely reporting it as existing.
I suspect I need to change that to:

Code: Select all

check_symbol_exists(M_PI math.h HAVE_M_PI)

Or something like. I think I'll just remove it and hard-code

Code: Select all

#ifndef M_PI #define M_PI 3.14.....


Hang in there...

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

Re: muse for windows

Postby Tim E. Real » Tue Feb 19, 2019 9:55 pm

Yes that was it. You can continue to compile simply by replacing the HAVE_M_PI
in muse_math.h like this:

Code: Select all

#ifndef HAVE_M_PI

Change to:

Code: Select all

#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 fixes you have submitted so far are just a prelude to the actual Windows feature?
Because from what I can see you'll have more trouble ahead. For example the dlfcn.h header and functions like dlopen().

What actual platform, build chain, and/or IDE are you using?
MingW, MSYS2, CygWin? QtCreator? KDevelop for Windows? Or command line and an editor?

I mentioned a while ago that I too, attempted to port to Windows. I tried using either MingW or MSYS2.
I gave up, concluding it was a waste of time because it appeared neither system fully supported what we need.
Each supported some of the things we need but not everything. IOW one system supported 'this', but the other supported 'that'.
MingW is not POSIX and so lacks all those goodies like dlfcn.h.
MSYS2 didn't seem to have or like Qt. Or something like that.
Sure there are replacement substitute libraries out there (for dlfcn.h).
With more work it could be done I suppose.
This is what I mean when I ask "was this a prelude with more of your fixes to come?".

There is a new player in town sort of based on MingW but a lot of animosity between those two projects.

T.

aquilarubra
Established Member
Posts: 48
Joined: Sat Nov 24, 2018 8:12 pm

Re: muse for windows

Postby aquilarubra » Wed Feb 20, 2019 4:19 am

I'm using mingw64 in msys2 environment. Definitely there are differences, but I was trying to make MusE more ready for cross platform compilation. At the end I could compile it, but that it works is another thing. At least, it is a step forward.

I didn't find any issue with QT. I think it is mature enough with mingw64, as you install it directly through mingw64 packages.

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

Re: muse for windows

Postby Tim E. Real » Wed Feb 20, 2019 4:37 am

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 latest KDevelop.
It refuses to install. It's a known, as-yet unfixed bug. Go figure. I just can't .... Win... sometimes... :wink:

QTCreator... Wins again...

aquilarubra
Established Member
Posts: 48
Joined: Sat Nov 24, 2018 8:12 pm

Re: muse for windows

Postby aquilarubra » Wed Feb 20, 2019 5:02 am

Forgot to mention. I just use notepad++, no IDE. If I were to develop a cross platform application, I would choose ultimate++ over Qt, as it sensibly decreases code lines and has better license terms. Their Theide editor is also quite good and on Windows it comes with mingw64.

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

Re: muse for windows

Postby Tim E. Real » Wed Feb 20, 2019 6:04 am

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 search capabilities. And highlighting. And 'find usages' which really helps track down used things.
What possible advantage could there be in using Notepad++?
Also, it might change the file formatting (CR/LF), try to preserve it.
The overwhelming benefits of IDE are too much to ignore in a project like this.
Rant over.

About PackageConfig for Windows: In Linux, CMake uses PackageConfig (.pc files) to help find libraries and headers.
In Windows there is a PackageConfig version but I believe I was unable to install it.
Thus, lacking PackageConfig support I modified our top-level CMake file.
For example here is the new section that detects and supports Jack Audio, note that user must manually
supply a JACK_INCLUDE_DIRS path (usually "/Program files (x86)/Jack/includes") :

Code: Select all

##
## find jack >= 0.103.0
##

### Old code:
#PKG_CHECK_MODULES(JACK REQUIRED jack>=0.103)
#include_directories(${JACK_INCLUDE_DIRS})

### New code:
if (UNIX)
    PKG_CHECK_MODULES(JACK REQUIRED jack>=0.103)
else (UNIX)
    find_path(JACK_INCLUDE_DIRS jack/jack.h)
    if (JACK_INCLUDE_DIRS STREQUAL "JACK_INCLUDE_DIRS-NOTFOUND")
        message(FATAL_ERROR "Jack development files not found in JACK_INCLUDE_DIRS: ${JACK_INCLUDE_DIRS}")
    endif (JACK_INCLUDE_DIRS STREQUAL "JACK_INCLUDE_DIRS-NOTFOUND")
endif (UNIX)

include_directories(${JACK_INCLUDE_DIRS})

message("Jack include dirs: ${JACK_INCLUDE_DIRS}")


In case you find that ultimately PackageConfig for Windows is not an easy option,
would you like me to commit those top-level CMake changes?
There are several sections like the one shown above, one for each library (sndfile, samplerate etc.)
[Hm, I think I have to find a way to actually detect if PackageConfig itself is available and use that
instead of the

Code: Select all

if (UNIX)
line shown above.]

Or, if you find some way to get CMake to honour PackageConfig settings - without installing PackageConfig for Windows,
I can just leave it alone for now.


About wrapping with hard-coded defines: Take a case like the unix dlfcn.h header, containing dynamic loading functions.
If it turns out that for whatever reason dlfcn.h is not available and you need to 'substitute it' or use the Windows LoadLibrary() et al,
I'd like to try and 'house' everything in a central 'hub' exactly like I did in muse_math.h - there is no more math.h or <cmath>
header usage in the entire app except in muse_math.h and all calls to exp10 and M_PI go through it now.
So for the dl functions, we can probably find some common handle format to pass around and house the required
platform-dependent code in one place. On *nix it would use dlopen() et al. On Windows it would use LoadLibrary() et al.

Cheers.


Return to “MusE Sequencer”

Who is online

Users browsing this forum: No registered users and 1 guest