====================================================================
      MusE  ---  Linux Music Editor
====================================================================

Welcome to MusE, the open source MIDI/Audio sequencer.

MusE is distributed under the GNU General Public License (GPL).
Please check out the file COPYING in the src/ directory for more
details.


  =============================
      Features:
  =============================

      MIDI sequencing:
         - Realtime record/playback
         - Midi file import/export
         - Input filter
         - Support for internal softsynth plugins using
           LV2, DSSI, VST, LinuxVST and MESS
         - much more

      Audio sequencing:
         - Realtime Record/Playback several mono/stereo inputs/outputs
         - Graphical editing of automation
         - Support for LADSPA, LV2, DSSI, VST, LinuxVST plugins

      Technologies supported:
         - LASH - for session control with external LASH enabled applications
         - JACK - The Jack Audio Connection Kit can be used for audio and midi
         - RtAudio - basic audio input/output for Pulse, ALSA and OSS
         - ALSA midi
         - Plugin formats: LV2, DSSI, VST, LinuxVST, MESS
         - Support Inst(rument) Patch Library for enhanced fluidsynth features.
         - FLAM plugin guis.
         - Built on Qt5




,-----------------------------------------------------------------.
| NOTICE                                                          |
|-----------------------------------------------------------------|
| Some parts of MusE code are EXPERIMENTAL, and may well result   |
| in a CRASH, and who knows what other ill effects.               |
| RUN THIS SOFTWARE AT YOUR OWN RISK.                             |
`-----------------------------------------------------------------'

  =============================
      Requirements:
  =============================

      - CMake >= 2.4
          http:/www.cmake.org/HTML/Download.html

      - Qt: Qt >= 5.7.0 (development files)
          http://qt-project.org/
          MusE does _not_ compile with older versions
          For ubuntu packages can be installed via:
          sudo apt-get install qt5-default qttools5-dev qttools5-dev-tools

      - gcc >= 4.x.x or clang >= 2.9
          http://gcc.gnu.org/
          http://clang.llvm.org/

      - libsndfile >= 1.0.1 (development files)
          http://www.mega-nerd.com/libsndfile/

      - libsamplerate >= 0.1.0 (development files)
          http://www.mega-nerd.com/SRC/

      - JACK version 1 >= 0.103 (development files) or
        JACK version 2 >= 1.9.9.5 (development files)
          http://jackaudio.org/

      - LADSPA (development file ladspa.h)
         www.ladspa.org


  =============================
      Optional:
  =============================

      - ALSA >= 0.9.0  Advanced Linux Sound Architecture (development files)
          http://www.alsa-project.org/

      - fluidsynth >= 1.0.3 (formerly known as iiwusynth) (development files)
          http://sourceforge.net/apps/trac/fluidsynth/

      - libinstpatch >= 1.0    Instrument Patch Library (development files)
          http://www.swamiproject.org/

      - RtAudio >=5.0 audio input/output support.
          https://www.music.mcgill.ca/~gary/rtaudio/

      - LV2 (LADSPA Version 2) plugin support:

        lilv >= 0.22.0 (development files)
        sord >= 0.14.0 (development files)
          http://drobilla.net/software

        lv2 >= 1.12.0 (development files)
          http://lv2plug.in

      - LV2 Gtk2 User Interface support:

        Some LV2 plugins may provide a Gtk2 based graphical User Interface.
        To view them, the following is required (development files):
        gtkmm-2
         http://www.gtkmm.org
        gtk+-2
         http://www.gtk.org

      - DSSI     Disposable Soft Synth Interface (development files)
          http://dssi.sourceforge.net/

      - liblo    Lightweight OSC (Open Sound Control) (development files)
          http://liblo.sourceforge.net/

        (Both recommended - DSSI can use OSC, OSC alone does nothing, for now.)

      - dssi-vst        Support for DSSI vst plugins
          http://www.breakfastquay.com/dssi-vst/

      - LASH            Audio Session Handler
          http://lash.nongnu.org/
          Recently LADISH has been emulating it instead:
          http://ladish.org/

      - Python    The python scripting language
          http://www.python.org
          The remote control supports Python 3.
          See https://github.com/muse-sequencer/muse/wiki/python-remote-control.
          The bundled midi scripts ('Scripts', or 'Plugins' in earlier versions) require Python 3.

      - Pyro 4    Python Remote Objects
          https://pythonhosted.org/Pyro4/
          The remote control supports Pyro 4.
          See https://github.com/muse-sequencer/muse/wiki/python-remote-control.

      - PyQt5 is used by some of the bundled midi scripts ('Scripts', or 'Plugins' in earlier versions).


  Quick instructions for Ubuntu and similar distributions:

  =================================
      Building MusE under Debian/Ubuntu:
  =================================

    1. Install build tools:

       sudo apt-get install git build-essential cmake

    2 Get muse source (unless you already have it).

       Choose one of the below:
         a. Download the latest muse source distribution from
           https://muse-sequencer.github.io/

         b. Clone muse source:
           git clone https://github.com/muse-sequencer/muse.git

    3. Install libraries:

       sudo apt-get install\
         libsndfile1-dev\
         libsamplerate0-dev\
         libjack-jackd2-dev\
         ladspa-sdk\
         qt5-default\
         qttools5-dev\
         qttools5-dev-tools\
         liblo-dev\
         dssi-dev\
         lv2-dev\
         libsamplerate0-dev\
         libsndfile1-dev\
         libfluidsynth-dev\
         libgtkmm-2.4-dev\
         librtaudio-dev\
         libqt5svg5-dev\
         libinstpatch-dev\
         liblilv-dev\
         liblrdf0-dev\
         librubberband-dev\
         python3-dev\
         python3-pyqt5

    4. Change directory:

       cd muse/src

    5. Compile:

       ./compile_muse.sh

    6. Change directory:

       cd build

    7. Install in /usr/local:

       sudo make install

    8. Run:

       muse4

  =============================
      Generic building MusE:
  =============================

      - Download source from http://muse-sequencer.org/

      - Unpack the source somewhere.

        You may also try the various MusE development GIT branches for
         up-to-the-minute features and fixes, but they may be less stable.

      - To compile MusE, run the following commands from the
         top level directory where the source code was unpacked
         (the directory where THIS README FILE is found):

	    ******************************************************
        *                      Notice:                       *
        * A quick way is to run the ./compile_muse.sh        *
        * script in the same dir, it should perform the same *
        * steps for a basic setup without asking any         *
        * questions. If it fails you may be better off using *
        * the instructions below.                            *
        ******************************************************

        The build directory:
        --------------------
          Building in a subdirectory is recommended to keep the build directory separate from the source tree.
          So create a new subdirectory with a useful name like "build" or "debug" or "release":
            mkdir build
          Change directory (cd) to the new directory:
            cd build

        Configuration:
        --------------
          There are a few different ways to configure (notice the two dots):

          Type "cmake -L .." to see options, then compose "cmake <options>" yourself.
          Some <options> are:

            -DCMAKE_BUILD_TYPE=<type>
               <type> can be blank (to reset a previous cached type to 'empty'),
                Debug, Release, RelWithDebInfo and MinSizeRel.
               Release is recommended, to get optimizations.
               If no CMAKE_BUILD_TYPE is given at all, cmake uses either the previous
                cached value, or else 'empty' (plain or default system optimizations).

            -DCMAKE_INSTALL_PREFIX=<prefix>
               The installation <prefix> where the program is installed.
               The default is to install in /usr/local.

          Or type "ccmake .." (if you have it - text-mode GUI). It may be blank so hit
           'C' to first-time configure. Fiddle with yer options if ye so desire, then hit
           'C' to configure then 'G' to generate and exit, or 'Q' to quit without
           generating.

          Or there is also a desktop GUI for cmake called cmake-gui.

          Normally MusE builds its many internal modules as SHARED libraries and the
           executable file is small but it links to all those libraries.
          There is a special flag for building MusE as a more or less 'monolithic'
           application (one big executable) which forces MusE to build most modules
           as STATIC libraries and join them all in the final executable:
           -DMODULES_BUILD_STATIC

          --------------------------------
            *** NOTICE TO PACKAGERS: ***
          --------------------------------

          Some packagers of software like to ensure that there are no unresolved symbols
           in ANY shared libraries in the software, for example by using:
           -DCMAKE_SHARED_LINKER_FLAGS=-Wl,--no-undefined

          When using such flags, the -DMODULES_BUILD_STATIC flag
           MUST BE ALSO BE SUPPLIED otherwise there will be many unresolved symbol errors.

        Compiling:
        ----------
          After configuration, while still in the build directory,type:
            make

        Installing:
        ----------
          After compiling, type:
            make install (as root)
           or
            sudo make install

  =============================
      Running MusE:
  =============================

      Recommended setup:
      ------------------
        MusE is a realtime program which requires special rights to work properly.

      - Check if you are running a sufficiently new linux kernel > 2.6.x
        A modern, standard destop kernel should suit virtually all needs.
        For even stricter realtime performance a so-called 'low latency'
         or 'realtime' kernel may be available. Check your distro's packages
         for availability.

      - create an "audio" group if it does not already exists
        and put yourself into this group

      - For realtime priority, you may want to ensure either the file:
           /etc/security/limits.conf
         or
           /etc/security/limits.d/audio.conf
         contains:
           @audio   -  rtprio     95
           @audio   -  memlock    unlimited

        Some distros have a graphical menu or tool which does this for you.

      - Start jack, typically by using the qjackctl application.
        MusE can also be run without Jack. MusE will use a dummy audio
         driver if Jack is not detected, or the -a option is given.


      Running:
      ------------------
        start MusE by typing:
            muse4 <options>

          Some <options> are (complete list is printed by running muse4 -h):
            -h       help
            -v       print version
            -d       debug mode: no threads, no RT
            -D       debug mode: enable some debug messages
                                  specify twice for lots of debug messages
                                  this may slow down MusE massively!
            -m       debug mode: trace midi Input
            -M       debug mode: trace midi Output
            -s       debug mode: trace sync
            -a       no audio
            -A       Force inclusion of ALSA midi even if using Jack
            -P  n    set audio driver real time priority to n
                      (Dummy only, default 40. Else fixed by Jack.)
            -Y  n    force midi real time priority to n (default: audio driver prio +2)
            -p       don't load LADSPA plugins
            -I       don't load DSSI plugins
            -L       don't use LASH
            -l  xx   force locale to the given language/country code
                      (xx = de,en,es,fr,pl,ru,sv_SE)

      (JACK and all its clients (qjackctl & MusE) must run with the
      same user id)


      Startup troubleshooting tips:
      -----------------------------

      - Some rare distros might not load the alsa sequencer module by default.
        If necessary, load the alsa sequencer module with:
            /sbin/modprobe snd-seq

      - Timer accuracy for ALSA support:

        If ALSA support is enabled, a reliable source of timing is
         desired for playback of midi notes.

        By default, the timer is attempted to run at 1024 Hz (ticks/second).

        MusE will try the Real Time Clock (RTC) first.
        If that fails it will try ALSA timers instead - typically the
         ALSA High Resolution (HR) timer or the ALSA system timer.

        The RTC is recommended, with sufficient permissions, for best accuracy.

        To ensure you have permissions to use the RTC, on modern systems
         using udev rules, create this file if it does not exist:
           "/etc/udev/rules.d/40-timer-permissions.rules"
         and add the following lines to the file:
           KERNEL=="rtc0",GROUP="audio"
           KERNEL=="hpet",GROUP="audio"
         and, as stated in "Recommended setup" above, ensure you are
          part of the audio group.

        (The hpet is not supported, but that line can help other applications.)

        It is possible to use the ALSA system timer instead of the RTC,
         but it usually requires a kernel built with a 1000 Hz system timer
         (low-latency, realtime, or custom kernel as in "Recommended setup" above).
        With most desktop kernels, the system timer is limited to 250 Hz,
         while the HR timer is limited to 1000 Hz.
        On such distros, without modification, MusE should end up picking
         the 1000 Hz HR timer.

        But if you set your RTC as above, you can run even higher rates.
        See the Global Settings dialog for user-adjustable high rates.

        Run MusE in a terminal to see what it picks. -D option gives more info.


        (The following is old information! But may work for those without udev.)
        Make sure you can access the realtime clock (RTC)
            chmod 660 /dev/rtc
            chgrp audio /dev/rtc
        Make sure MusE can set the rtc clock:
            echo 8192 > /proc/sys/dev/rtc/max-user-freq
            inspect with:
            cat /proc/sys/dev/rtc/max-user-freq

  =============================
      Known bugs:
  =============================

      The odd wierdness happens and some things may not be completely implemeneted
      though we hope it is as stable for you as it is for us!

      If you differ in this opinion we are grateful for all reported issues.

      See the bug tracker for a better view of issues
      https://github.com/muse-sequencer/muse/issues



====================================================================
Let us know whether MusE works for you !!!
Have a look at the webpage https://muse-sequencer.github.io/ for details.

MusE is really not big on making developers do it the MusE way.
For good and bad (probably mostly bad) it's a bit of happy anarchy out there.
But whatever, it's a labor of love.

Anyway, maybe some things should be a bit more clearly defined so I started this
document with some pointers for best practices and procedures.

* STYLE *
whatever floats your boat. Okay, maybe try to keep it atleast somewhat consistent :)

* TOOLS *
MusE is highly dependent on Qt, mostly this is a good thing, especially as we want to
make MusE even more portable. So, when implementing stuff that requires some support
library, do check if Qt can provide the necessary functionality. Many times it can.

* DEVELOPMENT *


* RELEASE PROCEDURE *
When making a release there are some steps that should always be done to make the
packaging consistent and traceable.

1. make sure that version info is updated.
   CMakeLists.txt:SET(MusE_VERSION       "3.0.0pre1")
   CMakeLists.txt:SET(MusE_VERSION_FULL  "3.0.0pre1")

2. add a release-line to the ChangeLog (search for old ones for some format hints)

3. commit everything to git

4. now create the tarball from the build dir (could be a good idea to create a new build dir)
   $ make clean (otherwise the tarball will way too big)
   $ make package_source
   feel free to ctrl-c out of this as soon as the .tar.gz build is done as it contines to make
   a lot of variants that we do not use.

5. verify that the built package has the right name and can be built

   NOTE: if you are making a point release (e.g. 3.0.1) the file name is based of the path so
   the package will be called muse-3.0.tar.gz while it really should be muse-3.0.1. Easiest
   way to fix this (for now) is to untar the package, rename the folder (in this case) from
   muse-3.0 to muse-3.0.1 and tar it back into muse-3.0.1.tar.gz.

6. make a tag in git for this particular checkin when you are satisfied the release is correct
   From 4.0 release we use https://semver.org/ formatted tags.
   For instance 4.0 pre release 2 is 4.0.0-pre2.
   'git tag -l' lists all of the previous tags.
   Use git tag -a <tag name> to create an annotated tag.
   To push the tag to master: git push --tags

7. create a releasenote

8. upload both releasenote and tarball to the sourceforge page (or whatever is in fashion when
   it's time).
   Update: Currently we upload to both sourceforge (because we always have and it's not a lot of work)
   and to the Releases page on github.

9. Update the frontpage and news page at https://muse-sequencer.github.io/.
   The frontpage is html and resides a specific git repo.
   The news page is in the muse github wiki.

10.Update wikipedia to reflect the new release.

11. send out a release mail

V 0.0.1 03/26/2020 By Tim.


A mini review of the Operations and Undo system in MusE.
========================================================

Operations:
------------

During each audio cycle segment, a realtime audio thread
 processes audio and midi.

A block of audio and midi events are gathered to be played
 in the next segment to various outputs, while a block of
 incoming audio and midi events from the last segment are
 recorded from various inputs.

Various containers house all the audio and midi events
 in a song, from which the realtime process thread gathers
 the required events for the next playback segment.

When it is desired to alter the contents of the various
 containers which house all audio and midi events, and
 to do so from a thread other than the realtime thread,
 for example the GUI thread, the actual change must be
 synchronized with and take place in the realtime audio
 thread, otherwise these concurrent accesses will crash.

In a realtime audio thread it is forbidden to use code
 that may block or wait or take a long time, such as
 mutexes, memory allocations, or printing functions.

So MusE does not use any mutexes or locks of any kind
 in the realtime thread. Instead it uses synchronized
 OPERATIONS to make desired changes in the realtime
 process callback just before audio and midi are processed.

Example: To change a note in a list of notes in a song
 from inside a GUI dialog, an OPERATION is requested,
 and the GUI thread will pause while the realtime thread
 executes the request. The GUI thread resumes when the
 OPERATION is done.

Note that it is possible the realtime audio thread may NOT
 be running in realtime, for example if the audio system
 is not set up for realtime. MusE is fairly tolerant of
 that, but it is possible the audio thread may not finish
 before the GUI thread runs again, which may cause a
 concurrency crash if some list was being changed.
This is why realtime is important and why it is important
 to try to make changes as quickly as possible in the audio
 thread in case the thread is not realtime - if the changes
 are taking a long time in the audio thread, the GUI thread
 might run.


Undo/redo:
----------

It is desirable to have an undo/redo for many OPERATIONS.
And yet, not all OPERATIONS can be or need to be undoable.

So for many OPERATIONS, the request is sent to the UNDO system,
 instead of directly to the OPERATIONS system. The UNDO system
 remembers the OPERATION so that it can be undone and redone.

Still, some requests are sent directly to the OPERATIONS system,
 bypassing the UNDO system.

In addition, the UNDO system has the ability to process some
 requests WITHOUT remembering them for undoing, basically
 passing them on to the OPERATIONS system.
This is convenient for example when a list of UNDO OPERATIONS
 contains some OPERATIONS that should not be undoable. This
 eases the caller's composition of lists of requests, using
 only the UNDO system instead of working both the UNDO and
 OPERATIONS systems.

The UNDO system has a few tricks. It can combine previously
 executed commands into one list. It can reduce repeated
 similar commands to just one, such as when operating a mouse
 to adjust some value - only the last value at mouse-up is stored
 instead of storing hundreds of values in hundreds of commands.


Operations vs. Undo Operations
-------------------------------

A distinction should be made between OPERATIONS and UNDO OPERATIONS:
Although the UNDO system takes requests and composes and executes
 OPERATIONS, UNDO requests are not the same as OPERATION requests.
The caller does not pass OPERATION requests to the UNDO system,
 the caller passes UNDO OPERATIONS. Owing to the different nature
 of the two systems, the composition and structure of the requests
 is different. For example OPERATIONS system has the ModifyTempoList
 OPERATION, but the UNDO system has AddTempo DeleteTempo and ModifyTempo
 UNDO OPERATIONS.


Stages:
-------

Both the OPERATIONS and UNDO systems work in STAGES:

* OPERATIONS system:
The OPERATIONS system has two STAGES: A REALTIME STAGE followed by
 a NON-REALTIME STAGE.

The idea is that the caller composes an OPERATION beforehand in the
 GUI thread, then passes it to the OPERATIONS system where any
 realtime-sensitive changes occur in the REALTIME STAGE, followed by
 any non-realtime-sensitive code in the NON-REALTIME STAGE such as
 cleanups, safe deletion of memory no longer used, etc.

* UNDO system:
The UNDO system has three STAGES: A NON-REALTIME STAGE (1), followed
 by a REALTIME STAGE (2) which basically just calls the OPERATIONS
 system REALTIME STAGE, followed by a NON-REALTIME STAGE (3) which
 basically just calls the OPERATIONS system NON-REALTIME STAGE.

The UNDO system NON-REALTIME STAGE (1) is a convenient place where any
 non-realtime-sensitive code can by run BEFORE the REALTIME STAGE.
It offers a place to compose complex preparations for a request
 instead of the caller having to do it, trying to make the caller's
 job as simple as possible. For example memory allocation.
The OPERATIONS system has no such STAGE. The caller must compose
 the OPERATION and handle any allocation etc. although the system's
 NON-REALTIME STAGE can be used to cleanup, deallocate etc.


Altering lists vs. swapping them out quickly:
---------------------------------------------

In the OPERATIONS system's realtime code, the idea is to execute
 only the bare minimum code required to make the changes. Such as
 inserting in a list, or calling erase with an iterator that was
 already found in the GUI thread so that erase is 'ready to go'.
Before the OPERATIONS system was added, the UNDO system handled
 all of this, but it was ALSO executing some awfully heavy code.

But even though those list insert/erase techniques are as tight
 as they can be, they STILL may allocate or de-allocate memory,
 which is not realtime safe !


One way to guarantee very fast changes to containers (fixed time)
 is to completely swap them with another list, composed beforehand
 with the desired changes.
If the container happens to be a pointer-to, the pointer can be
 quickly, even atomically, swapped with another pointer-to,
  guaranteeing no hiccups or xruns in the processing.
If the container is NOT a pointer-to, unfortunately there is no
 pointer to swap, since the container is the object.
However some containers have a swap() method which has very fast
 fixed-time complexity, which really helps in this situation.

Note with this technique, the UNDO system does NOT store a copy
 of the container for each UNDO OPERATION in the UNDO history.
The UNDO system only stores the necessary CHANGES, saving memory.
When an actual Undo is performed, only then is a new replacement
 list composed based on those changes, and then swapped out with
 the original.


Several OPERATIONS have now been switched over to this technique.
One caveat and inefficiency is that with a very large container
 needing only a simple change, you will be making a copy of it,
  albeit only for a brief time until swapped.


Tempo, time signature, key, and other special operations:
---------------------------------------------------------

These three tempo, sig and key areas have very special needs
 due to how these containers operate. The code is somewhat complex.

In addition certain other operations have special needs and have
 more complex code.

MusE can create LADSPA GUI's (graphical user interfaces) from
Qt designer *.ui files at runtime.
This allows a user to create or modify customized LADSPA guis without
recompiling MusE.

======================
   Installation
=====================

Copy the file muse/widgets/musewidgetsplugin.so into a directory were
Qt (designer) can find it.

Example:
      if you installed Qt in /usr/qt3:
      su -c "cp -af musewidgetsplugin.so /usr/qt3/plugins/designer"
Check:
      After starting the Qt designer you see all MusE specific widgets
      under Tools/MusE. If you cannot find any MusE widgets, designer
      did not find the file "musewidgetsplugin.so".

======================
   Environment
======================

Naming:
      The Qt designer files are named after the LADSPA plugin ID.
      Example: the "freeverb" plugin has the id "1050". A gui for
            freeverb has to be named "1050.ui".
      The plugin ID is shown in the MusE plugin browser.

Path:
      MusE looks for *ui files at (museglobalshare)/plugins/.
      If you installed MusE at "/usr" (configured with --prefix=/usr)
      MusE looks at "/usr/share/muse/plugins" for *ui files.

======================
   Creating *.ui file
======================

The association between LADSPA plugin parameters and Qt-Widgets is
done by name. All input widgets which manipulate a LADSPA parameter
must have a name starting with the letter "P" followed by the parameter
index.
      Example:
      A "Slider" widget which manipulates the 3th parameter of a
      plugin has the name "P3slider".

Supported Widgets:
      "Slider"       slider for float values
      "DoubleLabel"  entry for float values
      "QCheckbox"    to manipulate a on/off LADSPA parameter
      "QComboBox"    select from a list of named values; sets
                     integer LADSPA values

(for more hints please look at the example *.ui files)

=============================================================
      Short instructions to get the soft
      synthesizer up and running
=============================================================

1. Compile and install MusE

3. Run MusE from an xterm with Option "-D";
   look at the debug output in the xterm; you should see something
   like:

      3 soft synth found
      found soft synth <fluid> <fluid soft synth>
      found soft synth <organ> <organ soft synth>
      found soft synth <S1> <organ soft synth>


4. Configure Software Synthesizer

   Open Settings->MidiPorts/SoftSynth.

      - select a software synthesizer
      - press "Add Instance" to create an istance of this
        synthesizer; the synthi shows up in the list
        of instances with a unique name

5. Configure Midi Port

   To use the synthesizer instance you must
   connect it to a MusE midi port:

      - click into the "Device Name" column of an empty midi port
        (Device Name == "none")
      - select the synthesizer from the dropdown menu.

   This connects the synthesizer to the selected midi port.
   The instrument type is automatically set.

6. Open the Audio Mixer

      You see a new mixer strip of type "Synthi" and the name
      of the new created synthesizer instance.

      Route the audio output of this strip to "Output".
      (per default the synthesizer is routed to the first Output strip)

7. Now you are ready to play with the "organ" synthesizer

      - create midi track
      - set the midi port to the synthesizer port
      - click the "R" column in the tracklist to enable "Recording"

8. Optional: open Configure->MidiPorts and click in column GUI
   to show a GUI for the synthesizer instance.
      There is no gui available for the S1 synth.
      The iiwu gui enables you to enter a different sound font.
      The organ gui has some "draw bars" to let you play with
      sounds in real time.

These are the software synthesizers currently available:

      - S1  a simple sythesizer skeleton as a guide for all who
        want to code their own one:
            - only one tone at a time
            - simple sinus wave form
            - no gui
        The synthi may be used as a metronome.

      - organ, an adapted version of the LADSPA plugin
        "Organ - Additive Organ Synthesizer Voice" from
        David A. Bartold

        "organ" implements a gui connected bidirectional
        to the synth via stdin/stdout

      - fluid, is the adapted version of Peter Hanappe´s
        sample based fluid synthesizer (formerly known as iiwu)
            - loadable sound fonts
            - multi timbral
            - 128 voices
            - simple gui lets you load a different sound font
        Fluid loads a default sound font determined by the
        environment variable "DEFAULT_SOUNDFONT".

=============================================================
      Short instructions for compiling MusE
      with native Steinberg VST SDK
=============================================================

By default MusE utilizes the VESTIGE compatibility headers for VST support, it is however
possible to compile with Steinbergs SDK for some possible improvements (vst chunks has
been implemented so I actually don't know if there is any reason to use the VST SDK anymore)

To fulfill the requirements for this follow these steps:
1. download and extract vstsdk (last it was seen here: http://www.steinberg.net/en/company/developers.html)
2. find the folder containing aeffectx.h (usually it's under <sdk>/pluginterfaces/vst2.x/
3. Edit the aeffect.h and change
#define VST_2_4_EXTENSIONS 1
to
#define VST_2_4_EXTENSIONS 0
4. Configure MusE to disable VESTIGE and point to the SDK HEADERS, for instance with adding these
   arguments to the cmake commandline:
   cmake -DENABLE_VST_VESTIGE=OFF -DVST_HEADER_PATH=<pathtosdk>/pluginterfaces/vst2.x/
   Note that by default the sdk extracts into a folder with spaces, this may work badly,
   safest to rename the path without spaces.
5. run cmake, make and make install as you usually would.

# Building MusE on Windows.

The file is named win32 though it extends to windows in general but the word Windows is just too ambiguous.

There is a thread in the forum with the most recent effort to bring Windows support to MusE:
https://linuxmusicians.com/viewtopic.php?f=61&t=19353

Be warned that the Windows build of MusE is work-in-progress and is mostly of interest to tinkerers that wish
to pursue this effort.

## Instructions

The following steps allow native Muse (git) compilation under Windows with the mingw64 compiler. Optional steps or alternatives are commented out.
It is available in it's original formatting here:
    https://musicsecrets.euniversity.pub/muse.html

    Support files:

        Required dependencies
        Fix make paths script (place it in muse/src)
        Compile components script (place it in muse/src)
        Compile Muse script (place it in muse/src)
        Pack script (TODO)


    1. Install msys2 from http://www.msys2.org/ in a short path (i.e. f:/a)
    # From the msys2 terminal
    pacman -Syu
    # Close the msys2 terminal and open it again
    pacman -Su

    2. From mingw64 shell from now on, install common packages:
    pacman -S \
    mingw-w64-x86_64-toolchain \
    python3 \
    python3-setuptools \
    mingw-w64-x86_64-python3 \
    mingw-w64-x86_64-python3-setuptools \
    python2 \
    python2-setuptools \
    pkg-config \
    mingw-w64-x86_64-pkg-config \
    autoconf \
    automake \
    perl \
    gtk-doc \
    flex \
    bison \
    patch \
    libtool \
    mingw-w64-x86_64-libtool \
    wget \
    git \
    nasm \
    mingw-w64-x86_64-nasm \
    dos2unix \
    mingw-w64-x86_64-cmake

    3. Install pre-built dependencies
    pacman -S \
    base-devel \
    mercurial \
    cvs \
    p7zip \
    ruby \
    mingw-w64-x86_64-qt5 \
    mingw-w64-x86_64-ladspa-sdk \
    mingw-w64-x86_64-libsndfile \
    mingw-w64-x86_64-libsamplerate \
    mingw-w64-x86_64-fluidsynth \
    mingw-w64-x86_64-gtkmm \
    mingw-w64-x86_64-dlfcn

    # Build the following packages with these commands in /usr/src:
    cd /usr/src
    cd #PACKAGE_DIR#
    makepkg-mingw -g >> PKGBUILD
    makepkg-mingw
    pacman -U *.pkg.tar.xz
    cd ..

    mingw-w64-liblo
    mingw-w64-serd
    mingw-w64-sord
    mingw-w64-lv2
    mingw-w64-sratom
    mingw-w64-lilv
    mingw-w64-portaudio
    mingw-w64-jack

    4. Build Muse
    cd /usr/src
    git clone --recurse-submodules -b master git://github.com/muse-sequencer/muse.git
    cd /usr/src/muse/src
    export LIBRARY_PATH=/mingw64/lib
    export CPATH=/mingw64/include
    # Copy here the files compile_muse_mingw.sh and CMakeLists.txt
    ./compile_muse_mingw.sh

    5. Pack files (TODO)
    # Place muse_pack.sh in /usr/src
    ./muse_pack.sh