Re: [Lmuse-developer] My changes committed now

[Dennis S. <mus...@wi...>]

Congrats, Tim. I see a new round of comiling comming for me. :-)

Dennis


On Tue, 17 Jun 2014 01:55 -0400
"Tim E. Real" <ter...@ro...> wrote:

> 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.
> 
> 
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Lmuse-developer mailing list
> Lmu...@li...
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer