I use the sampler on my dt2
I record the master, and make a 128 steps loop.
This loop is played in its own pattern, trigged by 1st and the it is looped foreward.
I go to a new pattern, the loop keeps on playing, the. I can mix in the new pattern and go on to next ‘song’, like a dj.
But…. I have to nudge foreward the new pattern, because the loop is not exactly 128 but a bit shortstory. It is only a little bit, but it affects a lot when looping for a while
I prefer not to care about it.
Why the loop is not exactly 128?
Is this a bug?
What can I do?
possibly - but it doesn’t sound like a bug - this is why it’s nigh on impossible to get pedal loopers to play nicely with MIDI - the looping algorithm would have to be flexible enough to accept a bit of give/take on the position of the loop and the loop length
it’s just something to work with / around unfortunately - unless there’s a sample playback mode which does precisely what you need
not sure why dn1 would seem to be more robust in a similar test
If it’s recording a slightly truncated file, then that’s an issue
If you expect the 128bar sample to eternally loop perfectly in pace with the system clock it just won’t happen like that
If it’s wildly off after one pass that’s different, but it’s not a strategy i’d lean on unless the sample could be automatically expanded/contracted to stay with an internal clock … all the sample is doing is looping its own fixed duration, there won’t be enough accuracy to rely on a sequencer to stay in phase with that, even if the sample length was seemingly bang on
if a sample is the full length, it’s better just to retrigger it rather than loop it in this case above … imho
I dont understand this answer
I can set 2, 4, 8, 16, etc steps (till 128) in my sampler as sample length.
The problem is, when I set to 128, the length of the loop is a tiny bit shorter
The question is, is this a bug?
Cool thing about the current situation is, that I nudge the pattern to be in sync again…. This geves vinyl dj vybes, Some tention because it feels unstable
I understand
I use the loop and turn of the sequencer, for song transition with such a result
I can copy the src page and use the sequencer on the new song, but it compexicates. Would be very handy (and I think possible) to ‘tune’ the recorder length slightly better
I probably need to try to see what happens in practice … with a standalone device setting its own tempo the looping ‘sync’ may feel good for a while, but if the tempo was dictated by an external midi clock then the sample and sequence may drift apart sooner … it’s just not a strategy I’d lean on to work reliably as a norm, it is useful to nudge the sequencer for sure
It still seems optimistic to have the sample freely loop in sync with a sequence, unless the recorded sample length is in fact trimmed too short/long and it’s somehow manifesting worse than it should
My expectation would be similar to yours. If I ask the sampler to sample exactly 128 steps I would expect it to do that. The link I gave to the bugs thread is about DT2 failing to do that and recording 1 millisecond less than that.
Whether that’s the cause of your problem, or the other things that @avantronica has highlighted, i don’t know.
it could be an issue that crept in when extending the sequence length, it’s not something i’ve tried out (or would opt to do in practice tbf) - so maybe it’s more than an ‘expectation’ thing … do some research, compare behaviours of looping 16/32/64/128 length recordings to see how the sync fairs between those (and another device if possible) … build a case for it being a bug aot optimistic
Isn’t this just the impact of the zero-crossing detection truncating the beginning of the sample? It starts with a fixed length of 128 steps but because you’re probably using the gate to start the recording, which it does when the set threshold is achieved, it then records a length of 128 steps thus it knows where the end point is, but the beginning is determined not by the recorder start, but by the first “detected zero crossing” in the total recording which happens to have a maximum length of 128 steps as determined by how you set it up.
The algorithm must perform this detection after the act of recording. It has to, as zero-crossing is not used as a triggering mechanism, because it is sound detection above the set threshold which triggers the gate. So, because there is no recording buffer which exists before the trigger, the zero-crossing algorithm can’t find something that exists from before the gate is activated and naturally it’s going to then truncate whatever is after the start point, but before the detected zero crossing, creating a sample that is shorter than 128 steps.
Have to disagree sorry If the user interface offers to record 128 steps, and what it actually does is record 128 steps minus a millisecond or two, then I’d call that a bug.
(Unless there’s some note in the manual that clarifies that the offer of recording 128 steps is approximate)
I don’t know. Math is quite consistent and as long as the same CPU handles clock timing and audio sample timing, it should match exactly “forever”, as the same timing algorithm feeds the sequencing and the sample playing. Even if there is some jitter in the timing, it should smooth out over time (if it’s implemented correctly). Audio needs to be clocked as well, so there is no “free running” of audio in such a device. The code is continuously called in explicit time intervals to send the next Sample(s) to the DACs.
No, I use r.strt and arm on —> then restart and record 128 steps (sometimes it is better to set start of loop to 60, to have the second half of the 128 steps only, to deal with effects that sound different in the beginnjng
I think the new update fixes the problem , till now it is very good. I can make a loop, oneshot it, make some coffee, and it keeps on being in sync
Edit: It is amazing! Fantastic! Right update at the right time! Everything I wished for, incl routable distortion, monosampling, comb+, and mainly tight sampling! What a day🤙
Edit 2: release notes mention this: ‘ The length of the recording could be slightly incorrect when using the R.LEN parameter in the SAMPLING menu to record a set number of steps at the current BPM.’
If the user interface offers to record 128 steps, and what it actually does is record 128 steps minus a millisecond or two, then I’d call that a bug.