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