1.9.2: midi kills the application on Linux. about frescobaldi HOT 9 CLOSED

thanks

probably the ctypes embedding code does something wrong in 64bit mode.

It is recommended to install a Python binding to PortMIDI, such as the python-pypm or python-portmidi package.
Also installing PyGame >= 1.9.1 gives a Python binding to PortMidi.

This will work better I think, although the ctypes embedding should work as well.

from frescobaldi.

Hmmm.

Pygame is installed:

[frescobaldi-2.0]$ rpm -qa | grep pygame
pygame-1.9.1-2mdv2010.1

So what you are saying is that it should be picked up instead?

I'll give the other bindings a go and see what happens.

Regards,
Richard.

from frescobaldi.

what happens if you do this? Does Frescobaldi use the same Python as Pygame is installed for?

$ python

from pygame import pypm

from frescobaldi.

Python and Pygame are in sync. BUT:

Type "help", "copyright", "credits" or "license" for more information.

from pygame import pypm
Traceback (most recent call last):
File "", line 1, in
ImportError: cannot import name pypm

Bingo!

So I guess the default install of pygame on this platform is somehow incomplete.

Recompiling it after minor tweaks to account for the more recent portmidi I installed did the trick. I now have midi playback (with no volume, but that is more than probably another external issue on this machine).

I'll check the other bindings, but the bad news is that none of them is available as installable packages, so again they will require compilation, which is not something your average user is going to do if he can avoid it.

Adding a check at least for now to forbid the usage of the ctype embedding on linux 64 bits is probably a good idea as well though...

Regards,
Richard.

from frescobaldi.

If possible, could you test if portmidi embedding via ctypes now works under 64bit Linux? I changed all c_long to c_int32 in the pm_ctypes module.
You can do this by changing the try_order variable at line 88 in portmidi/init.py in frescobaldi_app. (Put 'ctypes' in front to force usage of the ctypes binding).

from frescobaldi.

Wilbert Berendsen a écrit :

If possible, could you test if portmidi embedding via ctypes now works under 64bit Linux? I changed all c_long to c_int32 in the pm_ctypes module.
Will do in the morning.
You can do this by changing the try_order variable at line 88 in portmidi/init.py in frescobaldi_app. (Put 'ctypes' in front to force usage of the ctypes binding).
I had found that one yes.

Actually, using the ctypes embedding has pros and cons, the major pro
being less things to install, the cons is that it should be included
right into portmidi to make sure it follows the include files there...

But then, it does not seem like portmidi has evolved much in late years.

Out of curiosity: why not using pyrtmidi? It is built on top of rtmidi
and seems relatively active (well at least rtmidi is), and is supported
on linux, windows and macos. Better yet, it is multithreaded on all 3...

(ok maybe you tried and it failed miserably to do the job ;) )

Regards,
Richard.

from frescobaldi.

well at first I was intending to use the real-time features of PortMIDI (i.e. use the latency argument for Output and send timestamped MIDI messages). But later I used a thread myself to play the MIDI and send messages directly, which is also the way pyrtmidi works.

So now it would be very easy to change Frescobaldi to pyrtmidi. I'm even thinking about supporting both backends.

from frescobaldi.

OK, tested with the new ctypes on linux 64 and it works (I took the time to plug a soft synth in, so this time I even got to the point where there was real sound coming out).

Note that if the softsynth dies (taking its midi port down with it) it kills frescobaldi as well.

Regards,
Richard.

from frescobaldi.

Thanks for testing this.

Yes, the problem of midi ports disappearing while portmidi is using them is the next issue, but this also applies to the other portmidi bindings

from frescobaldi.