issue with generateBeams and mixed subdivisions

[nitzanrh]

https://jsfiddle.net/qztxvrL1/

Notice that the 8th note isn't beamed to the 2 Sixteenth notes, although it should. If you modify the code and change the Quarter Note Triplets into 2 Eight Note Triplets, the beaming works as expected.

I didn't manage to replicate this issue when using only triplets or only sixteenth notes. I assume this has something to do with the Quarter Note Triplet disrupting the internal division of the stave into beats, but it's just a hunch.

Cheers, Nitzan

[ronyeh]

Thanks! Very interesting issue. :-)

[nitzanrh]

Hey guys, any news regarding this issue?

[rvilarl]

If you modify the code and change the Quarter Note Triplets into 2 Eight Note Triplets, the beaming works as expected.

could you add a jsfiddle with this working variant?

[nitzanrh]

@rvilarl

Yup, there you go: https://jsfiddle.net/w0eh8bfo/

Again, the only difference is having inside the triplet 2 eighth notes instead of a quarter note

[rvilarl]

@nitzanrh I think that the problem is that the third note was not in the array.

https://jsfiddle.net/9jwrnxmb/

[nitzanrh]

@nitzanrh I think that the problem is that the third note was not in the array.

https://jsfiddle.net/9jwrnxmb/

Not sure I follow... in the fiddle you sent, the triplet beat contains more than 3 eight notes (quarter note + 2 eighth notes). There are 2 arrays:

1. notesEighthTriplets for the first beat - which should include a sum of 3 eighth notes (triplets) and
2. notesSixteenth for the second beat - which should include a sum of 4 sixteenth notes

As mentioned, if the first beat is divided into 3 eighth notes - the beaming of the second beat is correct. However, if the first beat is divided into a quarter note and an eighth note, the beaming of the second beat is incorrect.

Strangely enough, the order in which the first beat is divided seems to make a difference: if the first beat is divided into an 8th note and a quarter note (in that order) the beaming of the second beat is incorrect, however if you reverse the order (ie the first beat divided into quarter note and then an 8th note) - the beaming of the second beat is correct.

Curiouser and curiouser...

[rvilarl]

@nitzanrh VexFlow represents what it is requested. VexFlow does not make many consistency checks. If you send a picture of the required representation, I can try to help to get it done.

[nitzanrh]

@rvilarl I'll try to explain my situation better:

I'm using vexflow to render rhythmic notation for drummers. One of the unique features of the app is that it generates the notes (somewhat) randomly - therefore I'm counting on generateBeams to handle the beaming automatically.

In most cases it works great. However when there is a measure with one beat divided into triplets and the other beat divided into 16th notes, generateBeams does not handle it properly.

If I were to manually manage the beams then of course it would work as expected, but since the notes are random I'm dependent on generateBeams to handle the beaming.

To your question, I'm trying to represent the following notes and handle the beaming using generateBeams (ie without setting the beaming manually)

Hope this makes things clearer :)

[rvilarl]

Ok I see, I misundrestood the problem statement. I will look into what generateBeams does.

[rvilarl]

@nitzanrh the code is really complex. Have you tried to look into it? It is strange how the notes in the front interfere with the auto beaming. I do not understand why the two initial notes produce the confussion. If tey are left out, the result is good.

https://jsfiddle.net/andgkjx8/

[nitzanrh]

I'll try to look into generateBeams and see if I can come up with anything :)

[nitzanrh]

@rvilarl I tried to look at generateBeams and as you said, it's quite complex so I didn't manage to see where the bug is coming from. However, I did manage to somewhat bypass the issue by calling generateBeams twice - once on the triplet notes and one on the 16th notes.