Timing issue when using table/play and a sequencer for playing single shot drums!

#1

Hello!

Since the wave/play doesn't have a pitch function I have been trying to use the table/play to playback single drum shots. But I ran into some really weird timing issues.

See picture:
The sequencer selects which sample is selected 001-064. But the problem is that when the sequencer reaches the higher numbered samples, like 048, 064, etc. the clock timing slows down, radically. It is almost like the value of the sequencer affects how fast the clock is running. It starts of by playing fast and slows down as it reaches higher numbered values in the sequencer.

I have reproduced this issue with several kits of 64 single saved drums. If you have some single sounds saved as 001-064, then load them with the string/index and I am pretty sure you will get same result.

I tested that it is the same on 1.0.11, to make sure it isnt related to the new 1.0.12. I also tested exact same setup with wav/play and that works without any issues(but no pitch....). I also tested with removing the name in the string/index and then it plays at the same tempo. So it seems related to whatever is being loaded into the table/play.

This is really a mystery to me. Is there a technical explanation for it? Or might it be a bug?

Argh, hard to explain.... Is this understandable? This is something that you have to test fr yourself to understand, cause it doesnt make any sense.....

ANY HELP APPRECIATED :wink:

@johannes?

ISSUE WITH TIMING 1.axp (7.7 KB)

problem.png1146x421 41.8 KB

#2

Hmm weird. The only thing I see is that your patch is not following execution order. Sometimes that can cause unexpectes bugs.

#3

Hey @Blindsmyth.

Yes, I find this very weird. It makes it impossible to use table/play as a sample player. Did you also do a test with samples? Or is you suggestion from looking at the picture?

If you didnt do the test and if you have some samples allready organised, would you be so kind of doin the test with samples? If you dunt have samples organised all ready, I can send some when I am home in the afternoon.

#4

The cause is the table/load object, it causes an audio dropout, you'll hear an interruption when triggering table/load while something else is producing sound. This causes "lost time" on the clock.

I could create a "threaded" version of table/load, that will do the job of loading the file into the table outside the audio computation deadline, but if you 'd trigger loading and play it, it will not be ready with loading yet, so playback will be glitchy. That could be circumvented by loading the next sample file while playing the current (assuming a non-existent "threaded" table load object), but would requires that the next sample file is already known while playing the current, and doing a "pingpong" game with 2 tables, one for playing and one for loading, and swapping the role of those between every sample, this would be painful to patch, better expressed in code.

wave/play is made for 'streaming', it does not load the whole file at once but uses a "thread" to load file segments as needed. The reason wave/play does not have a pitch input is that if it would be transposed up by, say, 4 octaves, it would cause quite a storm (16 times as much sdcard traffic) as compared to non-transposed playback.

#5

Ahh that makes sense :slight_smile: I thought that there must be a technical explanation for this.

Thank you for suggesting making a new version, but from what you describe, I don't think it will do the trick, cause I often use a random modulation source to trigger different samples. It won't know before hand what comes next, so it is impossible to load it into a table.

Ah yeah I see the issue. That would take a lot of processing.

Guess I just have to rethink my idea. Maybe I could drag a bunch of samples into a daw and allign 64 drum hits after each other and export it as a single file and then load it into a table as a singe file instead of reloading the table with single shots, which is th cause of the problem. It takes a lot more preparation, but it could work.....

Any suggestions on how to achieve same goal, would be greatly appreciated :slight_smile:

Anyway, thanks for looking into it @johannes :wink:

#6

I could create a "threaded" version of table/load

....yes please! And also,a threaded version of table/save would be MUCH appreciated!

#7

After thinking a little bit about the threaded version;

Would it be possible to make a version where you could load many files, like maybe 64 files into, instead of just the next file? Basically preloaded the 64 files to avoid those issues?

(64 steps in a beat is equivalent to 4 bars of 16th notes. less than 64 could probably do, but 64 would be a really good number IMO).