Matt Barber wrote: > Incidentally, I think the cpu usage with graphical objects is even > worse on OSX,
A minor quibble which does not invalidate your point: dual-core Macs don't suffer from this, as the graphics process gets its own CPU -- at least this is my empirical observation. I have a great deal going on graphically in my patches, including VU meters, and it doesn't affect the CPU usage as measured by Pd, which seems to report either just the audio process CPU, or perhaps the most-loaded CPU (which is also the audio one in my case) in a dual-core situation. > so if you want your patches to be cross-platform, it's > best to optimize them not to include too many (vu meters are the > worst, but you can improve them based on arguments you give to [env~], > if you're using that to drive them). Depending on what your patch > does, you can often put much of the "engine" of your patch in > subpatches, and then make a "control surface" with sends and receives. > Those can be split up, too: for instance if you have the need for a > "mixer" and a "reverb module," the surfaces for those things can be > put in different subpatches so that they only take up cpu when you > decide to have them open to use them. > That's a good design principle. I just wish there were an easy one-click way to open subpatches while performing. There are some hacks, but nothing standard, as far as I know. > Also, it's a good idea to avoid the sprawling, spider-webby > "max-msp"-like patches you might often see (due, I think in max, to > the bendable and hideable patch cables, so you'll be less tempted in > Pd)-- you can significantly improve the organization of your patch by > using subpatches to group your objects into different "modules." And > modules that you use more than once or twice in a given patch you can > make into abstractions and use more or less like regular objects. > Excellent advice. It's much easier to maintain and optimize patches organized this way as well. Try going back and understanding a "spider web" you made two years ago! Phil Stone pkstonemusic.com _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
