Hi. This is something I run into in pretty much every project but this is the first time I was able to reproduce it in a straightforward .xrns file. What happens (for me at least) is that there are some pops here at the end of some beats (like those that happen when you don’t correctly chop at the transient). Thing is they sound random/inconsistent. I mean every playthrough results in different beats messing up. You can also hear it when you loop a section that’s busy with chops.
I suspect this might not be specific to phrases since I run into this pretty often but this is the best I could capture it. If this runs normally for others, I’ll capture a video or something to elaborate.
What happens (for me at least) is that there are some pops here at the end of some beats (like those that happen when you don’t correctly chop at the transient).
I tried rendering the pattern after duplicating it a number of times. And yes, they are slightly different, although not random - the differences tend to repeat themselves after a while.
After taking a closer look, I’m a bit puzzled. As I understand it, the “flam” (double-hit) effect should actually be more prominent, because that’s how the drumloops seems to be sliced + sequenced (some drum hits arrive a little bit early, on the line before). Obviously, this is something to be aware of when slicing up a beat where markers somewhere before the actual beat and then rendering those slices to a phrase.
But in any case, something fishy is going on. I think those renderings were supposed to be identical
Rendering slices to phrase will make the notes appear according to the groove of the break, this is why you can see delay values next to the notes. If you don’t go ahead and hard-quantize your drum hits to the grid according to their “supposed” positions (assuming the break would have no groove) then these inconsistencies will appear. Since you trigger the note later than it appears in the phrase you hear a flam-like snare. Pretty logical.
All I did was removing delay values and moving the hits to their correspondent positions. Yes, you will lose the original groove of the break if you do that, but you can still humanize your drums individually so they don’t clash when triggering.
Hey, I think I figured it out! Not sure if this is specific to my setup but it seems to be something about buffer size… I generally use 2048 samples and that seems to create some inconsistencies in timings of the beats. When I use 64 samples the playthrough’s are identical.
I honestly don’t understand your problem.
Perhaps that’s why you haven’t noticed anything odd. Here’s a simpler file that has a consistent flam effect on line 13 (19 in decimal) when the buffer size is 64 samples. When I increase the buffer size to 2048, that line sounds silent for the first playthrough, and has a less promiment flam effect on the 2nd one.
I didn’t change by buffer size but that example doesn’t play back consistently for me, now and then the line 20 (decimal, in the pattern editor) produces a glitch.
Perhaps that’s why you haven’t noticed anything odd. Here’s a simpler file that has a consistent flam effect on line 13 (19 in decimal) when the buffer size is 64 samples. When I increase the buffer size to 2048, that line sounds silent for the first playthrough, and has a less promiment flam effect on the 2nd one.
I actually noticed something odd and I understand the timing problem. Renoise seems to exert an internal swing/groove which fluctuates by an amount of very few samples. I reckon it’s not really a bug, it’s just a timing feature due to technical reasons or whatever you may call it.
Here is another reproducable example that I made. Let the pattern loop a few times. Theoretically the sample should always forward-reverse when the playback marker hits B1, but that’s what it doesn’t do in approximately 30 % of all playbacks. What happens is the sample runs out backward before it hits B1 by a matter or samples and thus can’t forward-reverse again.
