Wrong characters when typing in GNU/Linux ARM

As a short-term workaround you could try setting your system/keyboard language to English (US) or English (International) if it's currently set to something else. Obviously, you shouldn't have to do that in the long term and if other apps are working fine then this is something that needs fixing in MuseScore (or perhaps in Qt which MuseScore relies on for platform independence).

There must be some Qt test program that does nothing more than receive keyboard input and prints the letters or keycode to console.

none of those programs use Qt5 I believe (MuseScore 1.3 uses Qt4). Maybe test some simple program that uses Qt5 with keyboard output? A quick google search reveals to me https://github.com/selairi/mdiedit which is a text editor for Qt5, but you would have to clone that repo and compile yourself to test, which might be too much trouble for you...

Does anyone know of a simple Qt5 keyboard test program?

I compilied that mdiedit program for Qt on my C201 ChromeBook (which also uses ARMv7-A) running Arch Linux and uploaded that binary to my personal share https://efjz.in/index.php/s/wXAlK2qxRBJJCfN

If you could try running that program and let me know if you can type characters in, then that would tell me if the problem is indeed with MuseScore or with Qt5. Also go to "Help"->"About Qt" and tell me what version of Qt is says (on mine it says "This program uses Qt version 5.5.1").

EDIT: I just realized my binary might not work on your chroot since arch uses the latest Qt version, while Ubuntu is likely to be behind.

Can you check the version of Qt in MuseScore > Help > About Qt?

that binary is not something that needs to be installed. Just put it somewhere you can reach from your chroot terminal, cd to the directory, execute:

chmod +x mdiedit_qt551
./mdiedit_qt551

There is also a mdiedit_qt4 version which I compiled for qt4, which would be nice to also test.

BTY, please try what lasconic says above by going to musescore and checking "Help"->"About Qt" and letting us know what version of Qt it says.

try: chmod 777 mdiedit_qt551
or maybe prepend with sudo?

I apologise for skipping over your comment earlier. And sorry if this is being too complicated for you.

(BTW, for anyone else listening, I compiled that binary for QT5 in the makefile. I'm not sure if that binary will be compatibile with a machine runnign qt 5.4.2, although I could try downgrading my Qt and recompiling to test)

on Android you can't execute programs from an SD card. this is disallowed by Android for security reasons.

as a matter of technically, don't use the word "install" when all we are trying to do is just executing a binary. The chmod lines are supposed to make the binary executable (which are normally set non-executable when downloaded for safety). Now I'm thinking you might not have busy-box, which provides the chmod command.

well maybe that mdiedit_qt551 won't work if you don't have the latest qt5 version. What happens with the mdiedit_qt4 when executed from terminal?

ok. I'm afraid I'm making you do a wild goose chase, simply to test how Qt interprets your key presses. I was hoping that binary I compiled would work on your machine but clearly there are incompatibilities...probably due to different libaries. You could try compiling that test program yourself, but that is usually very involved and might not be worth your effort. Maybe someone else on this forum has a better way to nail down your keyboard issue? All I can suggest at this point is to try installing some other Qt programs that are already packaged for your Ubuntu from this list: https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt and see if any exhibit the keyboard problem (and also report the version of Qt). That will tell us if MuseScore is at issue or if it is Qt or the chroot.

I just realized there is the kate text editor which uses Qt. Can you install kate by typing:

sudo apt-get install kate

and then run it by typing

kate

and then trying to input with keyboard, and also go to "Help"->"About Kate"->"Version" and reporting what number it says for Qt.

Nevermind...that is going to install way too many dependencies.

I finally found a simple Qt text editor for ubuntu that won't require too many dependencies called "juffed" that you might be able to install with:

sudo apt-get install juffed

and let me know if you can type anything and the Qt version.

EDIT: I also found a newer Qt text editor "tea" you might be able to install with

sudo apt-get install tea

If were to report to Qt, I'm sure they would want you to try with the latest Qt release installed, because this might be an issue that they already know and have fixed since Qt 5.4.2. I think having you compile the latest Qt dev from source would be out of the question because would take forever. Does anyone know of an easy way to install latest Qt dev builds inside DusanP's Ubuntu chroot on android?

Arch linux always has latest Qt libraries (5.5.1) as compiled binary, so if you're feeling adventurous you can try installing an archlinuxarm chroot, and seeing if musescore works with keyboard...but I must warn you arch linux is not for faint-of-heart.

Ideally you would try installing Qt 5.5 and see if that fixed the problem, but it doesn't look like that's possible because there is no Qt 5.5 package for Ubuntu Wily (15.10) and you can't get it directly from the Qt website because they don't release ARM packages.

Unfortunately it looks like there's no option but to wait for the time being. When Ubuntu Xenial (16.04) arrives it will have Qt 5.5 in it's default repository, so you can try upgrading then. But remember, that's just something to try; we don't actually know whether the bug is fixed in Qt 5.5.

Ubuntu Xenial (a.k.a Ubuntu 16.04) won't be released until April. April is the 4th month - that's what the "04" stands for. (Ubuntu versions ending in ".10" are always released in October - i.e. the 10th month.) If you have Ubuntu Xenial installed it must be an alpha (developmental) release. It's possible that the VNC problems will be fixed in the actual release.

Qt is a common dependency, so you can be reasonably sure that the latest version will be packaged for ARM in time for the official release of Xenial, and I don't think that it would happen any sooner if you contacted them.

Your setup is extremely rare (Ubuntu via chroot via Android running on ARM) so there is a high likelihood of something not working properly. It may indeed be best to try a distribution with more up-to-date packages, like Arch.

>> packages were retrieved, but not installed

could you elaborate. Are you saying that you tried downloading Linux Deploy's minimal arch linux base image but that that download failed. Or are you saying that you were able to get a minimal arch linux runninig, but that pacman failed to fetch any packages?

>> Can it happen that my tablet architecture is not suitable for Arch Linux?...Ubuntu in the Linux Deploy, I used the architecture armhf. The closest was armv7h, but installation did not happen.

Well I believe armhf in debian speak is ARMv7 with hard float ABI, and armv7h in arch linux arm speak is ARMv7 with hard float ABI, so those should be the same ISAs, and so your tablet architecture should be suitable for arch linux.

You said your computer is "Android tablet with ARMv7 (Prestigio MultiPad 7.0 HD Duo)". For reference purposes, could you let me know what version # of android and if you are running a custom or stock rom.

hmm...I don't know why packages not installed. The cpu microarchiture is Cortex A9, which implements ARMv7 ISA and has floating point (the "h" stands for hardware floating point) and I believe the "l" is for little endian, which the cpu should understand if told.

I might have a look into it myself on one of my own androids...my cellphone is Samsung S3 i9300 which has an Cortex A9, although I'm on latest android v 6.0.1, kernel 3.0.101-CM-g6b99703 on Cyanogenmod 13, but I should be able to replicate your steps installing Ubuntu 12.04 with this Linux Deploy program (I'm going to use release version 1.5.5 )...

