Regarding ReaReaRea:
At first thx, it is really great seeing more "creative" stretch algorithms introduced.
My concern: It seems that this algorithm is somehow "unstable/unpredictable" (maybe even in a intended/superior way, who knows [not me]
) --> I let you be the final judge. Let me explain:
[BTW i have tested with 0% ranodmization]
It seems that this algorithm is a "feedback/feedforward" realtime audio processor rather than a items "manipulation" which would be baking the results into the "virtual" item.
--> When i stretch out a Drum Sample (e.g. Rimshot) and try to play it back it seems to matter where the playbackcursor is located --> the Audio which is playing back differs if I have the playcuror before or over the file --> the played back audio isnīt the same. During playback this kind of seems neglectable but what if I would like a certain part out of an audiofile and have it rendered:
This also comes into play when rendering Timeselection (action:"Render selected area of track") and I would only like to render a part out of the item I stretched but not inlcuding a certain beginning portion of the item (but still having the beginning section "affecting/ringing out" in the following (rendered) audio). e.g. not including the drum transient in the timeselection but still gettting its grainy character into the rest of file.
I am not sure if the "baked in" scenario is even possible/desired or worse, but for some (like me) this might be a reason to file a bugreport when audio playback vary on differnt cursor position --> especially if they donīt know the "fineprint" with this algorithm. (so just a "heads-up")
If it is intended, then all is good. Just wanted to let you know about my user-scenario.