Skip to main content
Topic: An experiment in tuplets (Read 8258 times) previous topic - next topic

An experiment in tuplets

I did not want to call this "how to write tuplets", because my method has a few drawbacks. Still, it might be useful in one or another situation. Concepts:

  • Dots and double-dots are used as much as possible to distribute the note lengths roughly equally over the tuplet - then, with "extra dot spacing" -1, the dots are suppressed.
  • For some tuplet values, dotting does not work. In that case, tied invisible notes are prepended to the visible notes - prepended so that the ties are not visible; the first note, however, is never preceded by a tied note, because otherwise it would not line up with the beat.
  • And for some values, an invisible triplet spanning the whole tuplet allows a somewhat better distribution of the note values.
  • Drawing the beams is typically done with NWC's builtin beams. However, in a handful of cases, the new version 0.6 of the Beam.hmm object is needed to draw one beam less than the note values would usually request: For example, a septuplet in 3/4 time gets only one beam, even though the "eighths" are a little bit shorter than real eighths (and are therefore created mostly with double-dotted sixteenths).

Of course, this dot/double-dot/triplet combination method always leads to not perfectly divided tuplets when playing - but this is acceptable in many cases, I would say.

For the tuplet bracket, I have for the moment used the LineSpan.nw object, with a manually placed text. It would be nice if the LineSpan object could place a centered text - and place it in its line - out of the box ...

To use one of these tuplets in your scores, I suggest you download the attached NWC file, copy the tuplets to your score and move the notes up or down as needed. Tuplets that do not use 64ths can of course be shrunk by a factor of two (select, then press minus), those not using 32nds can also be shrunk by a factor of 4.

H.M.


Re: An experiment in tuplets

Reply #1
I understand the approach you are taking here, and it's an interesting one. However, another approach occurred to me, that was inspired by your second version of CueStaff.hmm. You never did explain how that approach worked, although I poked around a little in the object's code, and I think I figured out enough of the general approach to see how it could be applied to the tuplet problem.

Imagine that a user wishes to create a custom tuplet at some spot in their score. They would insert the tuplet notation as grace notes, and then make the notes hidden and muted. This gives them zero duration in the measure. Then, they would insert a non-grace rest of the desired duration of the tuplet, and mark that hidden as well.  Immediately preceding these notes, there would be a user object, which would have necessary parameters to control the appearance (and playback) of the tuplet. The object would then loop over the grace notes and draw them on the staff as regular notes, using the appropriate properties of the grace notes (stem direction, beam type, "duration", etc.)

I've left out some details, but let me know if this approach could work in theory. It could be a bit simpler than the CueStaff object since it only needs to draw notes, and maybe rests.  Does the idea sound feasible?

Mike

 

Re: An experiment in tuplets

Reply #2
they would insert a non-grace rest of the desired duration of the tuplet, and mark that hidden as well.  Immediately preceding these notes, there would be a user object, which would have necessary parameters to control the appearance (and playback) of the tuplet.
Without knowing the durations and appearance of notes on other staves, the user object could not get the appearance right.
Registered user since 1996

Re: An experiment in tuplets

Reply #3
Without knowing the durations and appearance of notes on other staves, the user object could not get the appearance right.
How about "marker 16ths" (or 32nds etc.; see attached example) with 0 stems and blank heads? They seem to spread correctly (check with Alt-F V! - the spreading in the editor is irrelevant) - and nothing else seems to spread correctly. Of course, all these "blank head features" collide with CueHeads ....

H.M.

Re: An experiment in tuplets

Reply #4
Imagine that a user wishes to create a custom tuplet at some spot in their score. They would insert the tuplet notation as grace notes, and then make the notes hidden and muted. ... user object, which would have necessary parameters to control the ... playback ...
Playback ... hm. Of course the plugin could compute equally distributed durations for the tuplet notes; but it would also have to consider all the articulations (on the "controller cue notes"!), current velocities (only problematic in case of cresc/decresc and hairpins*, I'd say), performance style - and more? That is why I essentially gave up my second idea about cue staffs - for the moment, at least ...

* BTW, hairpins also seem to require "nicely spreading items" to be shown correctly.

H.M.

Re: An experiment in tuplets

Reply #5
Of course, all these "blank head features" collide with CueHeads ....
One thing I forgot to mention before is that you can "turn off" CueHeads temporarily in your score by inserting a hidden CueHeads object, and then turn it on again later by inserting another object instance, this time unhidden. Alternately, inserting a copy with Class set to Standard will stop its StaffSig behavior, and not insert the "banner" in your score. In fact, if your score only contains a few cue sized notes, you can insert Standard CueHeads immediately before those notes, instead of using the StaffSig object.

Re: An experiment in tuplets

Reply #6
How about ... 0 stems and blank heads? They seem to spread correctly
0 stems are OK, but you might as well make the noteheads visible. Easier that way, I think.
Registered user since 1996

Re: An experiment in tuplets

Reply #7
0 stems are OK, but you might as well make the noteheads visible. Easier that way, I think.
I think what Mike wanted to do is to draw e.g. a quintuplet, septuplet etc. with equally spaced noteheads, i.e., at positions where NWC would never put them. Thus, the 16ths or 32nds would only span a raster into which the user object would then interpolate the off-raster positions of the tuplet's note heads, and draw them there; and thus the "raster notes" should not show any noteheads ... if I understood Mike's idea correctly.

H.M.

Re: An experiment in tuplets

Reply #8
I probably didn't explain it very well, so let me try again. There would be a cluster of invisible muted grace notes, that would only be present to establish the pitch, articulation, accidentals, etc. of each tuplet note. Then you put a hidden normal (non-grace) rest after that, to take up the appropriate staff duration (so the measure is properly filled). Maybe you also need to add a spacer there if there is only a single staff, so the measure doesn't collapse (I forgot to mention that last time.)  Anyway... the user object could be right before the grace notes, and it could have a parameter to specify how many tuplet notes to expect. So it would look ahead in the measure to see how much space was available, and it would place the "n" notes there appropriately spaced (I would say "equally spaced" but some might have accidentals, which would mess up the spacing. I didn't say the object would be simple :) )

The idea is that if I am putting a septuplet run in staff #1 and there are 4 quarter notes in staff #2, I really don't care if the notes line up exactly.

Does that make more sense?

Re: An experiment in tuplets

Reply #9
For me, it does - ...

... except that I still think that using a hidden rest is not the best idea, because for finding the end of the stretch into which the plugin then places the noteheads, it has to heuristically use the "next object after the note", e.g. a bar - but then, it does not get from NWC any information about any "padding" around the bar; and it does not work for single staff scores except with manual spacing (which somehow defies NWC quite nice note placing capabilities).

Two stem-0 headless ("raster") notes of equal duration are, in my humble opinion, better - the plugin measures the distance between them and doubles this distance to get the complete distance where to distribute the noteheads.

On another note, I changed the attachment to the initial posting, so that it (a) shows that slurs work nicely; and (b) some length distributions are not now better than before, especially for playback.

H.M.

// Edit: Mhm ... English ...