![]() ![]() ![]() In most cases, the sonically pleasing loops are a mix of sharp hits, pads or swells and rhythmically undefined filler paint that need quite a bit of manual work to properly play at different bpm. I've thrown it away after finding that maybe only 5% of the loops didn't need any manual correction. Good luck! yes, that's exactly what I did in my AutoIt script and the way I've applied it to a selection of different WAVs. If you create your loops from samples (as opposed to live recording), there may be a solution but it's rather complicated and I will not go into detail here. Yes, it "worked", I had a bunch of RX2 files in the end, all created with a static setting of, say, 70% slice detection level in Recycle, but as you may have experienced by now, this is only 10% of the story. I had the same problem and I have programmed a WAV/AIFF to RX2 "batch converter". If you are not ready to do the manual work, you better not include any loops in RX2 format as they would be worthless anyway if they sound bad when sped up or slowed down. BTW, you can at least batch convert REX/RX2 to Apple Loops using Apple's Loop Utility. It's "just one more format", but one that you have to put some lovely labour into. (just like Acid WAV or Apple Loops that must be properly sliced just as well!) Well, the solution is manual hard work. Automation of this process only works if every drum/percussion hit is 100% isolated from the other and there is a short silence between each hit, and that's rarely the case (but I don't know your loops). That's also where I blame the propellerheads: While during the past years they have slightly updated Recycle in terms of functionality and file handling, they have in no way improved the slice detection quality. Yes, and have you listened to the result at different tempos, like +30% or -30%? Only a properly sliced REX(2) file will still sound good, and proper slicing almost always means manual, 'tortural' slice point editing. ![]()
0 Comments
Leave a Reply. |