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