gcc 8.2, python 3.7

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: MattKingUSA, khz, spamatica

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

gcc 8.2, python 3.7

Postby aquilarubra » Sat Nov 24, 2018 8:18 pm

Hi, I updated the Arch package, which I attach. I don't know why there were restrictions concerning gcc (version 6 was recommended). I could compile it with gcc 8.2 and also jack2.

In the PKGBUILD, you can also see some patches (the sed commands), through which I enable Python 3.7. They should probably be added to enable Python 3.7 support.

I was also thinking about a port to Windows (basically cross compiling with mingw). However, the mixed architecture with dssi does not seem that easy to transpose to mingw packages. Maybe it should be allowed to disable it during build.

I would love to see portaudio as audio backend in MusE, as that would allow Asio support in Windows.

spamatica
Established Member
Posts: 132
Joined: Mon Feb 08, 2010 10:38 am

Re: gcc 8.2, python 3.7

Postby spamatica » Sun Nov 25, 2018 9:10 pm

Hi,
I don't see anything attached here but I saw you made a ticket so I suppose that is the same?
Probably the recommendation for gcc 6 is old and was the most recent compiler when the recommendation was made, Tim might know more.

DSSI is optional so it should not be necessary in the case of trying to build on windows, check the CMakeLists.txt for more details.
Regarding ASIO, RtAudio which is already supported has a backend for ASIO under Windows so that could be a way forward.

Also, I don't know the state of Jack under Windows but it used to support ASIO anyway. Jack is the most evolved audio backend in MusE so it could be an alternative approach.

Lastly, mostly as a historical note, there is a branch which sadly is very much out of date now called platform_independence was made to try rework linux specific parts of MusE. I believe it did build under Windows at one point, mostly unusable though. I think some of the changes there were ported back to main though.

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

Re: gcc 8.2, python 3.7

Postby Tim E. Real » Sun Nov 25, 2018 11:53 pm

Hello. Awesome job, thanks! Be sure to post your work to Arch forums!

I think maybe you meant that the gcc6 requirement was an Arch package thing.
From our README file:
- gcc >= 4.x.x or clang >= 2.9

About the Python stuff: Wow, I don't think anyone (including me) has enabled that
option or tested it in a long time. Good stuff.
Could you extract those 'sed' changes into either a patch or just a short explanation?
(It's hard for me to read sed lines and determine exactly what it does.)
The part which says "#include <QButtonGroup>" in genset.cpp was already patched
a few weeks ago by another user, we now include <QButtonGroup> in genset.h
Also the part which says "#include <QAction>\n\n/' muse/mplugins/mitplugin.cpp",
<QAction> is already included in mitplugin.cpp.

Also be aware that in the last few weeks some major folders and files were moved around.
For example /muse/widgets/genset.cpp (as shown in your 'sed' lines) now resides in /muse/components/genset.cpp
(All complex 'widgets' were moved out to a 'components' folder.)

Whether or not that Python stuff still works reliably is questionable.
The ability to control MusE through Python was greeted with great excitement when it was added.
But the code may (or may not) need some tender loving care, since a lot has changed since then.
Do let us know if you spot any trouble.

About Windows: Yes DSSI is optional with MusE cmake. One of the problems with DSSI is that it relies on ALSA,
which is not available on Windows. There is a cut-down, stripped-down ALSA compatibility package specifically just for DSSI,
and I tried that package but unfortunately it just doesn't contain enough of the ALSA code to allow MusE to use it with DSSI.

I have, on my Windows drive, my own rather full-blown attempt at a Windows port, from a year ago,
which I never announced. I tried two different approaches: A full native Windows port and a Mingw port.
The full native Windows port got so far before I realized it wasn't going to work. The Mingw port got so far
before I started having trouble with Mingw and Qt so I had to give up trying for now. Such a shame, I tried really hard.

MusE now supports RtAudio since about a year, which should help since it allows RtAudio to do all the audio stuff.
I have used Jack for Windows with ASIO (about a year ago) and it works. I used it with some Windows DJ software.

If there's anything more that you need, help, fixes, bugs etc. don't hesitate to ask, we'll do our best to help.
Tim.

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

Re: gcc 8.2, python 3.7

Postby aquilarubra » Tue Nov 27, 2018 6:19 am

Thanks. I was missing replies here, but now that I enabled notifications I should get them.

I am the same who posted the PKGBUILD, and now it was updated in the AUR repository. For some reason the attachment failed here. I will write later about the used thing.

My compliments for the Windows attempts! I think the easiest way is to cross build. I spent 2 months trying to cross compile Ardour, tried Fedora, mimicked the secret way the ardour Debs do it (and ask for payment for binaries), till I ended up with Arch. I had partial success with Fedora (got recipes are all outdated and won't work to the end); success with Debian, but I was ending up with pretty old libraries and didn't want to figure out the last bits; and complete success with Arch, with a bleeding edge build. I have a ready virtualbox machine with all the libraries compiled, and MusE only uses a subset of them. Despite I could compile Ardour and run it successfully, when I load an existing project it crashes as the Ardour calls misbehave with the gtkmm library. I attribute this to the Ardour code just being old and buggy, when it is compiled with new libraries. Their Windows build was built on top of Wheezy and worked for a chance. Debian notoriously uses old libraries already. So, their Windows working version can be considered maybe 5-6 years old. Anyway, I got plenty of insights along my attempts.

With MusE, I felt a bit halted, because dssi requires mixing 32 bit stuff with 64 bit. But now the alsa issue is clearer to me. I'll try to spot out required libraries and evaluate feasibility. Rtaudio is a great way for Asio support. Maybe if we join efforts we can do it. I wrote C code 20 years ago and have no clue of QT, but I can help putting things together.

I could write a bit PKGBUILD and create an AUR package, so it would make it easier for people wanting to test the latest MusE code.

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

Re: gcc 8.2, python 3.7

Postby aquilarubra » Sat Dec 01, 2018 6:17 pm

Hi, here are the changes to pyapi.cpp.

static struct PyModuleDef muse =
{
PyModuleDef_HEAD_INIT,
"muse", /* name of module */
"", /* module documentation, may be NULL */
-1, /* size of per-interpreter state of the module, or -1 if the module keeps state in global variables. */
g_methodDefinitions
};

static void* pyapithreadfunc(void*)
{
Py_Initialize();
PyImport_AddModule("muse");
PyModule_Create( &muse );

Simply, the new function PyModule_Create knows nothing of the methors and cannot take parameters. Therefore, you need to pass a structure to it, which contains all parameters and references to methods.


Return to “MusE Sequencer”

Who is online

Users browsing this forum: No registered users and 1 guest