Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Second voice - collisions #355

Closed
yaras6 opened this issue Apr 29, 2020 · 2 comments · Fixed by #502
Closed

Second voice - collisions #355

yaras6 opened this issue Apr 29, 2020 · 2 comments · Fixed by #502
Assignees
Labels
area-rendering Everything related to the rendering state-accepted This is a valid topic to work on. type-feature 💡

Comments

@yaras6
Copy link

yaras6 commented Apr 29, 2020

Description

This task is related with behavior described in this question #353

Would be nice if library will detect collisions or alternatively second voice could have a class which allows me to make second voice more transparent.

image

Possible Solutions

No idea.

Current Workarounds

No workarounds.

@Danielku15 Danielku15 modified the milestones: 1.0.0, 1.x May 1, 2020
@Danielku15 Danielku15 self-assigned this May 1, 2020
@Danielku15 Danielku15 added type-feature 💡 area-rendering Everything related to the rendering priority-medium state-accepted This is a valid topic to work on. labels May 1, 2020
@yaras6
Copy link
Author

yaras6 commented May 5, 2020

@Danielku15 With this ticket, could you improve drawing rhythm for second voice as well? Thanks a lot in advance.

I am not sure why, but in some cases it works as expected, in other not. It is by bellow example:

image

@Danielku15 Danielku15 removed this from the 1.x milestone May 7, 2020
@Danielku15 Danielku15 added this to the 1.2 milestone Jul 21, 2020
@Danielku15
Copy link
Member

Dev Notes: Thanks to the spring-rod model we follow in alphaTab it is guaranteed that 2 notation elements across voices will always be aligned one after another. In Guitar Pro we can see this: nicely in this comparison:
image

Note: on Guitar Pro the rods of rests seem to span 1 notehead width, not the rest glyph size.
Explanation: On left the 3rd rest is before the 3rd note. To have enough space for the 3rd rest before the note the springs are stronger. It is guaranteed that 2 rods do not overlap because there is always a spring inbetween them and spring with force 0 has the width 0. On the right example, the 2nd rest is longer and the 3rd rest shifts after the 3rd note.

So there is never the case that notation elements at 2 different time positions can overlap partially as one rods follows the next. First we need to check in alphaTab that this constraint is also valid and properly followed. It could break if we 'accidentally' allow negative spring constants.

Having this pre-condition in place we can reduce the collision detection checks of rests to the elements of the exact same time position the rest is. Then things get a bit simpler as we can mark "lines" as used and just place the rest above/below the last used line based on some rules.

The AccidentalHelper already holds the min-max lines on a beat base. We can additionally cache the lines on a time base. When placing the rest glyphs of secondary voices we can just check against this list and displace the rest accordingly to do not overlap.

@Danielku15 Danielku15 removed this from the 1.2 milestone Jan 8, 2021
This was referenced Jan 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-rendering Everything related to the rendering state-accepted This is a valid topic to work on. type-feature 💡
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants