Am 26.05.2009 um 15:04 schrieb danomatika:
My point is, I wish pd didn't force me to work it's way but allow me
to work my way. That's the beauty of patching as opposed to vsts,
etc. You have to build form the ground up.
i don't fully understand, why you feel forced to program in a certain
way. actually, pd gives you the freedom to go the route you prefer:
fancy-clicky-boonty or straight and efficient (or anything in between).
i guess, a common approach is to first define the goals and then chose
the programming style/software layout, that is most compliant with the
goals. in your case, the goal is pretty clear: performance. of course,
there are some contraints, when going that route, but _you_ decided,
that your goal is performance.
some things, that come to my mind, when thinking about optimizing
performance (additionally to what has been already said by frank b.):
- turn off the dsp for any unused subpatches/abstractions with
[switch~].
- don't do too many things in zero logical time. the lower the
latency, the more critical is this issue. try to avoid such situations
by serializing the tasks.
- avoid dynamic patching during performance. if you still need it,
first turn off dsp, create the necessary objects, turn dsp on again
(triggered by [t b b b]). don't do dynamic patching, while dsp is on
(this certainly applies to linux, but i guess not to pd on os x, since
only turning the dsp on uses too much time).
- be careful with any object, that might block pd. especially, this
applies to object classes, that send data to the extra-pd-world, such
as netsend, comport, (midiout?), etc.
yo, i guess, most of it doesn't really help optimizing performance in
terms of using less cpu cycles, but is about avoiding audio drop-outs.
however, this is not less an issue on a 500MHz machine.
cheers roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de