Thanks. So the solution is to have only two time-varying transformations and always apply one before the other. \
I suppose ... but I'm not sure what the problem is. Nice, though, to have solutions
Remembering the original on-time: I don't see why you would need this either. I was thinking along the lines of: what if we want 8th and 16th swing at the same time? If you apply 8th swing first, then the 16th swing would have trouble to detect the on-the-beat 8ths, because some of them would already be delayed by the 8th swing. But even that does not require remembering the original time, you just have to apply 16th swing first as it only alters notes which are of no interest to the 8th swing.
Well if you really want to have both 16th and 8th (or different skew rates, etc) it's pretty simple.
set swing to whatever
define some patterns
set swing to something else
define more patterns
I can almost guaranty that it'll sound unmusical. In most cases you want all the instruments/players doing the same swing manipulations. Mind you, my sense of "musical" may be quite different from yours
RTIME: I too have the feeling that it does not really mimic a sloppy player. There is only a small range between "no effect" and "too much". I believe it could be more "musical", but I don't know exactly how to do this. My current best guess is that it should favor delays over advances and it should randomize heavy notes (on-beats ...) less than the light ones.
The new rtime option which lets you set a min/max (ie Rtime 5,10) should help. In which case it never delays. Or you could do "rtime -5,10" or something like that. I think this helps.
But here you run exactly into the problem described above. If such randomization is applied after swing mode, it will have trouble to tell heavy notes from light ones. You would have to keep track of the original notes.
And now we have a definition problem: what is a "light" or "heavy" note? Duration? Place in the bar/beat? Volume?
I think we'll have humans playing for a few more years