so if i understand correctly, you are recording successive loops of sound and then playing them back all together? if so, you might consider using VASP or something similar. so instead of having 200 separate arrays, record the new sound into one array, then copy/mix the new sound with the exisitng sound pool array, and then have one tabread playing from that new array. if that makes any sense :)

http://www.parasitaere-kapazitaeten.net/Pd/ext/vasp/

good luck,

-josh

Dan Wilken wrote:

List,

I have a patch, it records an event into an array event(x), when recording is stopped, it crops the array to the recorded sample size and starts a playback [tabplay~ event(x)] -- [bang] [tabplay~] loop.

Then we record the second event, until track 200 or so.

I was expecting to have to use 2 or three machines, but on my G4 350 I'm starting to have hickups around 35 tracks in. It performs up to 90 tracks, my current beta, but not well.

How can I improve things. I've used tabplay~ because it's supposed to be cheaper than tabplay4~, correct?

Can (and should) both my recording and playback be down-sampled from default 44.1?

Is there any way to change the 32 bit floating point in PD to 16 bit? Would this help?

I used renice to bump pd up to level -19 and Wish to level -17, I think that helped a bit. Does tabplay have an invisible trigger?

I haven't tried no gui yet, will do so next. Will it help?

Any ways to allocate more memory? Where does PD store my arrays? RAM or Hard Drive. The patch currently does not do any writing to or reading from disk, though I imagine it may have to, especially for crash recovery and/or network load sharing.

Tips for both Linux and OS X Welcome.

Is there a good "optimize system for PD" howto out there?

Is Panther working better with 0.37 than Jaguar? I'm running Jaguar, though happy to switch if it's encouraged.

A little off topic, but At random points, I get 90 "~error: tabplay~: event0: no such array"s

The arrays don't exist, at least not called event0. The arrays are created at setup time to reduce load during performance, but the [tabplay~]s are renamed only when triggered. There is nothing that I can see that's triggering these [tabplay~]s, they're all hidden behind a [route] and by definition only fire off one at a time, and named at that point. Does tabplay have an invisible trigger? This must be costing me CPU time.

This happens whenever I close a subpatch, every time I start and stop the tabwrite~.

Thanks in advance,

Dan

---

PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list

Hallo, Dan Wilken hat gesagt: // Dan Wilken wrote:

I have a patch, it records an event into an array event(x), when recording is stopped, it crops the array to the recorded sample size and starts a playback [tabplay~ event(x)] -- [bang] [tabplay~] loop.

Then we record the second event, until track 200 or so.

I was expecting to have to use 2 or three machines, but on my G4 350 I'm starting to have hickups around 35 tracks in. It performs up to 90 tracks, my current beta, but not well. [...] Any ways to allocate more memory? Where does PD store my arrays? RAM or Hard Drive. The patch currently does not do any writing to or reading from disk, though I imagine it may have to, especially for crash recovery and/or network load sharing.

Maybe you're slowly running out of memory. Arrays and tables are created in memory. You could record to files with writesf~ to consume less memory, and read and play then with readsf~

ciao

Frank Barknecht _ ______footils.org__