About time, innit?

Here is the Changes starting from 0.9, I usually edit out duplicates and minor stuff but no time at the moment so here's the whole shebang.
Many thanks to our developer hero Tim who has implemented 99.3482% of these things!

The release is at the sourceforge site:


      * Fixed: Track info panel 'Rec' button not changing existing values on controller graph. (T356)
        - Name changes: MidiCtrlValList::add, ::del, ::find to ::addMCtlVal, ::delMCtlVal, ::findMCtlVal
           to make it easier to spot all usages of them.
        - Simple fix in MidiCtrlValList::addMCtlVal: Return false if the value is already found for the part.
        - TODO: It takes three 'undos' to undo the 'Rec' button push. It is because prog, vol, and pan
           are changed. This should be unified into one undo...

      * Fixed: Compile error on 64-bit systems, in audiotrack.cpp at cacheJackRouteNames(). (T356)
        - Changed from unsigned int pair key, which required pointer conversion, to AudioTrack* pair key.
        - Test OK (on my 32-bit system). ** Need 64-bit users to test it. **
      * Fixed: Segfault when playing a note in a drum map, when the note's port says 'none'. (T356)
        - Added a line in the 'don't echo controller changes back to software synthesizer' block of
           Audio::processMidi(), to check valid device.
      * Fixed: Missing or stuck notes or events on recording (or rec-armed only) midi track. (T356)
        - Symptom: Playing live (rec-armed only), or recording, on a midi track gives stuck or
           missing notes and other events. Very annoying bug!
        - Cause: A single list was used for recording midi events, while muse was also reading from that list.
        - Employed a 'flipping' two-list technique for MidiDevice::recordEvents().
        - In Audio::processMidi(), process one list while MidiDevice::recordEvent() writes to the other.
      * Fixed: Manipulating controller events in midi track parts was not changing midi port controller values. (T356)
        - Symptom: Change a part's midi controller events, or move or delete a part, or delete a track, then the underlying
           midi port's controller values are not altered, leading to 'phantom' or 'ghost', or duplicate controller values,
           even where there is no part or no track, or no controller values where there should be !
        - Oops, how did this major bug go unnoticed so long?...
        - Major rewrite: Created a struct MidiCtrlVal{int val, Part* part}, and changed class MidiCtrlValList from
           std::map<int, int>  to  std::multimap<int, MidiCtrlVal>
          Changed MidiCtrlValList::add(int tick, int value) to MidiCtrlValList::add(int tick, int value, Part* part),
           and MidiCtrlValList::del(int tick) to MidiCtrlValList::del(int tick, Part* part),
           and added MidiCtrlValList::find(int tick, Part* part).
          Changed Song::addEvent(), Song::changeEvent(), Song::deleteEvent(), Song::addPart(), Song::changePart(),
           Song::removePart(), Song::insertTrack2(), and Song::removeTrack2() to make sure port controller values
           are added/removed properly.
          Changed a few other things to make it all work.
          Reasons: The Part* member was added to each controller value item in the list, so that the system can
           know exactly which part was responsible for putting a value in the list.
          This helps when we have overlapping controller values from events of different parts on the same port and the same channel -
           if one of the parts is deleted or moved, the overlapping values from the events of the other part are NOT disturbed
           within the port's controller value list.
          The list was changed from 'map' to 'multimap' to accommodate the multiple values from events of different parts.
         - NOTE: When there are overlapping values from events of different parts, the system will arbitrarily choose the
           first value it finds at a given time. I considered 'mixing' the overlapping values together
           (by averaging, or maybe highest/lowest value), but I felt it would just cause more confusion for the user.
          Therefore it is up to the user to be aware of overlapping controller events and deal with them.
          If you are looking at a controller graph and it shows a particular value at some time, but the
           midi knobs/sliders and actual midi output does NOT correspond to what you are seeing, then
           most likely ANOTHER part on the same port and channel has an event at that same time, and that
           event's value is likely the one that is being used by the system.
      * Fixed: Changing a midi track's out port or channel was not updating the ports' controller values. (T356)
        - Changed MidiTrack::setOutPort() and MidiTrack::setOutChannel() calls to new MidiTrack::setOutPortAndUpdate()
           and MidiTrack::setOutChanAndUpdate(), which make sure the port's controller value list is properly updated.
        - Part of the larger fixes above.
      * Fixed: Midi adjustment knob on controller canvas was not working after moving the part to another track. (T356)
        - Added some code to CtrlCanvas::songChanged() to set curPart and curTrack and update the knob,
           upon SC_PART_MODIFIED.
      * Fixed: Clear midi input transforms when song cleared. Update transform dialog when song changed. (T356)
        - Symptom: Repeated loading of songs causes duplication of midi transforms, causing .med song files to grow big !
        - Added clearMidiInputTransforms() to midiitransform.cpp, called by Song::clear().
        - Added updatePresetList() and slot songChanged() to MidiInputTransformDialog, triggered by Song::songChanged.
        - Added some code to readMidiInputTransform() to **auto-eliminate** duplicate transforms in existing .med files.
        - Still some 'quirkiness' with the dialog buttons, but it works better now.
        - ALSO: Applied those same fixes to midi transforms and the midi transform dialog.
      * Fixed: Notes not recorded to track for a drum map 'instrument item' having non-default (track) port. (T356)
        - Changed to drumRecEvent.setPort(port) in 'Track::DRUM' section of 'if(recording)' section of Audio::processMidi()
           so that buildMidiEventList() would accept the notes.
      * Fixed: Removed jack midi port names from audio in/out port lists. (T356)
        - Added JACK_DEFAULT_AUDIO_TYPE to jack_get_ports calls in JackAudioDevice::inputPorts and ::outputPorts.
      * Fixed: Notes were being mixed up when switching a track type between midi and drum. (T356)
        - Changed to drumMap[pitch].enote in 'Drum -> Midi' section of TList::classesPopupMenu().
      * Completed: Moving multiple events from multiple parts when editing in pianoroll or drum editor. (T356)
        - Work had begun several commits ago. Completed.
        - Now you can select and move multiple events from different parts in the editors.
      * Feature: When editing multiple parts in the pianoroll or drum editor, controller graphs are now overlaid! (T356)
        - When you are editing more than one part at a time in the editors, the controller graph will overlay
           all of the graphs together!
        - The currently selected part will show its controller as normal blue columns, as before, but the other
           unselected parts will draw their controllers as a gray 'ghost' outline on top.
        - TODO: Add menu items, hot keys etc. to cycle through each part (in case there are no notes to select in a part!)
      * Improved: Support for GS/XG midi drum controllers. (T356)
        - Added MidiPort::drumController(). Tells if an event is a drum controller event, according to the port's instrument.
          Does it by looking up the event in the instrument's controller list.
          Would prefer a 'marker flag', eg use the event 'dataA' high bit to mark as drum controller event, but it's too risky!
          Used MidiPort::drumController() a dozen or so places where drum controller events needed remapping/manipulation etc.
          May be a speed hit with many/large controller graphs? Test further...
        - Added code to update port controller values when changing drum map ANote, channel, or port.
        - KNOWN BUGS: Still a few loose ends to tie up: Port controller values (but not track events) may not be correct when:
           'Swapping' (by dragging) items in the drum map, and
           loading a song with a drum map which had 'swapped' (by dragging) items.
          Some stuff (midi value adjustment knob) is not updated when changing drum map ANote, channel, or port.
          Workaround: Be sure to select another drum map item, then reselect the changed item again, after such operations.
      * Changed: All softsynth midi controllers now have default initial values. (T356)
        - Added default initial values to all softsynth controllers such as fluidsynth's controller map.
        - Added 'initval' argument to all ::getControllerInfo() methods, which is passed to the newly created
           controller (new MidiController) in SynthI::initInstance().
        - These initial values will then show on the various gui midi adjustment controls, knobs etc.
      * Changed: Fluidsynth master gain and reverb initial settings. Gain was too loud and there was too much reverb. (T356)
      * Fixed: Follow up - some issues with instrument editor. (T356)
        - Instrument editor was sometimes falsely detecting instrument had changed.
        - Also, do not list 'internal' instruments like generic midi, soft synths, vst etc.
        - Also, upon 'Save As', prompt for a new instrument name if the user hasn't changed it, to avoid duplicates.
        - Remove any unsaved (new) instrument when moving to another instrument, closing etc.
        - Fixed up tab order of instrument editor controls.
        - TODO: When muse wants to close, trap it in the instrument editor so we can save.
      * Fixed: Problem in xml parser. '&amp', '&quot' etc were being read as '&&', '""' etc. (T356)
        - Added a couple of lines, and removed one, in Xml::stoken().
      * Fixed: Zero bias midi controllers (with a negative minimum value, like 'pan') weren't working right. (T356)
        - Broken after last changes. Added an updateBias() line to MidiController::read() 'controller' tag end section.
      * Added: Send all instrument controller initial (default) values to all of a port's midi channels,
           except where explicitly initialized by the song. (T356)
        - Added some code to MidiPort::setMidiDevice to initialize controllers from instrument, if needed.
        - When setting a midi port's device (such as in Settings->Midi Ports, or simply when loading a song),
           then any specified controller initial values in the instrument are sent to ALL of the port's channels,
           EVEN if the controller is NOT in the song. This ensures better consistency between songs, so that
           chosen controllers are not left in undesirable 'leftover' states.
          (Taken from important comments in MidiPort::setMidiDevice(): )
          For example: A song is loaded which has a 'reverb level' controller initial value of '100'.
          Then a song is loaded which has no such controller (hence no explicit initial value).
          The 'reverb level' controller would still be at '100', and could adversely affect the song,
           but if the instrument has an available initial value of say '0', it will be used instead.
        - It is desirable to have defaults for some controllers, but it is wise to have NO default for certain
           other controllers, like the 'reset all controllers' and 'sustain' controllers (actually, zero would be OK).
      * Changed: Clicking Midi->InitInstrument (or moving to song position 0) now initializes controllers
          from instrument controller initial values, if they exist, or previously hard coded values if not. (T356)
        - sendGmOn() and sendXgOn(), which are called via Audio::initDevices(), now use instrument controller
           initial values if they exist, or the previously hard coded values if not.
      * Changed: Non-softsynth non-GM drum tracks: Patch popups now show all drum AND melodic patches on ANY channel. (T356)
        - For drum tracks, if the song type is not GM, and the track's port is not a softsynth, then all patches
           including drum AND melodic are shown for ALL channels when 'select instrument patch' popup is clicked,
           regardless of the patches' 'drum' flag setting (in the instrument editor).
           (Softsynths handle their own patch popup lists).
        - Added a 'bool isDrum' parameter to all populatePatchPopup() methods, which is passed 'true' only
           if it's a drum track, and changed a couple of lines in the only class which uses the drum flag - MidiInstrument.
        - Previous behaviour was to show drum patches ONLY on channel 10 of drum tracks.
        - Reasons for change: 1): A midi device might have a non-standard drum channel(s), so drum patches
           as well as melodic patches are shown for all channels. 2): Since any channel can be used in the drum map,
           melodic patches are shown as well as drum patches so that any patch can be selected for any channel.
          NOTE: Each of a drum track's channels which are used in the drum map should be set to a patch number,
           otherwise it doesn't work right ! (**) This is true for softsynth devices too ! (**).
          So it was imperative that the user be able to select ANY patch on ANY channel, to suit their setup,
           for flexibility.
          (If that same flexibility were applied to regular midi tracks (non-drum tracks), it might make the
           'drum' flag for patches obsolete, since there would be no reason to filter them from the list !)
      * Changed: All midi controller event values sent to a midi port are now constrained (limited) to the port's
          instrument controller's range (if that instrument controller exists). (T356)
        - Example: Incoming events from a midi keyboard's pitch wheel range from -8192 to 8191, but it is
           desired to limit that range to, say -200 to 8191. One could use the midi input transformer to
           accomplish this, but instead now you can simply adjust the chosen instrument's pitch controller range
           (in the instrument editor), and then the pitch wheel's range will be limited to that range.
        - This only affects playback events (and therefore 'live' incoming events), but does NOT affect
           actual recorded data, so that by simply readjusting the instrument controller's range,
           or by changing instruments, the range can be restored with no loss of recorded data range.
      * Fixed: Cleaned up all .idf files and changed ranges of all 'zero-bias' controls (-64/63 'pan' etc). (T356)
        - Many .idf files had bare '&' characters in them, causing corruption of names and values when reading.
        - Also turned on the 'drum' flag for ALL drum patches in MANY .idf instrument files.
          Some .idf's I was uncertain about, and did not change : AlesisQS6, Waldorf Q.
      * Changed: Fluidsynth pan controller range from 0/127 to -64/63. (T356)
        - To be consistent with .idf file changes.
      * Replaced: All direct calls to MidiPort::setHwCtrlState() from GUI thread, with new Audio::msgSetHwCtrlState(). (T356)
        - My fault, I was not paying attention to iter-thread communications.
      * Optimizations: Optimized MidiPort::setHwCtrlState(), MidiPort::sendEvent(), and calls to MidiPort::setCtrl(). (T356)
        - Optimized MidiPort::sendEvent().
        - Replaced code in MidiPort::setHwCtrlState() with more optimized code.
        - Replaced several clumsy calls to MidiPort::setCtrl(), which checked for and created the controller,
           with a new optimized MidiPort::setControllerVal().
      * Fixed simpledrums/ssplugin.cpp to build with recent Ubuntu 8.10 (FN)
      * Feature: Muse now has an instrument editor, complete with a midi controller editor! (T356)
        - Click on the menu "Midi->Edit Instrument".
        - You will see a sysex editor there too, but it is non-functional. (Use the midi event editor instead).
        - >>> Tooltips and "What's This?" are provided with IMPORTANT information. <<<
          >>> If you want to understand how to use instruments, patches, and controllers in your song, <<<
          >>>    READ THEM!    <<<
      * Added: Environment variable MUSEINSTRUMENTS, so a (writable) instrument directory can be chosen
         instead of default /usr/share/muse/instruments etc. (T356)
        - Also added display of environment variables recognized by muse to command line help (muse -h).
      * Fixed: Popup displays of instrument patches to filter according to GM, GS, XG song type, and whether
         on drum channel 10. (T356)
        - Use the new instrument editor to set these GM, GS, XG, and drum filters.
      * Changed slightly: Creation of a new drum track - initialize to channel 10 instead of 1. (T356)
      * Fixed: Force audio prefetch seek when play is pressed. (T356)
        - In Audio::seek, changed the call of audioPrefetch->msgSeek to force a prefetch,
           to ensure the most recent data. Things can happen to a part before play is pressed
           such as part muting, part moving etc. Without a force, the wrong (old) data was being played.
        - If you perform those same operations while playing, there may be a few seconds delay before you
           hear the changes (the play cursor must move a certain distance before they're heard).
        - TODO: How to make the same thing happen when transport is externally started, such as from qjackctl.
            OR: How to force a prefetch at specific places like when a part is muted, and when it is moved,
                 instead of just before play is started. That way the operations can be done quickly while playing.
      * Fixed hangup: Upon loading of songs with fluidsynth soundfonts which can't be found. (T356)
        - (!) Removed error message box from FluidSynthGUI::processEvent causing freezeup.
        - You can still read fluidsynth errors by running muse on a command line. I figured it was
           better to be able to load the song and to see errors, instead of just letting it freeze.
        - This should now allow you to share fluidsynth songs with other people (without the soundfonts).
      * Fixed: Audio aux tracks not working, intermittent. (T356)
        - Aux functionality was intermittent depending on whether the aux had out routes,
           and whether any tracks feeding the aux had out routes, and other factors.
        - In Audio::process1, rearranged, and added, some code to make aux work all the time now.
      * Speedups: To some songChanged() functions. Ignore unnecessary flags. (T356)
        - For example simply adjusting midi gui controls would cause costly and
           unnecessary rebuilding/redrawing of certain areas, like parts of trackinfo, and controller graphs.
        - Noticeably less 'slugglish' when adjusting controls now.
      * Fixed: Midi controller events not being added to midi port controller, after record with no part. (T356)
        - Symptom: If you record midi controllers without first creating a part, muse creates the part
           for you and creates the controller graph OK, but when you move the play cursor around, the graphs
           have no effect. This doesn't happen if you first create the part to record into, or manually edit a graph.
        - Symptom: As above, the graph is OK, but the controllers don't show up in the list when you click 'ctrl'.
        - Changed a line in song::cmdAddRecordedEvents() to use addEvent() instead of adding directly to list.
      * Fixed: Automatic detection of pitch bend wheel not working. (T356)
        - Added some code to MidiPort::sendEvent to detect ME_PITCHBEND events.
        - Note: There appears to be a sound system bug (using ALSA 1.0.15): The system will NOT deliver any pitch
           bend events to muse until ANOTHER controller is detected, ex. move the modulation wheel THEN the pitch wheel.
          Verified with another app - RG - and with a real midi hardware to hardware connection (not my KB's fault).
      * Observed: Stuck or missing midi notes when recording or even just 'record armed only' 'live' playing. (T356)
        - The sound system appears to be having occasional trouble detecting midi events, including note-off !
          Verified with muse and RG (using ALSA 1.0.15). Not sure why or when this started, seems early this year...
      * Linked: All midi knobs and sliders with their labels. (T356)
        - Now they work together when displaying and adjusting.
        - After careful consideration of the meaning of 'off' in those
          labels, you now double click the label to turn the midi control on/off.
          Off does not mean 'zero'. Rather, it means:
          'Don't save this current value in the song file'.
          When a midi control is 'off', loading the song won't initialize the controller with a value.
          'Off' means the current value is set at 'unknown'. 'Unknown' means the actual
           'behind the scenes' hardware value is the last value that was set. The knob or slider still
           shows this value, or a default initial value, or if both of those are unknown, then 0.
      * Changed: Midi and audio level slider/knob labels to show '---' for infinite attenuation. (T356)
        - As mentioned above, the midi level slider labels can also show 'off'.
      * Fixed: The new midi controller knob in pianoroll and drum editor. (T356)
        - It was not adjusting anything.
      * Fixed: Midi vu meters again. Now they should work! (T356)
        - They were not responding to play events with an off velocity other than zero.
      * Fixed: Marker view window doesn't remember if it is open or closed. (T356)
        - Add a markerClosed function to app.
      * Reverted: Back to audioRTalloc in mpevent.h (T356)
        (!) - I had changed it to midiRTalloc, but that may have been causing problems like
               midi shutdown (audio OK) after a few hours, and crash soon afterwards.
              Verifying... No more midi shutdowns after a few hours, so far...
            Ooops, not so fast, happened again...
      * Fixed bug in drum editor. Dragging the splitter too far left causes runaway resize, stuck in loop. (T356)
        - Tried several different arrangements, but QSplitter won't behave the way I need it to. Best I could do, so far.
        - You may notice some strangeness, like the controller graph not aligning with the matrix, if the right edge
           of the window is offscreen.
      * Added 'add/set event' to audio automation right-click popup menus. Ancient request by R.J. (T356)
      * Fixed arranger midi strip and arranger top controls not giving up keyboard focus after adjustment/entry. (T356)
        - Further request by user G.B. Changed all relevant QSpinBoxes to custom SpinBox, which behaves like this:
           Click up/down, or mousewheel, or hit enter with un-modified text (which means enter TWICE for modified text),
            and the control will give up focus, thereby allowing you to use global shortcut keys afterwards.
            Up/down keys still keep the focus.
        - TODO: Piano roll and drum editor.
      * Fixed major problem with lost jack routes upon file save, when save causes a jack shutdown. (T356)
        - Symptom: You click save, but jack shuts down during the save, causing lost jack routes in the file.
        - Fix: Cached the jack route names before file save, then used them during AudioTrack::writeRouting() xml code.
          Note this doesn't actually stop shutdowns from happening - now it just saves your files without losing jack routes.
      * Fixed mysterious intermittent wave part muting, as mentioned in 11.03.2008 (T356)
        - !!! PartList and EventList are now sorted by frame instead of tick, for wave parts only. Because fetchData()
           didn't like sorting by ticks. This is a radical change. So far, no other areas found requiring further coding, but...
      * Overlapping wave parts and events now mix together, instead of one part or event taking priority over others ! (T356)
        - Virtually no speed hit, since muse was already cycling through all the wave parts/events,
           just not mixing them together. So the very LAST wave part/event in the part/event lists was
           taking priority over others.
      * Fixed default instrument midi controller min/max values. (T356)
        - Symptom: Some pianoroll midi controller graphs much too small or too big, vertically.
        - Cause: You added these controllers to your track as a midi instrument, ex. General Midi (GM), then you
           changed the instrument, ex. to 'Generic Midi' or another instrument without those controllers,
           which set improper min/max values.
        - Fix: Added code to MidiPort::midiController() to set proper min/max values based on standard controller type.
          However, if the original instrument used CUSTOM min/max values, the graph may still be distorted.
      * Fixes to midi event list editor. (T356)
        - Added true sorting of event list. Now you can click on column headers to sort as desired!
        - Added formatted program number display (like 1-1-120) for 'Val B' column.
        - Fixed Poly After Touch events display in list. They were being listed as Channel After Touch.
        - Fixed crash when 'Delete events' clicked with no actual items selected.
        - 'Edit Contoller Event' dialog:
          - Fixed 'Create New Controller' popup list: Now it actually creates the selected controller.
          - Fixed 'Program' controller not showing correct program after selecting other controllers in list.
          - Fixed too high initial value displayed for controllers without an initial value in the instrument file.
        - 'Enter Poly After Touch' dialog:
          - Fixed uneditable note box. Switched from PitchLabel to PitchEdit.
      * Feature added - Pianoroll and drum editor controller graphs now have a static manual adjustment knob ! (T356)
        - Now you don't have to enter controller graph values to adjust a setting, just turn the knob.
      * Changed 'Create New Controller' in event editor 'Edit Contoller Event' dialog, and 'add new...' controller popup
         list in piano roll. (T356)
        - Now they only list controllers not already added, instead of all of them.
      * Fixed 'Position Edit' controls (0001.01.000 + up/down buttons) - click 'down' nothing happens. (T356)
        - Added updateButtons() call to PosEdit::setValue().
      * Fixed Mixer midi strip variation, reverb and chorus send knobs not enabled after controllers added. (T356)
        - Now you only need to create the controller to enable the knobs, allowing you to set a manual value without
           having to actually create one or more controller events first.
      * Fixed midi trackinfo pan value not the same as midi mixer strip pan value. (T356)
        - Trackinfo pan now goes from 'off' (-65) to -64 to +63.
      * Fixes to fluidsynth. Would crash when getting patch names from an 'unspecified' soundfont. (T356)
        - In fluidsynti.cpp, various places check for FS_UNSPECIFIED_FONT only. Added check for FS_UNSPECIFIED_ID.
        - Not sure if FS_UNSPECIFIED_FONT is redundant and unnecessary, but left it there anyway.
      * Fixed old bug - IntLabel control - right click causes popup and runaway increment. (T356)
        - Fixed NEntry widget. Same fix as for double entry widget (DEntry), somewhere way down on this change log...
      * More fixes to wave part gluing/splitting/drawing/playing. (T356)
        - Now all splitting/gluing of wave parts, even overlapping ones, even multiple times, should work.
        - Fixed problem in WaveTrack::fetchData causing it to read too many samples of wave events.
      * Fixes and changes to bounce functions. (T356)
        - Fixed garbled target track or file. processWrite() was writing ALL the Audio Outputs to the file or track, instead of just one.
        - Feature: Bounce to track (from menu): You now first select any single Audio Output track, and any single target Wave track.
        - Feature: Bounce to file (from menu): You now first select any single Audio Output track.
      * Fixed some problems with Mastertrack window. (T356)
        - Mastertrack window was causing tempos to be inserted into tempo list, if window open when project loaded.
        - Added signature list change event handling - to update signature value box.
        - Fixed drawing of signature scale after signature list change.
      * Fixed wave editor 'reverse' function crashing. (T356)
      * Fixed track list not highlighting wave tracks (default green) when selected in the arranger window. (T356)
      * Fixed midi VU meters, again. (T356)
        - Borrowed idea from Muse 2. Self-decay the meters in midi strip code, rather than the midi thread code.
        - The midi VU meters self-decay at a rate determined by the GUI update rate in the configuration.
      * Fixed arranger controls not giving up keyboard focus after adjustment/entry. Requested by user G.B. (T356)
      * Fixed gluing/splitting of waveparts. (Known bug of 02.02.2008 is gone now). (T356)
      * Fixed playing, and arranger/waveeditor drawing, of glued waveparts. (T356)
        - 'Working on' of 26.01.2008 is done.
        - Drawing of waveparts, even 'glued' ones, now fully respects tempo changes.
      * Fixed 'glued' mono + stereo wavepart drawing. Was drawing outside track if track height small. (T356)
      * Fixed soloed/muted wavetrack audio 'bleeding' into other wavetracks. fetchData() was not checking isMute(). (T356)
      * Fixed part colour popup to change unselected clicked item colour if no parts selected. (T356)
      * Fixed recent possible accidental(?) change of tracklist xml tag 'header' to 'header1'. (T356)
        - Muse was complaining: Tlist: unknown tag <header> at line 32
      * Fixed MREventList in mpevent.h, to use midiRTalloc instead of audioRTalloc. (T356)
        - Possible accidental(?) coding error since there is no other usage of midiRTalloc at all in muse.
        - If it does help at all, it might just ease RT congestion a bit.
      * Working on MIDI VU meters. They're too fast to see with jack, but should be OK with dummy driver. (T356)
        - If you move waveparts around AFTER the current play position, then play, muse actually plays the same
           arrangement as if you had not moved the waveparts at all, just one time - rewind the play position and
           it corrects itself. This is because muse does not prefetch the audio again after the movement of the parts.
          Workaround - After moving waveparts, be sure to rewind the play position to a point AT LEAST before those parts.
        - Wave parts will sometimes mysteriously go silent for no reason. Move the parts slightly, or reload, or do
           certain other operations, then the sound comes back. Working on this important issue!
      * Fixed a slight error in BigTime absolute display. Now shows proper absolute tick and frame values. (T356)
      * Added an extra arranger wavepart right-click popup menu item - "file info".
        Shows what wave file(s) are used by the wavepart event(s).
        TODO: Either remove duplicate file names or list the files by event number.
              Spice up with more info like wave starting/ending points etc.             (T356)
      * Removed some debug output lines from dummy driver - may have been causing intermittent crashes when moving position. (T356)
      * Some more fixes to arranger partcanvas wavepart drawing - speeded up and tightened code.
        KNOWN BUG: Does not correctly display more than one wave 'event' (file) per wavepart. (For ex. two waveparts 'glued' together).
                   Working on this issue ! (T356)
      * Fixed MIDI mixer strip VU meters. Let there be light! Not the best solution, a choice between two so-so methods.
        Looking at how to improve it... (T356)
      * Pianoroll and drumedit now open at the current cursor position. (T356)
        (The cursor position is that moving black vertical line on the time scale).
        This means you just click on an arranger midi part where you want to open the editor.
      * Arranger, pianoroll, drumedit and waveedit now stay at their current (left-side) position when you use the scale bar. (T356)
      * Fixed 'end of part' drawing problems - now you are guaranteed to see about 1+1/4 extra bar after the end
         of a pianoroll/drumedit (also compensating for drumedit drummap/canvas splitter), allowing you to
         add/move/clone notes past the end and allowing muse to properly auto-extend the part (to the right).
        TODO: Auto-extend parts to the left when necessary. (T356)
      * Added vertical, and fixed horizontal, lasso/parts/events auto-scroll - even past the end of parts.  (T356)
      * Fixed drawing of wave parts in arranger. Now you can rely on the 'picture' of the wave inside the part
         lining up correctly with the time scale, regardless of tempo/timesig changes in the song. (T356)
      * More fixes to wave editor. Fixed drawing of markers - they were much too close together.
        Added songChanged synchronization with arranger (you move/resize a wave part and the wave editor readjusts, etc.)
        WORKING ON: In the arranger, if you move a wave part to the left, the wave editor will readjust but the
         wave may be chopped off at the end. Investigating...  (T356)
      * Corrected the drawing order of items from ALL parts in pianoroll and drumedit. For multiple-part viewing.
        WORK IN PROGRESS: Added ability to select items from different parts at once, and to move them.
                          For now, only items from the currently selected part actually move. (T356)
      * Added small checkbox to Big Time display. Now you can switch between formatted or absolute time display.
        Absolute is handy for syncing with another app, or just knowing, absolutely, where you are in the song. Absolutely.
        Added ToolTip popups describing each 'group' of numbers (bars, beats, ticks etc). (T356)
      * Added function for deleting note overlaps in piano roll (usually makes fluidsynth grumpy - silencing the following note).
      * Some work on opening the editor at current position and selecting the leftmost item
      * fixed hanging note when editing multiple parts in midieditor and
        switching part
19.01.2008 (ws)
      * fixed Song::changeEvent(): part tick offset was not used
      * fixed removing of controller events in Song::deleteEvent(); this affects midi recording
        in replace mode and controller editing
      * Fixed automation right-click popup menu 'prev/next event' not working after a tempo change. (T356)
        - Now you are guaranteed to be able to navigate the automation events, regardless
           of how many tempo or time signature changes are in the song, or if you change the tempo/sig(s)
           AFTER adding automation events.
      * Fixed softsynths 'Fluidsynth', 'Deicsonze', and 'Fluid' to allow pitch wheel changes. (T356)
      * Fixed softsynths 'Fluidsynth' and 'Deicsonze' to allow MIDI patch changes. (T356)
        Note that I included MIDI patch change code in 'Fluid', but fluid is slightly broken
         and still doesn't respond. 'Fluid' should be removed from muse. It's obsolete. Use Fluidsynth.
      * Fixed LASH loading and saving. (T356)
        - Symptom - Muse fails building with error about 'lash_get_fqn' not declared in scope.
        - Cause - You are building muse with LASH > 0.5.1, where certain header files have been removed.
        - Fix - Replaced both calls to lash_get_fqn with QString manipulations instead.
      * NOTE! I encountered a muse segfault when you use LASH to close the project.
        It says 'received unknown LASH event of type 10' (which is LASH_Server_Lost), then it says
         'received unknown LASH event of type <<some big random number>>, then segfault and
         a glibc backtrace due to 'double free or corruption'. Not a big deal, but this will need to be fixed.
      * Tested OK saving and loading projects with LASH 0.5.4