Chris, thanks for having a look at this.
> It's a mistake to assume there is any one canonical structure for the
> notes in a bar and that they can be automatically rewritten correctly
> based only on their timings.
Oh, it doesn't just go by timing, it also goes by existing beamings and
tuplings.
* How it uses existing notation *
The tuplings inform how it will try to decompose the bar. That is, it
will only try (say) splitting by 23 if it sees a 23-let somewhere in the
bar.
They also inform "time stretching". In order to do 7-lets and worse
correctly, I do bar-splitting in stretched time, which is defined so that
every tupling mentioned by the notes can be exactly represented. I have
tried 23-lets, 43-lets, 3-against-13, all sorts of crazy tuplings, and
they come out OK! No more of this stuff where they miss barlines by 1
because we can't represent them evenly.
The old beamings are re-applied when it's done, except that:
* It will force a new group ID for tupleted groups that don't already
start with a fresh group. That's because it fears using a non-tupleted
beaming for a tupleted group. The Ravel example shows that this is
perhaps too strict.
* Where no beamings are given, not even -1, it will beam non-tuples
beatwise.
* What else probably was a factor *
There are a couple of other things that probably factored into the Ravel
example:
* It always tries the natural metrical decomposition first. Ie, mostly
binary splits. It kinda has to. At one point during development I had
it assigning scores and choosing the (apparent) best, and it produced
abominable results.
So it saw that 2 (normal metrical decomposition) was indeed a factor of
the 6-let timing and split them in 2, yielding 2 tripleted groups. At
that point it has no opinion on beaming or final tupling ratio, it just
wants a tree decomposition that hits everything.
* It puts tuplings into simplest form. In order to keep the code simple,
I don't try to keep tuplings "good" until that point in the code. This
makes 6:4-lets into 3:2-lets.
* Possible fixes *
I can probably get it to do that example right. Possible fixes:
* Re-beaming could be less strict about forcing a new group. In the
Ravel example, it could recognize that the previous tupled group still
works for the present performance ratio. This requires rearranging some
data structures, but it's doable.
* It could consult existing notes' tuplings when simplifying the
performance ratio. This is trickier. What if they are not workable, or
what if two simultaneous notes disagree? Also, note-ends have to count
too, but that's actually easy the way I represent it.
* It could (after beaming) consult beamings and "unsimplify" tuplings so
that they count as many notes as there are in the beaming. For nice
little 6-lets this is simple and obviously correct, but the rest+5 group
would be iffier, and for (say) a 6-let where a 6:4 16th was split into 4
6:4 64ths, it would be tricky. I could go by the longest piece in a
beamed group. The potential for tricky groups was one thing that drove
me to the present design. However, that was mostly about tricky
splitting and this would be post-splitting.
* Further questions *
On a similar note, Rewriter also decounterpoints everything. I have two
questions about that:
* Are there any use-cases where it's important to *not* split-and-tie
across barlines? Having to do that would really make this difficult, and
it seems just wrong anyways.
* Are there any use-cases where it's important not to decounterpoint?
That I can handle by just not rewriting except to split at barlines, and
I take the flag to do so, I just don't act on it because I'm not sure
it's the right thing to do.
Tom Breton (Tehom)
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
