im often more crouchy than that, so no harm done :)
i think the main reason why theres no button that does "standalone" is cause its pretty easy to just "embed" pd with your patch...
but some "hard" things i can think for when realizing that standalone
of course a magic button, make standalone, would be wonderfull. but its maybe just too much work to realize (as its allready doable like i did)
cheers -andre
On Thu, 2006-07-27 at 08:50 +0100, padawan12 wrote:
hmm here's some missing smileys from that :) ;) ;) I read it back and it sounds a bit grouchy... it's not, I'm just genuinely mystified why I cant see what the difficulty is and I want someone to tell me so I can kick myself. :)
On Thu, 27 Jul 2006 08:37:33 +0100 padawan12 padawan12@obiwannabe.co.uk wrote:
On Wed, 26 Jul 2006 18:17:25 +0200 Andre Schmidt andre@osku.de wrote:
i thought pd is an "environment"... :/
Semantics. Nomenclature. I don't see these boundaries myself. That's my view as a software engineer and computer scintist, not as a Pd "user" - in that capacity it's more than adequate as an "environment". I see a "software development environment" without the last mile, a bit like a bridge that goes 9/10 of the way across a river.
Right now it's the BEST audio dsp development environment that exists. That's because of the speed the visual interface allows, I can be about 10 times as productive as before.
It's a wonderful tool, for experimentation, prototyping, teaching, or design of media for use in other applications - but it stops one station short of being complete. The suggestion that one can use it to prototype code, and that if you want code "just write it in C" is simply peverse imho. I'm sure I am not the only one who sees that.
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)
I'm sure "kiosk mode" is a fantastic step forward for those that want to hide the gubbins from non technical users. That's not what I'm talking about. As far as paying someone to do it, I'm in no position to do that. I'm not developing commercial applications. Rather the converse, I'd be interested to know if anyone would like to pay *me* to work on such a project. But I kind of get the feeling rather few people here see the value in a such a step forwards.
It doesn't bother me though. I see a free software tool that does what Pd does and outputs code as an inevitability, sooner or later, it's just the logical thing to do. It's just that I'm rather scratching my head wondering why it doesn't do so already. Perhaps I've forgotten some fundamental reason why exploding the netlist into a code listing might not be trivial, reenterancy maybe, I've not properly studied the source of the server to see how it instantiates and schedules objects. But I don't see why that should disqualify from me from commenting on this obvious step forwards.
Does anybody who deeply understands Puredata have any comment on why this wouldn't be easy?
Or a reference to previous attempts that failed so I might study the problems.
... :/ 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
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list