>
> (What happens when you edit material with wildly differing recorded and
> notation times?
How wildly? I have these cases:
* Tiny notes. Notes that are shorter than Note::m_shortestTime. They're
handles as indivisible atoms. They've been exercised a little bit, and
so far they have behaved themselves. It has been exercised mostly by
crazy 23 vs 3 bars and such that I tried that resulted in some tiny
notes.
* Notes that leave slivers other than at barlines. They're accepted at
the nearest starting time. I conceptually split meterPieces in two
halves. A normal note that starts in the first half is notated as
starting exactly at the beginning, one in the second half is notated as
starting exactly at the end. It doesn't get too crazy because if they
start in the middle of a meterpiece, it's split further unless/until it's
a 1/64 or shorter.
* Notes that leave slivers at barlines. That's not implemented yet. The
plan is to coerce them the same way as the ones other than at barlines,
but by a different mechanism.
* Notes that are a lot longer or shorter than their notation times.
Like, they think they're half-notes when they are performed as 1/8 notes.
They can get split-and-tied differently than their original notation
thinks, according to how their performance times fit the bar. Then their
performance times are restored.
* "Swung" times. That I have done nothing for yet. I am hoping to get
swing info from the notation quantizer and calculate meter-split times
accordingly.
> It should presumably use the notation times as source
> material...)
We get the bar splitting from notation times, except in the case of tiny
notes.
My reasoning on tiny notes is that a tiny note has to go into a single
meterpiece. Splitting-and-tying something that small doesn't make sense.
It further has to go in the meterpiece that best corresponds to its
performance time.
> I would like to encourage everyone who can to test this branch -- I
> think the approach looks like a very sound one, enough to have provoked
> me from my slumbers, but there are many possible things that can go
> wrong and my testing time is very limited. It should get merged and
> released, most probably, but if it *just* gets merged and released
> without really being exercised, it won't work.
I completely agree.
Tom Breton (Tehom)
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
