[PD] pd clicking with jack/linux

Matt Barber brbrofsvl at gmail.com
Tue Jul 1 17:46:14 CEST 2008


> Date: Tue, 1 Jul 2008 15:46:57 +0200
> From: Frank Barknecht <fbar at footils.org>
> Subject: Re: [PD] pd clicking with jack/linux
> To: pd-list at iem.at
> Message-ID: <20080701134657.GG6144 at 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




More information about the Pd-list mailing list