Configuration

MIDI ports

MIDI ports provide an abstraction layer for your MIDI hardware and synthesizers (which can be both software and hardware synthesizers), and other MIDI applications. Ports are numbered. In order to produce sound, each MIDI track is assigned to exactly one MIDI port, to which the MIDI events are then sent.

The advantage of this abstraction layer is that if your system changes, for example you change MIDI hardware, then you need only modify the ports instead of all the tracks using those ports. This is similar to the audio input and output track abstraction to the outside world.

MIDI port configuration

In the midi/softsynth configuration dialog, you must map the port numbers to the actual devices (by selecting ALSA or jack midi ports, or synth plugins).

Try the context menu of the “Port” column of some MIDI track to see and change the settings per track. If you use a soft synth, right-clicking the Track type column of the synth or any midi track using the synth lets you launch the synth’s GUI (generic and/or native if available).

Columns in the MIDI configuration ports list:

Audio settings

Minimum control period

Plugins can usually process an arbitrarily small (or large) amount of samples. If some plugin control value changes continuously, to provide ideal listening experience, MusE would need to call the plugin 44100 times a second, asking for one single value at a time. With the minimum control period setting, the user can force MusE to ask the plugin for at least N values. Setting this value to 64 would in this situation make MusE call the plugin 689 = 44100/64 times a second, asking for 64 values at a time. While doing this will reduce accuracy of control changes, it may also reduce CPU usage, because calling the plugin more often, requesting smaller chunks, is more expensive than calling it seldomly, requesting larger chunks.

If you have no performance problems, or if you want to do the final downmix of your project, setting this to a low value ensures fine grained parameter changes which could mean improved sound quality.

And conversely, if you’re experiencing performance problems, increasing this value might help.

HiDPI

MusE uses the Qt framework which has a fairly good support for HiDPI screens. So the MusE application itself should be scaled automatically, according to your screen’s DPI. If it doesn’t (e.g. the monitor is not properly recognized or your desktop uses wrong presets), you should still be able to set an appropriate scaling using the corresponding environment variables. See Qt HiDPI settings for more information.

The typical problem with HiDPI (which affects all existing Linux DAWs) are the native GUIs of the plugins. They use different UI technologies, many of them are old and hardly any has a proper HiDPI support. Qt normally opens the native plugin window with the current application scale factor, which can lead to ugly effects as most plugins ignore this setting.

To cope with these issues, a new parameter exists as of MusE 3.1 (Global settings -> GUI tweaks -> Revert native GUI scaling in HiDPI). When set, the size of the native plugin window is explicitly adjusted to fit non-scaling plugins.

As the behaviour of the plugins can be very individual, there is a possibility to override the setting on a per plugin basis. This can be done in the Settings found in the generic plugin GUI.

Some plugins ignore the window size set by the caller (MusE in this case) and resize their windows uncontrollably.