Hi,

I'm working on my final year engineering project in Auckland, NZ, and I'm developing a DJ system that basically replicates what a CDJ does with pure data. Ofcourse, I came across the soundfiler issue of audio dropouts when loading tracks.

I thought of a potential way around this issue:

• Firstly using tables instead of arrays to reduce loading time
• Secondly, break the track into smaller parts (~300000 samples). This was done by playing the first 300000 samples, then incrementing the start position by 300000 samples and playing that, and so on.

This works sometimes. I've found that using Select to detect when the samples reach 300000, or 299999, does not trigger. If I use an if statement for triggering a bang, it only works if I make the threshold < 299500. If I set it to less, it does not always trigger the new section to begin playing...

Is there some sort of accuracy limitation? Why can't pure data detect the 300000th sample and trigger the new section when it's been detected?

Thanks in advance for any help!

Cheers

Depends on how you're patching it. Maybe you can post the relevant parts?

My guess is that it's an issue with converting the audio to messages. But until someone finally gets around to making a threaded [soundfiler], it's generally considered safest to just load all of the samples you're going to use before your performance.

@Architekt said:

• Firstly using tables instead of arrays to reduce loading time

do you mean using arrays instead of graphs ? I used to use these two words as perfect synonyms, meaning "a bunch of numbers with no front gui".

Nau

as Maestorm says, one of the big drawbacks to PD is that there isn't a threaded soundfiler. Which basically means that 'normal' sample loading is going to bumrush your computer and cause clicks/dropouts.

One way around this, which is really not ideal, is to playback your original sound with [readsf~] in an upsampled subpatch at a much faster rate, while loading it in to a table.

I've attached a patch which does this, and i can load files click-free at 64 times actual playback speed on my 2ghz mac.

If i were doing what you're doing, then that's the best way i can currently think to do it. The main problems are that you have to set the upsample rate yourself (using the [block~] object), and as far as i know, there's no way to set it to go 'as fast as possible'. You just have to trial and error for your system to see how fast you can get away with.

http://www.pdpatchrepo.info/hurleur/upsampled-loading.pd

This is really interesting, since I have exactly the same problem. I'm designing an ever-growing patch for live perfomances, which includes grain synthesis, drum samples, loopers, and all kinds of stuff which basically operates on audio samples. As you can imagine, whenever you are using the program creatively, you just need an audio file that you haven't loaded, or just want to substitute a sample for a particular module.

One question, when you refer to audio dropouts, do you guys mean just regular (but annoying) glitches or instead a situation where banging openpanel in search of an audio file completely freezes audio until file is selected? Because this is precisely what I've experienced

I think this is the main drawback I found in pd and it's very disappointing to see there's no way around. I wish pd devs work on this (I would if I had the required C programming skills).

The audio dropouts we are referring to are short silences that happen while the file loads (i.e., no [openpanel], just banging a message box to load the file in [soundfiler]).

The [openpanel] issue is also a drag, though even without it you still get the short drop-outs when the file is being loaded into the

yeey!!! ill definetely check the browser abstraction!