I'm making a note that my busybox says my architecture is "armv7l" ("l" for "little-endian memory word layout"), although I'm downloading the "armv7hf" ("hf" for "hardware-floating point application binary interface") ubuntu wily. (Note that hardware float vs software float and little-endian vs big-endian are two separate issues...I wish everyone would use the same standard naming scheme. Regardless, I'm pretty sure you and I are on the same architecture.

a lot of these problems installing chroots with Linux Deploy are best helped by asking at https://github.com/meefik/linuxdeploy/issues because I wouldn't know. I'm trying to install chroot myself with Linux Deploy now, but having issues.

(FYI, I've installed a choot in ~5years ago when I first got an android, and I remember executing the MuseScore 1.3 in a debian lxde chroot via VNC on a Galaxy Note II maybe 2 or 3 years ago, although I remember it being practically unusable. I do want it to work, so I'm willing to look into any bugs for which we can determine MuseScore is at fault.)

regarding Linux Deploy arch linux, I'm running into your same issue where it retrievies packages list, but then has a filesystem ... fail when retrieving base packages, and then closes with <<< install...

While you're doing the arch install, please copy any configuration information here, so I can try to reproduce using your same steps.

According to the Downloads page the command you need to run to install MuseScore on Arch Linux is:

pacman -S musescore

But I don't see any ARM packages listed here, so if that doesn't work then @ericfontainejazz can tell you where he got his copy.

Musescore is in the arch Linux arm repos. Make sure to type:

sudo pacman -Syyu

to update the repos and system, before trying to install musescore.

I have built a debug build on recent git master with some small modification I had made...you can download here, and should be able to execute (might have to chmod +x):

https://efjz.in/index.php/s/s2HODcBEXtxZ4or

I'm marking this as closed, based on the conclusion that the bug was something in an earlier version of Qt that has been fixed by Qt already. So that means people using debian or ubuntu will have to wait (or use Qt testing builds) if they experience this issue.

Please could you check which version of Qt is installed so that we be sure that's what fixed it for you?

I'm impressed with your determination to have come so far without giving up! Unfortunately, if the long stem bug hasn't been fixed in the Arch package then there is no way for you to get hold of it, except by compiling yourself, until whoever compiles the Arch packages gets around to fixing it.

Your choices are:

1. Compile MuseScore yourself.
2. Contact the Arch maintainer to have the stem fix applied.
3. Wait for the Qt 5.5 packages to be released for Ubuntu Xenial so that I can backport them for Wily.

The quickest option would be to compile yourself by installing the source code package that corresponds to the 2.0.2 binary package you just installed, applying the fix, and recompiling. However, if you've no experience doing this then it can be quite tricky.

If any Arch developers are reading this then the fix appears to be as simple as adding this patch to the list of patches in this file. Unfortunately, I don't have an ARM system on which to test the build so I can't do it myself.

(Accidentally reopened this because my post crossed with @ericfontainejazz's post).

Files on Linux that are named like lib*.so* are shared libraries (pre-compiled bits of code that perform common tasks and are shared between different programs so that each program doesn't need to rewrite the relevant code). It looks like libvorbisfile.so.3 is missing on your system, but you can see if you have any version available using:

ldconfig -p | grep libvorbisfile.so

If not, or if you have a version which is too old, you will need to install it. I don't have Arch, but presumably the command would be:

sudo pacman -Syyu
sudo pacman -S libvorbis

Maybe @ericfontainjazz can confirm this?

Ah, I think you edited your previous comment while I was typing mine. If you haven't installed MuseScore from the Arch repo yet then you will need to do so because that will also install all of its dependencies (i.e. the libraries it needs). When you try running the program, make sure it is really @eric's file that you are running and not the Arch version.

@DusanP,

as a matter of technicality, MuseScore nightly builds are numbered "2.1.0", not "2.0.1" (which was released last May).

As you have figured out regarding installing libraries, what you figured out with "pacman -S musescore" then "pacman -R musescore" will do the trick. It will not be under the start menu, and I wouldn't bother trying to put it there. In fact it would be best to open a terminal and execute musescore from terminal since the debug build will print text there, which will be useful for the inevitable crash. Oh, and please report any crash or bugs with reproduction steps.

Actually, making it appear in the start menu isn't too hard. Simply create a text file in ~/.local/share/applications called "musescore.desktop" and paste in the following:

[Desktop Entry]
Name=MuseScore Debug Build
GenericName=Music notation
Comment=Create, play and print sheet music
Exec=/path/to/your/debug/build/mscore %F
Icon=musescore
Terminal=false
Type=Application

Change the "Exec" line to point to the debug build (keep the "%F" at the end of the line) and then make the file executable (chmod u+x musescore.desktop). Note that the ".local" directory begins with a dot "." and will therefore be hidden on Linux.

That will put it in the start menu (you might need to reboot to see it) but if you want to give it an icon then just pick one of these SVGs and save it as "musescore.svg" in ~/.local/share/icons/hicolor/scalable/apps. If the icon doesn't show in the start menu after a reboot do:

gtk-update-icon-cache -tf ~/.local/share/icons/hicolor/

Actually, making it appear in the start menu isn't too hard. Simply create a text file in ~/.local/share/applications called "musescore.desktop" and paste in the following:

[Desktop Entry]
Name=MuseScore Debug Build
GenericName=Music notation
Comment=Create, play and print sheet music
Exec=/path/to/your/debug/build/mscore %F
Icon=musescore
Terminal=false
Type=Application

Change the "Exec" line to point to the debug build (keep the "%F" at the end of the line) and then make the file executable (chmod u+x musescore.desktop).

Notes:
1. The ".local" directory begins with a dot "." and will therefore be hidden on Linux.
2. The Exec line must contain a full path without aliases. (E.g. "/home/dusan/bin/mscore" and not "~/bin/mscore" or "$HOME/bin/mscore")

That will put it in the start menu (you might need to reboot to see it) but if you want to give it an icon then just pick one of these SVGs and save it as "musescore.svg" in ~/.local/share/icons/hicolor/scalable/apps. If the icon doesn't show in the start menu after a reboot do:

gtk-update-icon-cache -tf ~/.local/share/icons/hicolor/

If you experience any problems with MuseScore then run it from the Terminal to see the debug information, like @eric said.

regarding chroot audio, are you able to hear sound when you run any other audio programs in the chroot? Might be a limitation of the chroot (are you going through a vnc?). Here (https://github.com/meefik/linuxdeploy/issues/56) meefik said some devices work out of the box with audio, and someone else there had to use KDE to get audio. (KDE uses pulse-audio, while LXDE is just alsa by default, so maybe need to use pulse-audio). But I would bet audio would be choppy at best.

You should be able to hear it now. If not, try these steps, checking for audio after each step:
1. Try launching the debug build from the command line with the "-F" option to do a factory reset.
2. Try all four sound servers listed in MuseScore > Edit > Preferences > I/O.
3. Try installing either "pulseaudio" or "alsa" using pacman and then repeating step 2.

Eric and I are not on the core team so we don't have a say about Android. However, as someone who follows the project closely (and who has developed Android applications in the past) I would say that this is extremely unlikely in the near to mid-term, but may happen a few years down the line. It is a commonly requested feature, but the difficulties of programming for Android, combined with the need to completely redesign the user interface for touch-based input make it impractical for the time being.

I'm thinking about how audio from musescore inside the chroot might be delayed and choppy, due to the overhead of sending the output wav through the vnc, loopback network interface, then through android system. One simple solution is to lower the bitrate and samplerate, so less data needs to be processed.

I wanted to make a note about an idea to have musescore send raw MIDI messages through the loopback network interface, to be synthesized by an Android app and directly outputted via Android's audio output API. The android app could also be used as a bridge to the phone's USB port, allowing an external keyboard as input, or to send the midi to an external hardware synth (some keyboards have synth built in - which would alleviate much of the processing load). I know pulseaudio can send wav over the network (I've even been able to install a pulseaudio sink on my wifirouter), but I don't know if pulse audio is designed to send midi-messages over network (which would require a pulse audio listener implemented on android), and I haven't looked into whether jack or portaudio has such a thing (I see alsa has aseqnet but I don't see any android implementations). A google search also reveals open midi network protocol like RTP-MIDI or QmidiNet for linux, but I suppose would have to add code to musescore and implement an android listener. The Android API actually has https://source.android.com/devices/audio/midi.html but I don't think that will communicate over network.

That also leads me to consider the following method to unofficially distribute the full musescore editor to android: create a minimal linux image to be installed by LinuxDeploy (or another chroot installer like it) which contains the minimal set of dependencies required to run musescore (wouldn't even need a desktop environment like lxde...just need startx), along with an android midi-synth...could possibly even fork LinuxDeploy and add capabilities to synthesize the midi it receives from the chroot, so is self-contained. Of course would require root.

I might start a second post on that once I evaluate the difficulty, as this thread is closed. But I'm curious to know how well musescore works on your tablet chroot.

You're welcome!

Having re-read your previous post I'm not sure whether you meant that it's just MuseScore that doesn't make sound in the chroot, or whether none of your programs have sound. If none of them do then we probably can't help you, but if it's just MuseScore the solution is probably as simple as one of the one's I posted above. E.g.:

/path/to/mscore -F

Alternatively, try exporting your score in a audio format such as MIDI, MP3, WAV or OGG and listening in a normal audio player.

If you want to listen from within Android itself you could download the MuseScore app (playback only) or export as an audio file. You could also upload to MuseScore.com and listen there.

>> "People on the web sugest installing KDE enviroment instead of LXDE"

As I said in #60, maybe need to use pulse-audio. I don't think you need to install a full KDE (which is much more resource-hungry). Just install pulse-audio from LXDE:

sudo pacman -S pulseaudio

and may a pulse audio volume controller:

sudo pacman -S pavucontrol

and then in musescore I/O audio preferences select pulse audio. But that is just a hunch.

Regarding touch input, I know that Qt has a touch input capabilities, but I don't think implementing that is high priority for musescore. My recommendation is to get a bluetooth keyboard an mouse (which should be supported by LinuxDeploy) and use musescore just like on a desktop.

One last thing I was going to mention about audio...I find that on slow devices like raspberry pi, the cpu synth is really slow, so instead I output midi via usb to my yamaha clavinova and let the yamaha's hardware synthesize the midi. But trying to send usb midi out from inside the chroot is going to be way too complicated, so you are best just disabling audio if it is slow.

Sorry, I don't know much about non-blutooth wireless mouse/keyboard.

There are special OTG USB cables that can charge and have mouse/keyboard input, but you're on your own for that.

Regarding using your phone as input, I have had used the touchpad feature of KDE-connect https://f-droid.org/repository/browse/?fdfilter=kde&fdid=org.kde.kdecon… between my andoird and desktop.

Musescore can work to some degree without a mouse. esp if just doing single-staff chart. But I think there could be a few modifications to musescore, esp on things like the start page, to make it fully functional without a mouse.

I'm actually wondering now if someone has already made an android remote control for musescore. If not, this might be something useful. Would run on your smartphone and consist of an android virtual keyboard that is modified to have all the important keyboard shortcuts as buttons laid out just like the musescore window, with no need to press shift/ctrl, and contain a mouse touchpad, which talks over wifi to musescore. Oh and then maybe could act as the mythical remote midi synth I've been dreaming about to relieve some processing power from the weak device running musescore (again I don't know how feasable that is).

I haven't tried my chroot yet, sorry. I don't know the exact requirements for LinuxDeploy to work with audio. Did you make sure your mp3 program and musescore were configured to send audio through pulseaudio and do you see sound levels change in pavucontrol? Regarding gnome, if terminal doesn't work, then that is basically an indication that other things won't work...although you might try installing a simpler terminal like xterm or lxterminal.

regarding installing another terminal, at the end of my previous comment, I wrote: "Regarding gnome, if terminal doesn't work...you might try installing a simpler terminal like xterm or lxterminal".

Ctrl->Alt->F2 should put you into a full-screen terminal. (you may need to login with whatever user/password you set for your chroot).

Sudo might not be installed. Try:

su - root

And that should log you in as root user. Then you can install lxterminal as well as sudo:

pacman -S lxterminal sudo

have you verified that you see a soundfont listed if you go to View->Synthesizer? And when you press the play button, do you see the volume bar in the synthesizer move up and down when notes are played?

Well lack of midi module in android-linux kernel suggests that will be very difficult or impossible to get any sound out in an android-linux chroot. I'm wondering if that is for all android-linux kernels. According to https://source.android.com/devices/audio/midi.html only the most recent androids might have midi support:

Beginning with the Android 6.0 (Marshmallow) release, device makers can enable optional MIDI support in the platform.

I'm running android 6.0.1, since I'm using latest nightly CyanogenMod, so I might actually be able to use midi, but you might be out of luck.

I'm curious can you export score as .wav? Can you export score as .midi? Then are you able to open and listen to the score elsewhere, like on your computer?

I read this all very quickly but MIDI support on given platform has virtually nothing to do with MuseScore ability to play since MuseScore generates audio and send audio to the system. The MIDI stuff is completely internal. Or put differently, there is no MIDI out in MuseScore (except via JACK midi, but that's something different)

Did sound and terminal both work for you back when you were using the Ubuntu chroot?

Can you run "gnome-terminal" from the run box?

(accidental double post)

Lasconic is correct in #84, thanks for clarifying that.

I'm here to tell you that I've sucesfully run musescore in an android chroot and can hear playback sound and can input notes with virtual keyboard. I've done this not through VNC, which has overhead of compression and which requires a full desktop environment, but instead I've used XSDL, which is a basic X-Server that has a pulse-audio sink on it. I made amateur video https://youtu.be/7k2angBzfvY (although I could have made simpler), and put all the gory details in the video description and copied here:

@0:00 - I'm showing that I'm using the following settings for LinuxDeploy:
              - Distro: Debian
              - Distribution suite: sid
              - Architecture: armhf
              - Installation type: File on sdcard, auto calculate size, filesystem auto
              - User name, password: android, changeme
              - Desktop environment: I used LXDE here, but note that is should not be necessary to install full desktop environment if simply want to use one GUI application, in this case musescore...so could save on resources by selecting XTerm as desktop environment (which will just install XTerm as the only GUI application to start with).
              - SSH enabled
              - GUI enabled
              - Graphics subsystem: X Server
              - GUI settings: Display=0, X server address = 127.0.0.1
@0:20 - press back to get out of settings, and then press Start to mount and launch the image.
Next, I had to sudo apt-get update and then sudo apt-get install mscore (which installed 2.0.2 and all the needed qt libraries), which I haven't recorded in this video.
@0:29 - I open ConnectBot, and ssh into the chroot android@127.0.0.1 (which is the local host) and enter the default password "changeme"
@0:49 - I enter commands:
             - "export DISPLAY=127.0.0.1:0" (which indicates where the X-Server will be, since will connect to XSDL running on localhost)
             - "export PULSE_SERVER=tcp:127.0.0.1:4712" which is the address for XSDL's Pulse Audio server, which it tells me to use.
@1:29 - I try running mscore, but realize I forgot to start XSDL first, so complains could not connect to any display...
@1:35 - I start XSDL, and then go over some settings...For video settings I had to check auto-detect screen orientation and portrait/vertical screen orientation so I could use in portrait mode.  And for Audio buffer size I set to small, but note that I still had choppy and laggy audio regardless of buffer size.
@1:53 - I press back and then before the 3-second timer runs out to change resolution, I tap the screen, and then pick a screen resolution, and then a font size (I choose the smallest font I can read, so that the text in mscore isn't too big).
@2:10 - the x server is started, and in the background wallpaper it shows me the commands I typed in earlier (which I already did earlier in this video...but note that you should use 127.0.0.1 which is localhost, since the 192.168.0.11 ip address it displays here for wifi, but I don't want to send all the X data and pulse audio over wifi).
 @2:12 - I go back to ConnectBot (unforuntately in this video I had to reconnect since I somehow got disconnected, and then I re-start the image in LinuxDeploy)...so please skip over untill @3:51 when I finallay am able to type mscore from inside connectbot terminal.  Note that nothing happens in connectbot, but I have to switch to XSDL @3:57 at which point you see the musescore 2.0.2 popup window.  Note there is the annoying Loading popup bug, which has been fixed in 2.0.3, as well as the annyong long stem bug which has been fixed in nightly.
@4:21 I press a note, and you can hear it play back after maybe ~0.5 second delay.  Then I play the first measure...note audio is choppy.
@4:35 I verify that I am able to input notes using keyboard buttons, but takes closer to a full second for layout to update and note to sound.  I've also tested that I'm able to save & load scores.  Presumably anything that woks on a linux arm real machine should work in this chroot.

This device is running CyanogenMod 12.1-20160219_NIGHTLY-d2tmo running android 5.1.1 and linux kernel 3.4.109-cyanogenmod-g2cf3722

I'm veryfying that I'm able to reproduce the above steps on archlinuxarmv7h chroot (instead of debian chroot).

Also, note didn't need to install a full desktop environment, but all I needed to select in LinuxDeploy setup is :Desktop environment: = "XTerm", and "Select Components to install": "SSH server" (don't need to check the boxes "Desktop Environment" or "VNC server" or "X server"). Now convieably, I don't need an ssh server running if do these following steps on first boot:

ssh into the chroot (either ConnectBot via android@127.0.01 but only if you have a bluetooth keyboard, else it is better to ssh from a computer with a decent keyboard via android@whateveripaddressyourandroidis).

First, it is easier to create a script which exports the display and pulse server variables, so that can easily execute mscoreCreate a script start.sh and then copy & paste the following in (if use vi from terminal, press "i" to insert, and ":wq!" to write and quit):

#!/bin/bash

export DISPLAY=127.0.0.1:0
export PULSE_SERVER=tcp:127.0.0.1:4712
mscore

and make sure to

chmod +x start.sh

Now go to LinuxDeploy configuration, and enable "Custom scripts" and in "list of scripts" remove the script already listed and replace it with "/home/android/start.sh", and also in "GUI Settings" if I check the box "XServer XSDL" then it automatically starts XSDL when start the LinuxDeploy image, and since will start musescore from this start.sh, there is now no need to have an ssh server (so can remove from LinuxDeploy configuration).

Then

cd /home/android/Documents/MuseScore2/Soundfonts

and download the smallest soundfont available (listed on https://musescore.org/en/handbook/soundfonts smallest is TimGM6mb.sf2, but what I'd really like is something like a super small soundfont that is basically just a square wav to save on resources):

sudo pacman -S wget
wget http://sourceforge.net/p/mscore/code/HEAD/tree/trunk/mscore/share/sound/TimGM6mb.sf2?format=raw -O TimGM6mb.sf2

Then in XSDL in go to View->Sythesizer and add the soundfont TimGM6Mb.sf2 and set as default. Note, unforuntately, won't be able to close the synthesizer window, because we are just in X without a desktop environment, which means no minimize/maximize/close window buttons, and since the synth window si on top and since there is no default keyboard shorcut for it, there is no way to close it...so just force restart XSDL and then restart the LinuxDeploy image (hopefully this time will auto-start mscore and auto open XSDL). But I just realized it is easier to just edit the synth xml file from inside an ssh terminal, by editing

/home/android/.local/share/data/MuseScore/MuseScore2/synthesizer.xml

to replace FluidSynth soundfont with TimGM6mb (and to remove the unecessary effect which might cost some resources), so looks something like synthesizer.txt.

Also, mscore is much easier with a bluetooth keyboard and mice when inside android. But I was thinking about a simple usability solution for note input: one way is create a custom virtual android keyboard specifically to use with musescore android chroot which would contain a small piano keyboard (android let you create virtual keyboards with buttons shaped however you like!) and then have each button send proper command to the chrooted mscore (that might be a little hard...and maybe create buttons on the keyboard for each note duration, or maybe use the corresponding midi commands which can be set in MuseScore->Preferences->"Note Input"->"MIDI Remote Control").

I might also make a feature request to "UI improvements for running MuseScore without a desktop environment" which would do things like have all windows either have a way to close or be always docked, so that don't run into situations where you open up the synthesizer window and then can't close it (maybe specify a command at startup to invoke this mode). Or maybe it is as simple as making some xml configuration file.

To answer DusanP's query on how to install a terminal window without a working terminal window:

You can ssh into your chroot, and then exectue any terminal command, including sudo pacman -S gnome-terminal. You can ssh either from inside the android using ConnectBot, or from another desktop machine if you know the ip address of your android. But please read my comments #90 & #91 where I've managed to get audio playing on andoird using the program XSDL which is an X-Server that includes a pulse-audio sink (which allows you execute a shell command to direct pulse audio output to XSDL).

regarding how to close the Synthesizer window, I've discovered on desktop I can do Alt->F4. However, although my bluetooth keyboard for android has a "fn" button and a corresponding button "next song" with function "F4", unfortunately, I'm unable to do Alt->Fn->"next song" to issue the Alt->F4 command. Any other ideas are welcome. I also can't determine the criteron for why some mscore windows have a close button built into their qt layout, but others like Synth do not have a close button built in.

If it is choppy through XSDL, then I think it will be (more) choppy though VNC due to overhead.

The choppiness is simply a matter of limited CPU capabilites and the amount of data for audio. Note that the problem is not ARM, and I know that because I'm running mscore on a 1.98z Quad core ARM right now, and it is completely smooth. Let me summarize the datapoints we have between you and me:

My C201 native arch linux is Quad-core ARM Cortex-A17 @1.8 GHz and is very responsive!
My Samsung S3 phone chroot is dual-core Qualcomm Snapdragon S4 @1.5 GHz and is choppy :(
Your android tablet chroot is Dual-Core Cortex A9 @1.5 GHz, and you say is choppy :(
My RPi 1 (single core) @900Mhz is very choppy (but usable), and my RPi 2 @900Mhz (quad core) is a little less choppy.

So I think this means mscore is very close to being able to run smoothly in chroot on dual core 1.5GHz.

I am hoping there is a way to lower the synthesizer's drain on CPU. Like I said earlier, maybe use a super-lightweight soundfont (like square waves) for all instruments. Also maybe edit configuration to reduce the rendering bitrate & samplerate.

I wanted to mention on last configuration that I need to figure out how to easily set with the (remote) XSDL is to have the start.sh script querty the X-Server for width & height of screen, and have mscore preferences set size=@Size(%width %height) so can have a full screen same size as x-server. (note: usually people use desktop enviornments to figure out the width & height, but that is more difficult to figure out without desktop environment).

You could try all the different audio servers listed in Edit -> Preferences -> IO to see which works best. Choices are PulseAudio, PortAudio, ALSA and JACK. You'll have to install any you don't already have on your system.

XSDL has a non-standard interface: they've mapped the android "back" button to trigger their virtual keyboard. The way I'm able to stop it correctly is to pull down my notifications from top of my android screen, and then should see a tab for XSDL with a button labeled "STOP" which you can press.

address 10.0.0.6 is clearly the ip that the DHCP server on your Wi-Fi router is allocating for your android. While it is possible to send X data and pulse audio data over the wifi, you wouldn't want to do this if you are communicating just from inside your single android device. So it is better to just use the standard localhost 127.0.0.1 address (which is known as "loopback" interface...since whatever network packets are sent there from your android will simply loop-back and return to your android without actually traveling through air). Note, that if you want to for fun, you can run x-programs from any linux computer in your house and have their window and audio be on your android phone (just before you execute whatever program do export DISPLAY=yourandroidwifiip:display# and similiarly for pulse)!

Regarding the last letter in that address ":6" is the X-Server display number. There can be a different display number for every X-Server running on a particular machine, so that number might be different every time you execute XSDL. For me, it always gave me ":0" but if you are executing XSDL multiple times, it might be incrementing the display number, which would explain why it is giving you ":6". So waht you need to do is either reboot your android (so that next time XSDL would likely start with ":0"), or you need to change the ending part of export DISPLAY=127.0.0.1:0 into :6 (but I think restarting android and keeping display number :0 is easier).

Note: you do not need to restart the XSDL program every time that you want to restart your chroot. It is merly an x-server, and thus will display any windows from any computers on your network or android that send x windows to it.

Regarding shoogle's comment #99, I don't actually think that anything other than PULSE will work with this XSDL program, since XSDL is providing a pulse sink, but not a sink for any of those other programs. (FYI, one of the neat features of PulseAudio is that it is designed to work very easily over the network interfaces).

I think the problem is you need to use: DISPALY=127.0.0.1:6

Whenever you start XSDL, after loading and setting resolution, it will say:

"Launch these commands on your Linux PC:

export DISPLAY=IP:N
export PULSE_SERVER=tcp:IP:4712
metacity & gimp

To tunnel X over SSH, forward port 6000
in your SSH client"

Where IP is your android's wireless IP address, and where "N" is some small integer representing the display number which XSDL is hosting the X-Server at. For me, "N" is always 0, but for you it seems "N" is currently 6. Just use whatever "N" it is providing you.

NOTE THAT YOU DO NOT NEED WIFI. I'm am verifying right now that I can disable WIFI, then start XSDL (note it won't tell me any ip address...it just says Launch these commands on your Linux PC: To tunnel X over SSH, forward port 6000 in your SSH client), but I assure you that I'm able to simply use loopback interface 127.0.0.1.

Good you figured that out. Interesting how final digit of port number actually corresponds to display...I don't know if that is consistent behavior or not.

Interestingly, the guy that makes XSDL "pelya" says https://github.com/pelya/xserver-xsdl/issues/15 that:

XSDL accepts connections from amywhere, even from outside of your network. You may just specify DISPLAY=:0 for your chroot environment, it will use Unix socket.

And I've verified that I'm able to use just DISPLAY=:0 on my phone. Also this should be slightly faster than going through 127.0.0.1 I think (because don't need to wrap all the X data inside of unnecessary network packets, which is my understand of how communication through 127.0.0.1 works, which would also save on memcopys). "pelya" then says:

For best results, download this library to your chroot: https://github.com/pelya/cuntubuntu/blob/master/dist/libandroid-shmem.so?raw=true then do export LD_PRELOAD=/path/to/libandroid-shmem.so It will enable shared memory between XSDL and Linux apps, so they will draw a tiny bit faster.

Now I haven't tried that yet...will verify. It would indeed be faster by avoiding unecessary memcopys. I have made a feature request to have the text instructions indicate how to use localhost...see https://github.com/pelya/xserver-xsdl/issues/59

Regarding "The video size is incorect" I mentioned earlier that I'm looking into a way to figure out the X-Server's width & height, and then forward that to musescore. For the time being, you can edit the MuseScore configuration file (~/.config/MuseScore/MuseScoreDevelopment.ini or ...MuseScore2.ini) and in the section [MainWindow] change "size=@Size(1024 768)" to reflect whatever resolution you choose for your XSDL server.

Regarding "and I cannot close any opened window" I mentioned this earlier that unfortunately some of the popup windows like synthesizer will not be very easy to close when running just X without a desktop environment. I might make a feature request to facilitate this.

In addition to setting size equal to the resolution of your tablet, I would also suggest setting pos=@Point(0 0) instead of the default (10 10), and I also set maximized=true. So now I have a full-screen mscore without any pixels lost to top window bar or the DE's main bar. Here is what my .ini [MainWindow] section looks like after those changes:

[MainWindow]
debuggerSplitter=@ByteArray(\0\0\0\xff\0\0\0\x1\0\0\0\x2\0\0\x1\xf4\0\0\0\x32\0\
xff\xff\xff\xff\0\0\0\0\x2\x1)
maximized=true
pos=@Point(0 0)
showInspector=false
showPanel=true
showPianoKeyboard=true
showSelectionWindow=false
size=@Size(1280 720)
split=true
splitScreen=false
splitter=@ByteArray(\0\0\0\xff\0\0\0\x1\0\0\0\x1\0\0\0\x83\x1\xff\xff\xff\xff\x1
\0\0\0\x1\0)

Note, I'm discovering on internet that there is likely no easy way to query the X server for the width & height without using a desktop environment. So it seems that setting size in the ini will be the only realisistic way to get a full screen interface in plain X.

Ok, I tried out pelya's special library for rendering X directly to shared memory, and it works on my android (which is ARMv7) archlinuxarm chroot, but note that that library is precomipled for ARMv7 so won't work on earlier ARMv6 (but I think your tablet is good). Anyway, the instructions to use it would be:

start LinuxDeploy image
ssh into android@yourandroidipsaddress
wget https://github.com/pelya/debian-noroot/raw/master/dist/libandroid-shmem…
export LD_PRELOAD=/home/android/libandroid-shmem.so

and then can start musescore using the script (./start.sh). After downloading, you can just add the export LD_PRELOAD=/home/android/libandroid-shmem.so into start.sh before executing mscore.

For reference, I'm noticing shmem.so is printing debug messages to my ssh terminal, which seem to indicate that it is working correctly:

[android@localhost ~]$ ./start.sh 
initScoreFonts 0x22497b8
shmget: key 0 size 483916 flags 01600 (flags are ignored)
shmget: bound UNIX socket /dev/shm/000046ea
listening_thread: thread started
shmget: ID 0 shmid 46ea0001 FD 10 size 487424
shmat: shmid 46ea0001 shmaddr (nil) shmflg 0
shmat: mapped addr 0xaadb2000 for FD 10 ID 0
shm_remove: deleting shmid 46ea0001
shm_remove: shmid 46ea0001 is still mapped to addr 0xaadb2000, it will be deleted on shmdt() call
init Help from: 
shmget: key 0 size 1843200 flags 01600 (flags are ignored)
shmget: ID 1 shmid 46ea0002 FD 19 size 1843200
shmat: shmid 46ea0002 shmaddr (nil) shmflg 0
shmat: mapped addr 0xa2cb8000 for FD 19 ID 1
shm_remove: deleting shmid 46ea0002
shm_remove: shmid 46ea0002 is still mapped to addr 0xa2cb8000, it will be deleted on shmdt() call
shmget: key 0 size 717600 flags 01600 (flags are ignored)
shmget: ID 2 shmid 46ea0003 FD 22 size 720896
shmat: shmid 46ea0003 shmaddr (nil) shmflg 0
shmat: mapped addr 0xa23d0000 for FD 22 ID 2
shm_remove: deleting shmid 46ea0003
shm_remove: shmid 46ea0003 is still mapped to addr 0xa23d0000, it will be deleted on shmdt() call
shmget: key 0 size 38400 flags 01600 (flags are ignored)
shmget: ID 3 shmid 46ea0004 FD 23 size 40960
shmat: shmid 46ea0004 shmaddr (nil) shmflg 0
shmat: mapped addr 0xa5001000 for FD 23 ID 3
shm_remove: deleting shmid 46ea0004
shm_remove: shmid 46ea0004 is still mapped to addr 0xa5001000, it will be deleted on shmdt() call
QNetworkReplyImplPrivate::error: Internal problem, this method must only be called once.

easiest to just include "export LD_PRELOAD=/home/android/libandroid-shmem.so"
inside the start.sh file we created earlier, so looks something like (although with your display #):

#!/bin/bash

export LD_PRELOAD=/home/android/libandroid-shmem.so
export DISPLAY=:0
export PULSE_SERVER=tcp:127.0.0.1:4712
mscore

then ./start should set those variables correctly and execute mscore.

FYI, I'm currently looking at ways to have pulse audio speak directly to XSDL's pulse server (without going through loopback interface) but no luck yet (I'd like to do something similar to https://wiki.archlinux.org/index.php/PulseAudio/Examples#PulseAudio_fro… )

I've discovered that I can lower alsaSampleRate in MuseScore.ini and that reduces choppines of playback (simply because less bytes need to be produced and copied). Here is video playing reunion:

https://youtu.be/bUXapf8IpHY

I reduced alsaSampleRate from 48000 Hz to only 4000 Hz. For reference, 4000 Hz is just under the highest note (C8) of a 88-key piano (https://en.wikipedia.org/wiki/Piano_key_frequencies). So as long as notes don't get too high, isn't terribly an issue, although quality of note timbre will reduce due to loss of higher harmonics, and also the very highest notes will have their harmonics above 2000 Hz get aliased and mirrored back below 2000 Hz (you might be able to hear that aliasing the very end of reunion with highest notes). But that is tolerable.

Unfortunately, the audio still feels a little uneven...I almost feel as some measures are unintentially cut short so they are more like 7/8 measures.

Note that in that video I have an ssh terminal from my computer and when I press enter I'm executing ./start.sh, then you can see the splash screen appear on my android.

I would like to reduce the bitrate so use 8bit audio instead of whatever alsa is using as default (probably uses 16bit or 32-bit float?) to reduce processing demands even more. But I don't know of a way inside the .ini to reduce that...does anyone else know?

I timed the latency on my Samsung S3 I used in that video, and when pressing a note in Reunion, it takes close to 2 seconds for the audio to sound. And when inputting a note in Reunion, it takes close to 1 second for the note to display, and then another 1 second before hearing the note.

I think any modern flagship android will have no problem, though, as my S3 is close to 4 years old.

I've been investigating further, and I've discovered that this "pelya" github user is very prolific, and interestingly has made a version of GIMP+InkScape avialable on google play, which uses a debian chroot that doesn't require root (using some technique called proot). Other than that it basically uses this same XSDL of his that I've been using in this thread. Anyway, I'm trying out his debian noroot https://play.google.com/store/apps/details?id=com.cuntubuntu and it installs pretty quick, no complicated configuration, and has presented me with a nice debian jessie desktop. I first tried apt-get musescore, but that didn't work, so then I ran apt-get update and then apt-get upgrade (although the upgrade takes forever, and may not be necessary to run musescore). Musescore 1.3 installs and runs, but unforutunately, I have yet to get audio working. I've tried vmpk which says can't create ALSA, and qfluidsynth says can't create jack. So I'm going look into that later. Interestingly it is not a full chroot, so some of these things like audio might be a little more difficult. I notice that he is using that libandroid-shmem.so library cuase I see those similar debug messages being used. I'll try looking into audio a bit more, and might ask him a question on his github.

what you typed directly into terminal should work.

I say it is easier to put things into a script and save the script as a file. That way whenever you want to execute mscore, you don't have to type everything again.

Alternatively, you can put those export lines inside ~/.bash_profile so that whenever you start a terminal, those variables are set.

I realize the mistake: LinuxDeploy will execute the start.sh script we made as the *root* user, however the MuseScore preferences file we edited was the regular *android* user.

To use the same settings for root & regualr android user, after closing quiting musescore, type the following into an ssh terminal:

sudo rm /root/.config/MuseScore/MuseScore2.ini
sudo ln -s /home/android/.config/MuseScore/MuseScore2.ini /root/.config/MuseScore/MuseScore2.ini

If you run ./start.sh from ssh terminal, then you should see various messages printed to screen starting with "shm..." which should indicate that you are using the shared memory library to help out screen rendering.

I'm now realizeing by looking at LinuxDeploy messages when shutdown, that my start.sh script isn't really a proper startup script since it needs to have a startup and shutdown section.

let me preface by saying that I am making up these steps as I'm figuring them out, and that ideally I would make a clean static page of instructions once all the hiccups are figured out. Unfortunately right now some things are getting miscommunicated and out of order due to this thread.

FIRST: if you are just typing inside the ssh terminal, then you don't need to start with

[android@localhost ~]$ #!/bin/bash

as we are already inside a bash shell since we are in ssh terminal.

The next 3 lines:
[android@localhost ~]$ export LD_PRELOAD=/home/android/libandroid-shmem.so
[android@localhost ~]$ export DISPLAY=:0
[android@localhost ~]$ export PULSE_SERVER=tcp:127.0.0.1:4712

setup environment varialbes. To save time from typing in everything, I put in the start.sh script (but they could also be in .bash_profile).

your next two lines:

[android@localhost ~]$ cd /usr/bin
[android@localhost bin]$ ./mscore

could be simplified with just:

[android@localhost ~]$ mscore

since /usr/bin is always in $PATH.

Now since you are running as regular user "android" and not as root user "root", then it is not necessary for you to do those final two lines:

[android@localhost ~]$ sudo rm /root/.config/MuseScore/MuseScore2.ini
[android@localhost ~]$ sudo ln -s /home/android/.config/MuseScore/MuseScore2.ini /root/.config/MuseScore/MuseScore2.ini

The only reason I said to execute those two lines is incase you want to have a start.sh script which will automatically start musescore when starting LinuxDeploy image.

But what you do need to do before starting mscore is to change MuseScore2.ini in your user directory to modify alsaSampleRate to only 4000 Hz. You will need to know how to use vi editor if your are editing over ssh, so type in:

vi ~/.config/MuseScore/MuseScore2.ini

and then navigate to the line with alsaSampleRate, navigate right to the 48000 so that your cursor is directly over the "8", and then press the letter "x", and you should see that 8 get removed so alsaSampleRate is now 4000. Then save & quit by typing ":wq".

I see you updated your comment while I was typing. Please avoid doing too many edits, but when you do make an edit, please use words "EDIT:" so I know what is different, and instead of deleting what you didnt' mean to write, I prefer it when those words are just strikethroughed using html tags "del".

Looks like you copied and pasted some text, but I can't see it because this forum uses markdown formating. It it is best to enclose the text you want to display unformated by enclosing with html tags "pre".

See the Input format link below for more info how do use "pre" and "del".

like I said in #117, you have those environment varialbes correct, as evidenced by the fact that we see those shm messages on terminal window. But you will need to edit your regular "android" user's MuseScore2.ini settings to reduce alsaSampleRate to 4kHz.

I see your console output text now. Those shm library messages aren't errors, I think.

regarding errors on console, a lot of errors don't actually prevent mscore from executing. For instance, I get "QNetworkReplyImplPrivate::error: Internal problem, this method must only be called" but mscore still runs. Does that QXcb connection error prevent mscore from running?

Re changing the frequency to 4000 Hz: The shm library only facilitates rendering windows, not audio. It would be nice to have it help out with rendering audio (to avoid loopback interface), but pelya has not implemented that. In order to change frequency to 4000Hz, you have to manually edit the MuseScore2.ini file. FYI, you can do the same thing on your regular desktop linux if experiencing choppy audio.

you can google for "vi cheat sheet" to learn the basic commands for vi. It is a very useful text editor, especially if you only have access to a terminal, like when doing ssh. To change the 4 into 8, first navigate the cursor so it is over the "4", then press "r" (for replace), then press "8", then press ":wq" (which issues command Write and Quit).

You might be able to fiddle with the alsaPeriodSize (make sure it is power of 2, though), and maybe even alsaFragments. Changing those might help reduce (or increase) the latency you experience, but more discussion on that is on internet. Unfortunately sound is bad with 4kHz, but feel free to experiment and find something that doesn't sound too bad while isn't choppy. For editing on android, only just need something usable (i.e. can hear the pitch, volume, articulation, and can distinguish instrument) even if doesn't sound great.

Not to start a flame war... but you might find nano a bit easier to use than vi because it doesn't have any special shortcuts you need to learn in order to edit. It has a few shortcuts, but they are always displayed at the bottom of the terminal screen.

The only ones you need to know are:

• ^O (i.e. Ctrl+O) - save (overwrite) the current file
• ^X (i.e. Ctrl+X) - exit

To have full desktop environment, youd best use LinuxDeploy config with LXDE (maybe create a new image, since don't want to loose what is working...but there might be hiccups as I recall, audio might be difficult, and I might not be able or want to help figure that out again.)

pelya did just release a new version of XSDL, but there should be nothing you need to change to get audio...I've verified that I'm still able to use my ./start.sh command and can playback.

FYI, pelya added instructions on the background screen of XSDL, in response to my request (which is why you got the googleplay update):

https://github.com/pelya/xserver-xsdl/issues/55#issuecomment-188424183

So now it says "If you run Linux in chroot on this device, run: export DISPLAY=:0 PULSE_SERVER=tcp:127.0.0.1:4712", so whatever it says on your XSDL screen should be what you want...

>> "All of a sudden audio started to work... In the afternoon I tried alternative X-servers, none of them worked reg. audio and they probably hurt my tablet."

The other x-servers might be getting in the way. My advice is remove them all except for XSDL. I am very impressed with XSDL because it has done these important things (like direct memory copy and pulse audio support) which I haven't found in any other android x-server or vnc.

>> "What is please the command to start the complete desktop enviroment in ConnectBot, please?"

If you configued LinuxDeploy to use:

Desktop Environment => something other than XTerm
Select COmponents => ensure DesktopEnvironment is checked
GUI Settings => Display=0 (or whatever XSDL says), X server address = 127.0.0.1, and check XServer XSDL

Then I don't think there is any command you have to type into ConnectBot. The desktop should display on your XSDL automatically when you start your LinuxDeploy image (I would recommend first starting up XSDL before starting LinuxDeploy image, so X server is ready and waiting). However, this won't be getting the sharedmemory feature. And then there is still the issue of running mscore through pulse audio. In order to do that, you would have to either start musescore from a gui terminal inside your desktop environment, but first type "export PULSE_SERVER=tcp:127.0.0.1:4712" before typing mscore. You might try putting that command inside your .bash_profile so all desktop apps know where to send audio.

>> "Is the main reason that audio now works with MuseScore that XSDL has a pulse audio support?"

Pulse audio helps out tremendously because it is designed from the start to work over network interfaces. (Look at the first words of https://en.wikipedia.org/wiki/PulseAudio which say "PulseAudio is a network-capable sound server").

>> "But when I use bVNC (or other VNC) without audio pulse audio support, why do I hear mp3 then?"

ALSA audio is (1) being rendered & mixed in the chroot, then (2) is (possibly) being compressed in order to (3) be sent over the loopback interface and then (4) (possibly) be uncompressed. So yes VNC can handle alsa.

But when dealing with PULSE, I think it cuts out a few steps because it is basically (1) render audio to PULSE, then (2) send over loopback interface to PULSE_SERVER. ALSA is really a hardware driver, but since we are in a virtual environment inside the chroot, we don't need to be interfacing with virtual hardware audio devices.

My impression is that there are just a few more steps when dealing with ALSA->VNC, versus just PULSE.

But don't quote me about VNC doing compression (I don't know if it always does that...but if you look at the background wallpaper you will notice that the VNC downsamples the color scheme, so VNC does indeed compress visuals, but then again there are ways to disable that VNC compression). But I have to admit I don't really know current situation and full story.

>> "bVNC displays MuseScore much better than XSDL"

I haven't tried bVNC, but I doubt that. XSDL is rendering as is direct through shared memory (if that library is used), so should be faster. Are you referring to the lack of a Desktop Environment (note you can use a desktop environment with XSDL).

I apologize if I'm proliferating mis-information. There are a lot of things going on in background, and I'm not fully aware. Ideally we'd be able to take control of and write directly to android's framebuffer and audio out.

I don't know...never used Zynaddsubfx. You should be able to use Jack with MuseScore, and then use qjackctl (install with sudo pacman -S qjackctl) and then make a connection from MuseScore to Zynaddsubfx. FYI, searching the forums yields https://musescore.org/en/node/10969 but that is a bit old.

The problem you might be experienced is simply a midi channel & port number issue. Make a note of which instruments your are using in musescore, and look up their midi channel/port numbers, and make sure those numbers correspond to input sources that Zynaddsubfx will generate sounds for.

For these generic support with musescore, you're probably best getting a response if you post to the regular support forum. I closed this issue long time ago, and probably most everyone else has probably unfollowed this thread by now.

I'm would like to know why Qsynth runs significantly faster than mscore's built-in synth in this situation. At first I was thinking maybe this is because Qsynth is a seperate thread, but then looking at https://github.com/musescore/MuseScore/blob/cd6dd3edd7a524517682806799f… I see that the musescore sequencer is a seperate thread too. Does anyone have ideas? Maybe is Qsynth using simpler computations? Or maybe is there some performance bug with musescore synth???

I might need to do some careful timing experiments to determine if what is at fault.

In your above case, I might want to try having QSynth use pulse audio as output to the XSDL server, which would reveal whether it is truely QSynth at fault, or the pulse-audio implementation.

The symptom you describe is what happens if you try running the executable file from some location other than where it is actually installed to. That is, if you have a MuseScore installation in /usr/local, but you try running an "mscore" executable located in ~/bin or whatever, then it won't be able to find the necessary support files. It is important to fully install MuseScore and to run the executable from the installed location. You don't have to "cd" there; the executable just has to be located there.

you can always goto Edit->Preferences and foricbly replace the style directory with the regular 2.0 install style directory (something like "/usr/share/mscore-2.0/styles/"), instead of installing the debug build.

Possibly the test executable is using a different set of preferences and is looking for the style folder somewhere else. You might try running it with "-F" to make sure it gets the defaults. And, hmm, I would expect the default installation to be in /bin. As far as I know the default for 2.0.2 on Linux is /usr/bin, although maybe that differs by distribution.

It's probably best to ask for further help on the support forum where others will be able to see - there's only a handful of us who will see posts made here.

DusanP is just using something I built a month ago with "make debug". I don't think it will have the mscoreGlobalShare variable set to anything meaningful, which is why I said to just use the mscore 2 style directory.

Regardless, hopefully soon (~week) will get nightly builds for ARM AppImage up and running, which should have a valid style directory on first execution, so I'd suggest wait.

In the meantime, we should probably officially close this thread.

Probably easiest to wait untill we get an official arm nightly build running.

Wow, a second page of comments - quite an achievement!

We'll post here when the ARM builds are ready, but if we forget for some reason then check this page in a week or two: https://bintray.com/musescore/nightlies-linux. Currently there are builds for i686 and x86_64 architectures (32 bit & 64 bit Intel/AMD). When ARM builds arrive they will be labelled something else, probably armv6, armhf or something like that. Run the Linux commands arch or uname -m to find out your architecture, but be aware that the nightlies might still work even if they are called something slightly different to your architecture (e.g. armv6 executables will run on armv7).

Also, look out for the release of MuseScore 2.0.3 (it will be announced on the homepage) and see if there is any information about ARM builds (we can't promise there will be any news, but there might be). Please upgrade to 2.0.3 if you can and delete Eric's development build. If you continue using a development build you may run into compatibility problems if the file format changes before the release.

DusanP, I finally got the ARM AppImages (i.e. nightly) built on Travis & uploaded to bintray. Please test this out:

https://bintray.com/ericfont/nightlies-linux/MuseScoreNightly-armcross-…

and report back to me your system configuration and what works and what doesn't work. (If you can test ALSA, Pluse, and whatever else, that would be useful.

Note you will have to make that download executable, for example by typing:

chmod +x MuseScoreNightly-201603261315-armcross-9b68d75-armhf.AppImage

Also it would be useful if you can report back output of check-depends:

./MuseScoreNightly-201603261315-armcross-9b68d75-armhf.AppImage check-depends

And it'd be great if you'd continue this discussion in the Forum, this issue became virtually unreadable, due to its length

Discussion continued at https://musescore.org/en/node/103726.