[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 37 - new work
From: |
Mike Solomon |
Subject: |
Re: Issue 37 - new work |
Date: |
Fri, 28 Jan 2011 08:22:52 -0500 |
I cooked up this musical example that shows both responses to upward and
downward pressure to give you an idea of where I'm coming from.
Is there a way to get this type of collision avoidance w/o a 2nd quanting pass?
Cheers,
~Mike
On Jan 28, 2011, at 7:45 AM, Han-Wen Nienhuys wrote:
> On Thu, Jan 27, 2011 at 12:47 AM, Mike Solomon <address@hidden> wrote:
>> Hey all,
>>
>> I have a new Issue 37 fix.
>>
>> The attached patch set implements a 2-pass approach through the quanting
>> that is potentially a huge time drain in scores with lots of collisions, but
>> likely not a time drain for most scores. The problem is that the quanting
>> algorithm, by fixing a region size, sometimes places all possible solutions
>> in a range in which a collision will happen. The algorithm will also
>> sometimes create collisions where
>
> The knee code has a similar problem. See Beam::shift_to_valid on how
> it was handled there.
>
> I'm not a fan of the 2 pass approach. With the 2-pass approach, you'd
> always forego any beams with more extreme slopes; also, this patch
> looks hackish,
>
>
> + Direction dir = to_dir (me->get_property ("collision-dir"));
> +
> + if (dir)
> + {
> + Real max_demerit = 0.0;
> + for (vsize i = qscores.size (); i--;)
> + max_demerit = max (max_demerit, qscores[i].demerits);
> +
> + for (vsize i = qscores.size (); i--;)
> + {
> + Real d = (yl * dir > qscores[i].yl * dir) || (yr * dir >
> qscores[i].yr * dir) ? max_demerit : 0.0;
> + qscores[i].demerits += d;
> + }
> + }
>
> Why not increase the region-size for beams that we know are
> problematic, similar to what we do for knees? In a typical score most
> beams will not have collisions, so performance would largely be
> unaffected.
>
> Have you tried rebasing your work on the proof-of-concept code that I sent?
>
>> there were none before, making it impossible to check for them beforehand.
>
> I dont understand what you mean here.
>
>> Thus, we need to let that collision happen, then move the beam such that it
>> is >around the point of the collision, and then rerun the quanting
>> algorithm. If you >only apply the first patch, you'll still get something
>> that works, but w/ no good >quanting.
>>
>> I'd like to hear your opinions - do you see anyway to trim down the
>> computations?
>>
>> I've been using the attached .ly file to monitor the results. The only odd
>> thing is the small beam for the C that is being squashed by the G, but I
>> can't figure out a better solution with proper quants. The alternative here
>> would be just turning off the collision avoiding, but I haven't figured out
>> how to do that in that particular scenario. Otherwise, all of Han-Wen's
>> concerns are addressed. And, as before, the truly heinous collisions are
>> unavoidable because there is no way to anticipate desired output.
>>
>> I still need to do a make check.
>>
>
>
>
> --
> Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen
- Issue 37 - new work, Mike Solomon, 2011/01/26
- Re: Issue 37 - new work, Han-Wen Nienhuys, 2011/01/28
- Re: Issue 37 - new work, Mike Solomon, 2011/01/28
- Re: Issue 37 - new work,
Mike Solomon <=
- Re: Issue 37 - new work, David Kastrup, 2011/01/28
- Re: Issue 37 - new work, Graham Percival, 2011/01/28
- Re: Issue 37 - new work, David Kastrup, 2011/01/28
- Re: Issue 37 - new work, address@hidden, 2011/01/28
- Re: Issue 37 - new work, Han-Wen Nienhuys, 2011/01/29
- Re: Issue 37 - new work, address@hidden, 2011/01/29
- Re: Issue 37 - new work, Han-Wen Nienhuys, 2011/01/29
- Re: Issue 37 - new work, address@hidden, 2011/01/29
- Re: Issue 37 - new work, Han-Wen Nienhuys, 2011/01/28
- Re: Issue 37 - new work, Graham Percival, 2011/01/28