Lyrics are allowed to display in overlapping fashion

[GoogleCodeExporter]

A long lyric token string is not truncated when displayed on the piano roll
and is allowed to overlap other lyric token strings.

This is low priority because it's superficial.  Perhaps it could be a user
preference whether these lyrics are displayed as truncated.

Original issue reported on code.google.com by raynebc on 10 May 2010 at 7:31

[GoogleCodeExporter]

I think it would be neat to display the lyrics as truncated with the lyric text 
for 
the note under the mouse displayed in full with a black background. This way 
you could 
easily see which lyric you are about to click.

Original comment by xander4j...@yahoo.com on 12 May 2010 at 9:06

[GoogleCodeExporter]

That sounds like a pretty cool idea.  If the change would be in
eof_render_lyric_preview(), I can look into it when I get home.

Original comment by raynebc on 12 May 2010 at 9:13

[GoogleCodeExporter]

My bad, it's not in eof_render_lyric_preview().  I'll look into it nonetheless.

Original comment by raynebc on 12 May 2010 at 9:17

[GoogleCodeExporter]

Original comment by xander4j...@yahoo.com on 13 May 2010 at 4:20

• Changed state: Started

[GoogleCodeExporter]

Original comment by xander4j...@yahoo.com on 13 May 2010 at 4:44

• Changed state: Fixed

[GoogleCodeExporter]

This new logic is pretty cool, but if a lyric is long enough, it is still 
printed to
all the way past the end of the next lyric(s), instead of being truncated.  The
easiest way to fix this would probably be to black out the remainder of the 
lyric
text area on the top of the piano roll each time a lyric is rendered there.  
For example:

for(all lyrics to draw on top of the piano roll)
{
  Print lyric in lyric lane
  Print a string of spaces with black background to truncate for the previous lyric
}

So if the first lyric was:
"Saaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaay"
and the second was:
"what",
Printing the string of spaces would erase what was left in the lyric lane after 
the
end of "what", effectively truncating the prior lyric.

I tried to write the logic to do this in eof_lyric_draw(), but I couldn't 
figure out
how to make it not incorrectly erase lyrics when it was used to render the 
currently
hovered-over or playback position lyric.

Original comment by raynebc on 14 May 2010 at 1:05

• Changed state: Started

[GoogleCodeExporter]

My above logic would probably be required to have all "on-screen" lyrics be
re-rendered left to right, starting with the one passed to eof_lyric_draw(), 
each
time the function is called.  Otherwise the drawing of the black background 
spaces
would erase lyrics that are supposed to be left visible.

Original comment by raynebc on 14 May 2010 at 1:09

[GoogleCodeExporter]

r106 implements some new logic regarding the clipping rectangle, which should
guarantee that a lyric doesn't render far enough to the right for another lyric 
to
render on top of it.

Original comment by raynebc on 14 May 2010 at 3:30

[GoogleCodeExporter]

I think that another improvement to this (to make the moused-over lyric more 
readable
among a jumble of truncated lyrics), is to prefix and append the moused-over 
lyric
text with one space character.  This way, mousing over a lyric in the middle of
truncated lyrics like "whentheyput" will display " they " to make it stand out. 
 I
think there are some cases where even with the new clipping, a lyric can render 
on
top of another.  This may be a flaw with the new logic, or it could be a flaw 
with
Allegro's clipping, I'm not sure.

Original comment by raynebc on 14 May 2010 at 3:38

[GoogleCodeExporter]

I think just drawing a black border a couple of pixels wide on each side would 
suffice.

By "I think there are some cases where even with the new clipping, a lyric can 
render 
on top of another" do you mean one lyrics text overlaps another so that you see 
both 
jumbled together?

Original comment by xander4j...@yahoo.com on 14 May 2010 at 4:47

[GoogleCodeExporter]

I think just the way the lyrics appear truncated confused me a bit.  It does 
seem to
be doing better with the 2 pixel whitespace between each lyric.  That 2 could be
easily changed by subtracting a larger number from X2 in 
eof_lyric_draw_truncate().

The border around hovered lyric idea sounds really good.  I think this can be
elaborated further so that the hovered lyric is also displayed in a slightly 
larger
font size, given the effect of using the mouse as a magnifying glass to inspect
closely-grouped lyrics.

Original comment by raynebc on 14 May 2010 at 5:44

[GoogleCodeExporter]

I think the overlapping problem has been resolved, the rest of this involves 
enhancing the way it works.

Original comment by raynebc on 11 Aug 2010 at 6:55

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I don't know if the "magnifying glass" feature would be very easy to do without 
loading a different font set.  It might not be worth the hassle, but drawing a 
black border is certainly more feasible.

Original comment by raynebc on 23 Sep 2010 at 9:49

[GoogleCodeExporter]

Thinking about it some more, it should be relatively easy to render the hover 
lyric to a bitmap (similarly to how fret numbers are being done for 3D preview) 
and just scale that bitmap a bit before rendering it into the editor window.

Original comment by raynebc on 13 Nov 2011 at 7:41

[GoogleCodeExporter]

Original comment by raynebc on 13 Nov 2011 at 7:41

• Added labels: Priority-Medium
• Removed labels: Priority-Low