Im using tabread4~to read audio files (which are loops) from tables. I discovered that pure data has silent dips when I upload a new file whilst another file is playing.

To avoid this, it was suggested to me that I load all the files I need and then use set message to "point" tab read to different tables.

I haven't trialled this yet but I wanted same extra thoughts as to how effective this may be? The reason Im hesitating is because I have to achieve an hour long live set using the raspberry pi which has limited ram. When I load all those files to tables am I loading them to RAM? Or can I load them and successfully play a few back at a time instead ?

If you can find points in the set where you can handle dips for loading, that might be an opportunity to compose for.

You can also mess around with the nice value of pd, which might reduce audio dips.

Most modern rpis have 1 gig of ram, which you could load over 80min of cd quality stereo audio, and still have a couple of megs left over for OS and pd etc. How much rendered audio are you playing?

altogether so far an hour but my sets are growing. Also Im discovering that I may want to select a track spontaneously so I need to be able to load files whilst playing audio.

What do you mean when you say play around with the nice value of pd?

-also what is the reason for the implication on audio playback while a file is loaded, why is that happening? Can it be improved upon?

many thanks,

j

@Fauveboy Are you just using one table...... do you just have one [prac1] running?..... or many?
Zip and upload your patch please (all of it except the audio), as we have no idea why you are having problems with it.
Do you have two [prac1] running and you flip /flop between them?
Do you have many (2+).........?
David.

I use the patch like so:

I've linked prac.pd which i use one of. You will see in prac.pd two instances of sample.pd.(Im aiming to use more).

prac.pd.zip

sampler.pd.zip

@Fauveboy A very small change made here....... one_bit.zip
It limits the ram allocated when first opening.... so will load much quicker, and any [sampler] you add will use no (very little) ram until you open an audio file.
If I drag the window [prac] about on my desktop the audio stops, and takes a while to recover.
It is most likely that the drawing of the waveform in the visible array is what causes the dropout, and you might find that hiding it (moving it out of the GOP) will stop the problem.
David.

thank you, how can I hid the array table GOP and still use a table?

@Fauveboy I think just moving it so that it is not showing on the screen like this......one_bit.zip ....... should do it...
David.

after moving the table out of the on graph canvas an odd thing happens when I load a sample the table appears in the parent (prac.pd) relative to where its positioned in sampler.pd ? why is this happening won't this end up slowing down the performance again?

I think you need to replace the graph table with [table $1-table 100] in sampler.pd

@Fauveboy So it does...... @Balwyn is correct...... or you can dump it into a sub-patch like this........
one_bit.zip
Both should work.
By the way....... does it solve your problem?
David.

@Fauveboy In linux OSes, there is a nice value assigned to every running process, between 19 and -20. When processes are competing for resources, the nicer processes are left hanging while the lower value nice processes take precedence. You can dictate the niceness like so:

$ nice -2 pd
From the bash prompt.

Depending on from where to where the data is being read/written, the system may experience bottlenecks. The rpi3 has LPDDR2 SDRAM which has a throughput which might be as low as 20Mbps. That basically translates to a 20MB file hoarding all RAM IO for 1/8th of a second.
.

Thanks for all the replys...This putting it into a subpatch works well!