[PD] Pd standalone instruments ...

[padawan12]

I find this discussion very interesting. As I've said elsewhere
before, this is the single most important missing
feature in Puredata. Not being able to turn the netlist
into code is where the road ends for Pd as a serious software
development tool, where it stops short of being a fully
fledged DSP visual programming language. 






On Wed, 26 Jul 2006 10:46:55 +0200
IOhannes m zmoelnig <zmoelnig at iem.at> wrote:

> hi
> 
> 
> 
> 
> Chuckk Hubbard wrote:
>  >
>  >> 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.
> 
> i was rather suggesting that _you_ should edit the registry (via a small 
> installer) - that is, if you want it to be plug'n'play for your clients.
> 
> i think that if you want people to have an easily usable system, then 
> even editing a cryptic(!) .ini-file is way beyond.
> so you need something more intuitive, like a small setup program (doing 
> autodetection) that will write to a backend (no matter wheter it is an 
> rc-file or the registry)
> 
> 
> 
>  >
>  >
>  >> 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.
> 
> on my side, i (and my non-freaky composers) had never a problem with the 
> additional main-window.
> the menus however, are really there for handling pd (the framework) and 
> NOT your application (patch).
> if there is NO menu, you can build your custom one (either with special 
> widgets like [popup] or with normal [bng]s.
> 
> 
> > 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.
> 
> i totally agree that this if often nor an option.
> 
> > 
> >> 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.
> 
> yes, that was the main point of my email: use startup-scripts.
> 
> 
> mfga.sdr.
> IOhannes
> 
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list