Date: Tue, 1 Jul 2008 15:46:57 +0200 From: Frank Barknecht fbar@footils.org Subject: Re: [PD] pd clicking with jack/linux To: pd-list@iem.at Message-ID: 20080701134657.GG6144@fliwatut.scifi Content-Type: text/plain; charset=iso-8859-15
Hallo, Atte Andr? Jensen hat gesagt: // Atte Andr? Jensen wrote:
Basically I think my problems came from using array (and not table) to store a sample. Pd gave DIO errors when switching to the window containing the patch. Is this normal, and is there a way to avoid it, for instance running the gui in a separate thread?
It already runs even in a separate process from the audio engine. But both are tied together very closely and communicate a lot with each other, which leads to dropouts on gfx-intensive operations e.g. moving a lot ob objects or displaying and updating large graphical arrays. Use [table] everyhwere, you don't need to see the data, and avoid graphical objects for debugging in performance situations, only use them to input data. I.e. this is bad:
[r something] | [bng] | [s something-else]
this is better:
[r something] |
| [bng] | [s something-else]because you can easily make this out of it:
[r something] | | | [s something-else]
and if you want to be fancy, use something like this:
[r DEBUG]| | [spigot] | [bng]
to make debugging switchable on the fly.
Ciao
Frank Barknecht _ ______footils.org__
Thanks, this is all great advice.
Incidentally, I think the cpu usage with graphical objects is even worse on OSX, 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.
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.
Thanks,
Matt
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
On Tue, Jul 1, 2008 at 12:15 PM, Phil Stone pkstone@ucdavis.edu wrote:
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.
This may be true, but the graphics are still more expensive than other operating systems. At any rate in OSX you can look in the output of "top" from a terminal; you'll see two processes, and they do seem to be separately allocated as you suggest.
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.
If you have a subpatch, say [pd GUI-mixer], you can send it a "vis 1" message:
[vis 1 ( | [send pd-GUI-mixer]
"vis 0" closes.
You can put all of this in this kind of message:
; pd-GUI-mixer vis 1
You can then put a graphical bng or tgl on the main surface and route it to that message somewhere in a subpatch (I often put the GUI control stuff in a separate module).
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!
Exactly. It also helps you organize hierarchically from global design down to implementation, which is very useful for the optimization as you suggest. It's not always as useful if your design isn't hierarchical, but it still helps remove things from the screen, making things easier to follow.
Matt
Matt Barber wrote:
On Tue, Jul 1, 2008 at 12:15 PM, Phil Stone pkstone@ucdavis.edu wrote:
Matt Barber wrote:
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.
If you have a subpatch, say [pd GUI-mixer], you can send it a "vis 1" message:
[vis 1 ( | [send pd-GUI-mixer]
"vis 0" closes.
You can put all of this in this kind of message:
; pd-GUI-mixer vis 1
You can then put a graphical bng or tgl on the main surface and route it to that message somewhere in a subpatch (I often put the GUI control stuff in a separate module).
Thank you for the excellent tip, Matt. I shall try this out.
Phil
Hallo, Matt Barber hat gesagt: // Matt Barber wrote:
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.
Note that GUI objects even in subpatches can lead to more CPU use. At least I once managed to make a patch perform much better by removing a lot of [bng] objects hidden in abstractions or subpatches. The example is somehwere in the list archive, maybe I can find it again.
Ciao
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
Matt Barber -
Phil Stone