[PD] Pd standalone instruments ...

Chuckk Hubbard badmuthahubbard at gmail.com
Wed Jul 26 10:20:31 CEST 2006


On 7/26/06, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:
> hi
>
> Chuckk Hubbard wrote:
> > I am a total noob when it comes to programming in C, but doesn't it
> > follow that if Pd is in C and open-source, it would somehow be
> > possible to extract the part of the program that executes passes and
> > the GUI, and then replace the objects and connections, etc., in a
> > patch with the appropriate C code?  Alternatively, to remove all of
> > the objects *not* used in a particular patch from the source, then
> > hack the startup-option-reading code so that it loads a certain file
> > by default?  I suppose the average user would also like if the PD
> > window were invisible, controlled entirely by menus.  Again, I'm not
> > in a position to say fooey on those people; maybe you all can say it
> > for me.
>
> yes, you could do this.
>
> but think twice: what exactly do you gain? what do you lose?
> what is exactly the reason you don't want to use pd+patch?
> because people don't want to install a "cryptic looking program"? then
> what will your stripped down version be?

The people who might use my patch are other composers interested in
alternate tuning systems.  For the most part they are not computer
people.  "Cryptic-looking" isn't a bust in the slightest, it is how it
comes across, when I send an email to a composer to tell him how to
use my patch, and I have to devote several paragraphs to telling him
how to first get a couple of external libraries loaded and make sure
it selected the right sound device.  Again, I would love to tell him
"tough, learn something about computers if you want to use it," but
that would impede my possible future lessons with him.

>
> to ease the installation (sounds cards,...)? if it was that simple, it
> would already be in pd: even if pd-dev's might be queer, they generally
> don't consider "setting up the sound-card" as _that_ great fun... (i
> guess, but who knows...)

Good point.  Selecting a sound device certainly isn't unique to Pd.

> to read a special configuration-file? hmm, why? what is wrong with the
> registry (well, there are lots of things wrong with it, but we don't
> want to discuss this here, do we?); at least it makes your program a
> little less "cryptic looking" (for those windoze-users who don't use
> win95 any more)

Editing a registry is far beyond the scope of what the people I want
using my patch are willing to learn.  I'm not complaining, this is of
course my problem, but this is the reason I made the suggestion.  If
I'm the only person who thinks something like this would be neat, then
I'll drop it.


> what might be a good idea though, would be a king of "kiosk" mode, where
> the pd-main window is not present and where there are no menus at all
> (so you would have to control pd via messages).

I think menus could stay.  Menus are ubiquitous.  But it seems the
only need for a Pd-window is debugging, or of course analysis and
such; there are times when it's needed, but there are times it isn't.

> apart from that, why don't you distribute your "application" bundled
> with everything: pd, externals, abstractions, patch, startup-script.

Startup-script you say...  I hadn't thought of that.  Far less work
than developing a standalone-application compiler.

>
> > This is just speculation, because I'm nowhere near being up to this
> > task, but wouldn't it also be possible to write a program/external
> > that would perform this conversion automatically?  I imagine it would
> > be a bear to set this up, but it would theoretically only have to be
> > done once to be usable by everyone.  It would drastically change how
> > PD is used.
>
> people have tried to write such converters but to no avail: if you
> really want a C-program to do audio-processing, then write a C-program.
> it will be _way_ more efficient than pd (all something derived from pd).

I'd like to do this, but I imagine it will be a few years before I'm
up to the challenge.
Actually, my initial choice of Pd had little to do with audio
processing, it was mainly because of the drawing instructions for data
structures (my invention was the interface), and I still have yet to
find another music-oriented programming environment that can do this.
Unless you count C...

-Chuckk




More information about the Pd-list mailing list