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

HI weng

hope this is what you mean...

generally you'll find it better to preload all your tables before playback, that is, load all the samples into ram. Then there'll be no glitches when switching tables.

There are various ways to do this dynamically. One idea would be to create a load of

@boonier said:

generally you'll find it better to preload all your tables before playback, that is, load all the samples into ram. Then there'll be no glitches when switching tables.

Yes, i already know that.

@boonier said:

There are various ways to do this dynamically. One idea would be to create a load of

you can also do it faster by upsampling.

so you create [block~ 64 1 16], for example, to read the sample into the table 16 times faster than realtime play. ..but you will have to fiddle with some of the other maths in your patch to make the table resize and all that stuff accurate.

@weng said:

Regarding [sfread~], i can't load it, but i don't think it can access tables ( [readsf~] can't )...

Anyway, thanks for your reply....

yes sorry i just re-read you mail, i should have known you're not new to this

embarrased now.....

I now see what you were trying to do

Ooooh, i never got into block. Your trick looks very handy hardoff.
As i understand the block~ help patch, i just have to put this object in the patch (without the need to connect it to anything)... and off course adapt the maths. Thanks for this.

@boonier: don't be. Maybe my post was not very clear. I already knew you misunderstood it . No embarassment in trying to help others...

yeah, don't connect the [block~ ] object to anything...but make sure it is in a different subpatch to your playback and [dac~], otherwise things would get very weird.

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?