|
Title: Fast plectrum strums and RTime. Post by: sciurius on June 25, 2021, 07:31:28 AM When using RTime with Plectrum strum, the randomisation is applied to each of the individual notes.
The attached image shows the notes of a typical strum without RTime (1) and what happens when RTime is applied (2). When the strum is fast the randomisation can effectively lead to a change in the order the strings are hit which I do not think is appropriate. For a fast strum, I think it is better to maintain the individual order of notes, but displace all notes with the same, random value (3). This corresponds to real life, where a slow strum may lead to slight time displacements in hitting the individual strings while in a fast strum there will be (little or) no individual displacements but the strum as a whole may be displaced. Alternatively, a correction can be applied in situations where stringn+1 would sound before stringn. For a slow strum, where the strum time is significantly larger than RTime the current behaviour is okay. What do you think? Title: Re: Fast plectrum strums and RTime. Post by: bvdp on June 25, 2021, 04:05:10 PM Perhaps a command to insert a random delay at the start of each bar? Or a <insert random delay here> marker in a sequence which would push everything to the right? Don't know how that would work in MMA syntax or in code, but is an interesting idea.
Title: Re: Fast plectrum strums and RTime. Post by: sciurius on June 26, 2021, 01:25:44 PM I don't see how that would solve the problem at hand, given that the sequences involved are strum sequences.
I think we need to distinguish two cases: If the strum value is <= 2*rtime: calculate a random displacement and apply this to all of the strings. Otherwise (current behaviour): apply a random displacement to each of the strings. But again, the issue is minor... |