Hi all,

I'm using my computer (which is 800Mhz) in pretty intensive way for audio only, and i couldn't manage to load audio in tables without glitches while playing other samples. It seems like the [soundfiler] sucks every bit of my cpu out when it's working.

I also noticed that i didn't need the loading to be instantaneous (for most purposes), and i use only few seconds sound bites...

So i came up with a patch to fill a table using [readsf~] and then resize that table according to the soundbite's length, it (the patch) also outputs the soundbite's name.
It's working quite well for me.

Corrections, Comments, improvements, are welcome

http://www.pdpatchrepo.info/hurleur/sampleload.noglitch.pd

cheers for the block tips here, i suspect they are the answer to many a PD headache I have had when live-sampling!

The upsampling tip is useful...

Here's what I'm doing - I want to be able to record live into a table of variable length and then display the waveform in a graph-on-parent (so I'd need the table to be exactly the length of what I just recorded). So I record to a really long temptable first, resize the realtable to the number of samples I just recorded (calculated by [timer] * 44.1]) then use the upsampling in a subpatch where I send the output of [tabplay~ temptable] to the input of [tabwrite~ realtable]. It's a lot better than using [until], but still causes a little bit of a break in the sound output.

Does anyone know a better way to do this with no break at all?

Thanks!

i think you can send messages to tables to set the visual parameters - i know you can set the y-range, but i'm not sure about the x-range - something to maybe look into (and sorry if that's a wild goose chase)? resizing tables is an operation that can cause drop-outs, because memory allocation can take quite some time depending on the OS etc (not to mention pd's gui sucks at efficiency for displaying tables)

if you only want a display of your audio, and thus not intended for playback, you could eg setup a "display" table with length 256. when your real audio table is loaded, you could then setup an until objects which reads 256 points out of the audio table an writes them in the display table (using audiolength/256*index).

Ah yes. Thanks for the suggestion, domien.

ClaudiusMaximus - setting the y-range to something smaller than the size of the table will just make the overflow draw on the screen anyway. Even if it's in a subpatch, I'll have a flat line going out past the boundaries of the subpatch. Is there a way around this?

also, whatever route you take, make sure your array is set up to graph 'points', not lines. it's much nicer for audio representation anyway.

@hardoff said:

also, whatever route you take, make sure your array is set up to graph 'points', not lines. it's much nicer for audio representation anyway.

That's true, but graph lines is way faster than points...

Domien,

I just tried your until method a short table for the display. 256 was way too short and didn't give me a very meaningful view - so I tried 1024. Choosing 1024 regularly spaced samples from the table doesn't give you the points that tell you the wave's amplitude - it gives you random points in the wave, so it doesn't give you a very good picture. The amplitudes shown don't necessarily reflect the amplitude of the real thing - it especially seems like you get pretty random results for tables with a bunch of really short sounds (clicking, popping). Here's a screen shot - I had to make Y range .08 to -.08 to see anything.

What else could I try?

http://www.pdpatchrepo.info/hurleur/weird_display.png

Fellas, anyone have an example of how this excellent abstraction is incorporated into a looper or a sampler?