Arpeggio Stretch
What does the stretch value actually mean? Is it a multiple of the score tempo or of the note duration or some combination of these values?
Do you still have an unanswered question? Please log in first to post your question.
What does the stretch value actually mean? Is it a multiple of the score tempo or of the note duration or some combination of these values?
Do you still have an unanswered question? Please log in first to post your question.
Comments
Have a look at this:
Guitar_strum_accompany.mscz
Please note that this is an old file from a forum post I made when the arpeggio stretch feature was not available. It showed how to 'force' a faster strum by shortening the duration of the note that the arpeggio was attached to. All text in black is old. You want to read the red text.
In reply to Have a look at this: … by Jm6stringer
Here's what I see...
If the OnTime of an arppeggiated note is, say, 800 at 'normal' 1.00 stretch, then at 0.30 stretch the OnTime of the note will be .3 x 800 = 240
Look at the PRE (piano roll editor). At reduced stretch, the notes start earlier and so the arpeggio sounds 'faster'.
Edit: So, I checked an arpeggio with stretch = 1.00 that had OnTime values 133 - 266 - 400 - 533 and 666. With an arpeggio stretch = 0.10, those values were 13 - 26 - 40 - 53 and 66.
OnTime for the first note is always 0 whether arpeggiated or played as a 'block' chord (all at once).
In reply to Here's what I see... If the… by Jm6stringer
Thanks. I am also seeing this 133, 266 ... sequence as the default which would suggest that the arpeggio would be slower if the notes are minims than if they are crotchets since 133/1000ths of a minim is obviously longer than 133/1000ths of a crotchet played at the same tempo. I will check to see if this default 400/3 interval is the same at other tempos or whether it is adjusted for tempo.
When an arpeggio's onTime values are not manually adjusted in PRE they do not appear at all in Musescore's saved XML so they must be getting generated "on-the-fly" for PRE, possibly at the time the score is loaded.
In reply to Thanks. I am also seeing… by yonah_ag
...the arpeggio would be slower if the notes are minims than if they are crotchets...
Not necessarily, because each unit of Len = 1000 differs in real time for minim vs. crotchet.
Here's another "old" file: electric_guitar_strum.piano roll.mscz
In the file...
Any PRE image shows its (blue colored) chord immediately above it.
This file was created before arpeggio stretch was available, so all arpeggios are default stretch 1.00 when opened in the current version of MuseScore.
Compare the minim strum to the crotchet strum. The "speed of the strum" plays the same for minim as for crotchet.
Since a crotchet's total duration is half the duration of a minim, the Len values (even though total Len = 1000 for any note duration) are based on different time scales.
So, OnTime of 200 for a minim would be comparable to an OnTime of 400 in a crotchet, because 200 minim "time units" are equal to 400 crorchet "time units".
The minim spreads its Len = 1000 over a broad time span. The crotchet spreads its Len = 1000 over half that time span, so each crotchet "time unit" is smaller by half.
At small enough note durations (e.g., semiquaver) the arpeggio, or "strum", needs to be performed faster to fit into the total Len = 1000. That's why we used a small note duration with a tie to a note of a larger duration. A semiquaver would "speed up" the strum. (Which was the workaround before the stretch feature was available.)
In reply to ...the arpeggio would be… by Jm6stringer
Yes, that's exactly what I mean. An arpeggio of onTimes 133, 266, 400 with minims would be slower than an arpeggio of 133, 266, 400 with crotchets because the 1000 full note durations are different. I need to handle arpeggios in my "Let Ring" plugout so I need to use the 400/3 step and divide by 2 for minims, 4 for semibreves, 0.5 for quavers etc. then multiply by the stretch factor and round to an integer.
Thankfully the 'no stretch factor arpeggio' version of Musescore was before my time as a user but the workaround is neat.
In reply to Yes, that's exactly what I… by yonah_ag
Turns out that it's slightly more complicated as the tempo needs to factored in so that the time offset between notes, for any given stretch factor, is the same absolute duration even when the note type and tempo are changed. So the 133 OnTime seen at 120 bpm would be 133 x 117 / 120 at 117 bpm. i.e around 130.