i thought pd is an "environment"... :/
and now with the "kiosk" mode from iohannes i dont see why you people dont make an installer with your favorite tool... :/ (or pay for someone to do it)
... :/ andre
On Thu, 2006-07-27 at 03:04 +0100, padawan12 wrote:
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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list