[Lmuse-developer] My changes committed now

[Tim E. R. <ter...@ro...>]

Hey! [Tap tap tap] This thing on?
[Sound of wind and tumbleweeds rolling by. Then crickets chirping.]


- Transformation to non-shared event lists (started by Florian)
    is virtually complete.
- Events have an ID now, shared among clone parts. 

- A few more commands support Undo/Redo now, like setting global tempo. 

- Handful of (un)related fixes along the way.

- New: Fast pending operations lists: 
  They replace all the RT code in Song::executeOperationGroup2()
   and ::revertOperationGroup2().
  
  See the new operations.cpp / .h 

  The idea is the list only stores the actual finalized low-level 
   STL operations: A list pointer + an object to add or an iterator to erase.
  The list is executed 'boom boom' all in a row in RT stage with no extra BS.   
  Previously extensive searching and even allocating was being done in 
   this RT stage. Now non-RT stage-1 does all the 'gathering' and allocating.
  Yet, with these changes, the list items /themselves/ are still allocated 
   (by STL) in RT. So there is one step left to do: Memory pools for all these 
   lists, so that NO allocation is done in RT thread, not even the list items.
  The beauty of this is we have a non-RT stage-1 in which to /calculate/
   how much more space is needed and do the memory pool resize /there/.
  Then when the RT stage-2 comes around, the list's memory pool is ready 
   and waiting for new items, no allocation needed. 
  Ultra-fast.

  However I must admit that I was not able optimize Track operations
   because class TrackList is a vector, and vector iterators are not like 
   the others - they WILL easily change, so I could not CACHE them as 
   described above. Only slightly slower though - not as bad as it sounds.

  The implications of such a system are that sometimes you can no longer 
   count on the operation executing immediately - you have to be very aware 
   of that, see the midi controller graph code in ctrlcanvas.cpp for example.
  Fortunately it is robust and fairly 'foolproof' - you can pretty much throw
   any series of commands at it and it will OPTIMIZE them and deal with them.

  In fact, now even as you push commands onto any Undo operations list
   and execute the list, it optimizes, merges, discards, sets up, embellishes, 
   adds other needed commands and so on.

  The system is, well, I admit a bit overly complicated, redundant, and 
   even unused in some parts. 
  Particularly the TempoList and SigList support. I worked with those 
   lists 'as-is'  to prove it could be done as an exercise. They use allocated 
   items. And they're weird lists. So it was a challenge.
  Ultimately they need to be changed over to EASIER non-allocated list items
   exactly like how the KeyList was made.

  I will likely alter it, stay tuned...

  BUG: Slight bug with tempo and sig editing: Hitting Undo may not produce 
   the exact correct graph (missing pieces).
  EASY WORKAROUND: Hit Undo again, then Redo. Works every time.


*** NOTICE **** 
----------------------------------

- Classes Pos and PosLen have a few new methods, some new or borrowed 
    from my old huge fundamental changes POC branch, such as these:

Pos:
      unsigned posValue() const;
      unsigned posValue(TType time_type) const;

      static unsigned convert(unsigned val, TType from_type, TType to_type);

PosLen:
      unsigned lenValue() const;
      unsigned lenValue(TType time_type) const;
      
      static unsigned convertLen(unsigned val, unsigned len, TType from_type, 
         TType to_type);

=======================================

Please consider using these methods now wherever possible instead of 
 hard-coding  frame-to-tick/tick-to-frame conversions and so on.
It is important to make such code as 'agnostic' and abstract as possible so 
 that it can be easily changed, embellished, and streamlined.

Simply search for those method names to find good examples of usage
 and how they replace the old techniques.

=======================================

For example posValue() is pretty obvious - it returns the actual current 
 /value/ whether that value be in frames or ticks.
posValue(TType time_type) returns the value in the specified time type.

The methods really do help, when dealing with questions of how to convert
 from one domain to the other, even automatically with minimal input.


Thanks.
Tim.