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
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
