Hi list,
I was wondering if there is any way to export a pd instrument so it can operate in a system without pd ot self. Is there any way to make an instrument standalone?
Regard,
Terumi
ΓñçóéìïðïéΓ₯ΓΓ΄Γ₯ Yahoo! ΓÑñΓ₯Γ¨ΓΓͺÑôΓ₯ ôÑ Γ₯Γï÷ëçôéΓͺà ìçΓΓ½ ìÑôÑ (spam); ΓΓ― Yahoo! Mail ÀéÑèΓΓ΄Γ₯Γ© ôçà ΓͺÑëýôΓ₯Γ±Γ§ ÀáΓÑôà ðñïóôÑóΓΓ‘ ΓͺÑôà ôùà Γ₯Γï÷ëçôéΓͺþà ìçΓáìΓôùà http://login.yahoo.com/config/mail?.intl=gr
Hallo, Tas Pas hat gesagt: // Tas Pas wrote:
I was wondering if there is any way to export a pd instrument so it can operate in a system without pd ot self.
There is no Pd without Pd. But Pd is free, so you can bundle Pd with your patch.
Frank Barknecht _ ______footils.org_ __goto10.org__
is it allowed that pd gets distributed freely? wasn't it part of the
license that it should be distributed only by miller? actually I don't
know about pd-ext, can it be also freely distributed?
Am 21.07.2006, 21:16 Uhr, schrieb Frank Barknecht fbar@footils.org:
Hallo, Tas Pas hat gesagt: // Tas Pas wrote:
I was wondering if there is any way to export a pd instrument so it can
operate in a system without pd ot self.There is no Pd without Pd. But Pd is free, so you can bundle Pd with your patch.
Ciao
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
is it allowed that pd gets distributed freely? wasn't it part of the
license that it should be distributed only by miller?
No, that's not true, everyone basically can do everything with Pd, as long as the existing copyright text (pd/LICENSE.txt) is included.
actually I don't know about pd-ext, can it be also freely distributed?
Some parts of pd-extended are covered by different licenses. As pd-extended also includes externals and stuff, that is licensed under GPL, the whole package is distributed according to the GPL. This still allows you to distribute pd-extended, and you are encouraged to do so, however the terms are slightly different from distributing Pd core only because of the GPL.
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sat, 22 Jul 2006, João Miguel Pais wrote:
is it allowed that pd gets distributed freely? wasn't it part of the license that it should be distributed only by miller?
i beg your pardon???
that wouldn't be Free Software.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On 7/21/06, Frank Barknecht fbar@footils.org wrote:
Hallo, Tas Pas hat gesagt: // Tas Pas wrote:
I was wondering if there is any way to export a pd instrument so it can operate in a system without pd ot self.
There is no Pd without Pd. But Pd is free, so you can bundle Pd with your patch.
Alas, most of the people I work with aren't willing to install this cryptic-looking program and go through figuring out how to set up their soundcards and set up external libraries... I wish I could just say fooey on them, but I probably shouldn't.
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. 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. Would doing this violate the copyright, if the copyright messages were all left intact, and maybe supplemented? (just asking- if so nevermind!)
-Chuckk
hi
Chuckk Hubbard wrote:
On 7/21/06, Frank Barknecht fbar@footils.org wrote:
Hallo, Tas Pas hat gesagt: // Tas Pas wrote:
I was wondering if there is any way to export a pd instrument so it
can operate in a system without pd ot self.
There is no Pd without Pd. But Pd is free, so you can bundle Pd with your patch.
Alas, most of the people I work with aren't willing to install this cryptic-looking program and go through figuring out how to set up their soundcards and set up external libraries... I wish I could just say fooey on them, but I probably shouldn't.
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?
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...)
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)
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).
apart from that, why don't you distribute your "application" bundled with everything: pd, externals, abstractions, patch, startup-script.
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).
Would doing this violate the copyright, if the copyright messages were all left intact, and maybe supplemented? (just asking- if so nevermind!)
why should it violate the copyright? which part of it?
mfa.dsr. IOhannes
-Chuckk
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 7/26/06, IOhannes m zmoelnig zmoelnig@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
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
IOhannes m zmoelnig wrote:
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.
i have committed a patch to the current CVS-pd which implements such a kiosk mode as i like it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1529010&gro...
it does: disable the main window disable menus in the patch-windows disable keyboard shortcuts (like Ctrl-q or Ctrl-s) write to stdout
to enable this feature, start pd with "-kiosk" and don't forget to tell pd which file it should load (as you have no more chance to open it without any window)
caveats:
Ctrl-C on the shell)
most changes are really in u_main.tk (aka pd.tk); the only changes in the 2 .c-files are there for parsing the new flag and enabling kiosk-mode. people who want to try it out without having to recompile pd, can edit line 35 of u_main.tk, to set "pd_kiosk" to 1. (and copy the new u_main.tk to bin/pd.tk)
mfg.adsr. IOhannes
IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
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.
i have committed a patch to the current CVS-pd which implements such a kiosk mode as i like it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1529010&gro...
it does: disable the main window disable menus in the patch-windows disable keyboard shortcuts (like Ctrl-q or Ctrl-s) write to stdout
to enable this feature, start pd with "-kiosk" and don't forget to tell pd which file it should load (as you have no more chance to open it without any window)
caveats:
- no way to open another patch (no Ctrl-o)
- when the last window is closed, pd keeps on running (kill it with
Ctrl-C on the shell)
most changes are really in u_main.tk (aka pd.tk); the only changes in the 2 .c-files are there for parsing the new flag and enabling kiosk-mode. people who want to try it out without having to recompile pd, can edit line 35 of u_main.tk, to set "pd_kiosk" to 1. (and copy the new u_main.tk to bin/pd.tk)
mfg.adsr. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
ola, is it possible only disabling menus in the patch-window? but the shortcuts would work and the menu in pd-main would exist. because it would economize my screen-place.. which code should i change in pd.tk?
thanx
moritZ
IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
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.
i have committed a patch to the current CVS-pd which implements such a kiosk mode as i like it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1529010&gro...
it does: disable the main window disable menus in the patch-windows disable keyboard shortcuts (like Ctrl-q or Ctrl-s) write to stdout
to enable this feature, start pd with "-kiosk" and don't forget to tell pd which file it should load (as you have no more chance to open it without any window)
caveats:
- no way to open another patch (no Ctrl-o)
- when the last window is closed, pd keeps on running (kill it with
Ctrl-C on the shell)
Maybe send a [; pd quit( message from a patch?
most changes are really in u_main.tk (aka pd.tk); the only changes in the 2 .c-files are there for parsing the new flag and enabling kiosk-mode. people who want to try it out without having to recompile pd, can edit line 35 of u_main.tk, to set "pd_kiosk" to 1. (and copy the new u_main.tk to bin/pd.tk)
I haven't tried it yet, just looking at the patch to see how it works. I notice you use wm withdraw on the root window.
"+#jmz: set kiosk mode (no pd-main window) +proc pdtk_kiosk {kiosk} {
set pd_kiosk 1
wm withdraw .
+} +#/jmz "
But in this page at tcl.tk: http://wiki.tcl.tk/3175 there is a warning not to do that: "
I wouldn't advise you to use "wm withdraw ." on the "." window. Under some window managers (especially under unix...) this will prevent dialogs that have as parent the "." (like error messages) from showing up and block your app. Better to use something like:
wm geometry . 1x1+0+0 wm overrideredirect . 1 wm transient .
You can even send it out of the visible part of the screen, like
wm geometry . 1x1+3000+3000
But in any case, do not withdraw it :-)
" Otherwise it looks like a great idea, will it do fullscreen as well?
Martin
mfg.adsr. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Martin Peach wrote:
caveats:
- no way to open another patch (no Ctrl-o)
- when the last window is closed, pd keeps on running (kill it with
Ctrl-C on the shell)
Maybe send a [; pd quit( message from a patch?
now i only wander how you do that if the last patch is closed and you cannot create/open a new one...
most changes are really in u_main.tk (aka pd.tk); the only changes in the 2 .c-files are there for parsing the new flag and enabling kiosk-mode. people who want to try it out without having to recompile pd, can edit line 35 of u_main.tk, to set "pd_kiosk" to 1. (and copy the new u_main.tk to bin/pd.tk)
I haven't tried it yet, just looking at the patch to see how it works. I notice you use wm withdraw on the root window.
"+#jmz: set kiosk mode (no pd-main window) +proc pdtk_kiosk {kiosk} {
- global pd_kiosk
- set pd_kiosk 0
- if {$kiosk == 1} {
set pd_kiosk 1
wm withdraw .
- }
+} +#/jmz "
But in this page at tcl.tk: http://wiki.tcl.tk/3175
i am no tcl/tk programmer so i might have done some harm...
there is a warning not to do that: "
I wouldn't advise you to use "wm withdraw ." on the "." window. Under some window managers (especially under unix...) this will prevent dialogs that have as parent the "." (like error messages) from showing up and block your app. Better to use something like:
wm geometry . 1x1+0+0 wm overrideredirect . 1 wm transient .
You can even send it out of the visible part of the screen, like
wm geometry . 1x1+3000+3000
But in any case, do not withdraw it :-)
"
hmm, currently i cannot think of any "error mesage dialog" that could pop-up in the kiosk mode...probably the [opendialog] might be a problem.
it might be a good idea to add your remark to the patch-tracker in case somebody wants to apply it, they are warned.
Otherwise it looks like a great idea, will it do fullscreen as well?
i haven't thought so. i would use the window manager to do "kind of" fullscreen (e.g. use evilwm or no wm at all) if i needed this.
mfg.gsf.d IOhannes
Hi list,
One of Miller's student, Josef Sarlo, has made a pd to vst via python
solution, that I have tryed and know works on windows. I think there is an exe flavour available for PC, too. You could probably track it down if you search the archive.
For other platforms you maybe able to run as a vst through jack to
connect pd with your midi sequencer.
B~ www.cypod.co.nr
On Wed, Jul 26, 2006 at 04:12:36PM +0200, IOhannes m zmoelnig wrote:
- no way to open another patch (no Ctrl-o)
Yes there is, with internal messages:
[; pd open nameofmypatch.pd /path/to/my/thing/ ;(
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
Chris McCormick wrote:
On Wed, Jul 26, 2006 at 04:12:36PM +0200, IOhannes m zmoelnig wrote:
- no way to open another patch (no Ctrl-o)
Yes there is, with internal messages:
[; pd open nameofmypatch.pd /path/to/my/thing/ ;(
it's even simpler: [/path/to/my/thing]
but in both cases you have to get into edit-mode first, which you cannot do via shortcuts or menus. (but of course you can do it via a message to your canvas)
mfga.sdr. IOhannes
IOhannes m zmoelnig ha scritto:
i have committed a patch to the current CVS-pd which implements such a kiosk mode as i like it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1529010&gro...
Hi, I had tried it now (on linux): great !
I like wery much this kind of features :)
Lazzaro
IOhannes m zmoelnig ha scritto:
- when the last window is closed, pd keeps on running (kill it with
Ctrl-C on the shell)
Hi, I have find a workaround for this problem (on linux), I have add one line in pd.tk (near the line 860/864):
...... if {$pd_kiosk == 1} { toplevel $name ##Laz bind $name <Destroy> {exec killall pd-watchdog pd-gui pd &} ##Laz } else { toplevel $name -menu $name.m } .....
It is not very elegant but it work in my box :) Hope help -- Lazzaro
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
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
ok,
i made a proof of concept (or what ever)
download this: http://osku.de/pd/foo/pokesdown.tar.gz extract it and run the pokesdown.sh in it, ready. you should now hear the coolest pd tune ever :)
should look something like this: http://osku.de/pd/foo/pokesdown.png
yeah, works propably only on ubuntu dapper... -andre
ps. remember the kiosk bug, pd is still running after you close the window!
On Wed, 2006-07-26 at 18:17 +0200, Andre Schmidt wrote:
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I got a missing libtk8.5.so, but I see what you've done I think. That's very cool.
On Wed, 26 Jul 2006 20 Andre Schmidt andre@osku.de wrote:
ok,
i made a proof of concept (or what ever)
download this: http://osku.de/pd/foo/pokesdown.tar.gz extract it and run the pokesdown.sh in it, ready. you should now hear the coolest pd tune ever :)
should look something like this: http://osku.de/pd/foo/pokesdown.png
yeah, works propably only on ubuntu dapper... -andre
ps. remember the kiosk bug, pd is still running after you close the window!
On Wed, 2006-07-26 at 18:17 +0200, Andre Schmidt wrote:
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
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
oh, sorry, my mistake i was playing with tk8.5 (xft support) and actually fogot i had 8.5 :/
-andre ps. if theres need i recompile with tcl/tk8.4
On Thu, 2006-07-27 at 08:47 +0100, padawan12 wrote:
I got a missing libtk8.5.so, but I see what you've done I think. That's very cool.
On Wed, 26 Jul 2006 20 Andre Schmidt andre@osku.de wrote:
ok,
i made a proof of concept (or what ever)
download this: http://osku.de/pd/foo/pokesdown.tar.gz extract it and run the pokesdown.sh in it, ready. you should now hear the coolest pd tune ever :)
should look something like this: http://osku.de/pd/foo/pokesdown.png
yeah, works propably only on ubuntu dapper... -andre
ps. remember the kiosk bug, pd is still running after you close the window!
On Wed, 2006-07-26 at 18:17 +0200, Andre Schmidt wrote:
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
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
ok,
recompiled it, now it should work atleast on dapper made it minimal as possible (for pokesdown.pd)
pokesdown/ pokesdown/pokesdown.sh pokesdown/bin/ pokesdown/bin/pd pokesdown/bin/pd-gui pokesdown/bin/pd.tk pokesdown/bin/pokesdown.pd
and i even made a "run" package with http://www.megastep.org/makeself/ so now you can:
(you may need to wget it, as my server shows it as text in brauser)
(or double click after "chomd +x pokesdown.run". but remember, its still running after closing the window - "killall pd")
gotta go sleep andre
ps. it took so long as i was lazy and installed tcl/tk8.5 with make install and then didnt knew how to get back to tcl/tk8.4 :/ (so i installed another dapper partition :)
pss. and yes, the auto scrollbar patch has errors, maybe cause i made it with tcl/tk8.5, gotta check that someday...
pssszzZZ. and for the next "kiosk" feature: only show gem/pdp window :)
On Wed, 2006-07-26 at 20:58 +0200, Andre Schmidt wrote:
oh, sorry, my mistake i was playing with tk8.5 (xft support) and actually fogot i had 8.5 :/
-andre ps. if theres need i recompile with tcl/tk8.4
On Thu, 2006-07-27 at 08:47 +0100, padawan12 wrote:
I got a missing libtk8.5.so, but I see what you've done I think. That's very cool.
On Wed, 26 Jul 2006 20 Andre Schmidt andre@osku.de wrote:
ok,
i made a proof of concept (or what ever)
download this: http://osku.de/pd/foo/pokesdown.tar.gz extract it and run the pokesdown.sh in it, ready. you should now hear the coolest pd tune ever :)
should look something like this: http://osku.de/pd/foo/pokesdown.png
yeah, works propably only on ubuntu dapper... -andre
ps. remember the kiosk bug, pd is still running after you close the window!
On Wed, 2006-07-26 at 18:17 +0200, Andre Schmidt wrote:
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
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
Hey Andre, Almost, but not quite for me yet....
pearly:~$ chmod 555 pokesdown.run pearly:~$ sh pokesdown.run Verifying archive integrity... All good. Uncompressing pokesdown by andy farnell....... priority 98 scheduling enabled. sh: line 1: ./bin/pd-watchdog: No such file or directory priority 96 scheduling enabled. unknown audio API specified unknown API .... audio I/O stuck... closing audio sys_close_audio: unknown API 5 pd: watchdog process died
pearly:~$ uname -a Linux pearly 2.6.8-2-386 #1 Thu May 19 17:40:50 JST 2005 i686 GNU/Linux
pearly:~$ pd -version Pd version 0.39-2extended-test4 compiled 10:42:39 May 25 2006
pearly:~$ which pd /usr/local/bin/pd _______________________________________
Do you think it's cos I'm installed to /usr/local ?
I'm really excited to see this work. But enjoy your zzzZZZzz after your hackathon.
On Thu, 27 Jul 2006 00:27:20 +0200 Andre Schmidt andre@osku.de wrote:
ok,
recompiled it, now it should work atleast on dapper made it minimal as possible (for pokesdown.pd)
pokesdown/ pokesdown/pokesdown.sh pokesdown/bin/ pokesdown/bin/pd pokesdown/bin/pd-gui pokesdown/bin/pd.tk pokesdown/bin/pokesdown.pd
and i even made a "run" package with http://www.megastep.org/makeself/ so now you can:
- download: http://osku.de/pd/foo/pokesdown.run
(you may need to wget it, as my server shows it as text in brauser)
- run it with "sh pokesdown.run"
(or double click after "chomd +x pokesdown.run". but remember, its still running after closing the window - "killall pd")
- enjoy
gotta go sleep andre
ps. it took so long as i was lazy and installed tcl/tk8.5 with make install and then didnt knew how to get back to tcl/tk8.4 :/ (so i installed another dapper partition :)
pss. and yes, the auto scrollbar patch has errors, maybe cause i made it with tcl/tk8.5, gotta check that someday...
pssszzZZ. and for the next "kiosk" feature: only show gem/pdp window :)
On Wed, 2006-07-26 at 20:58 +0200, Andre Schmidt wrote:
oh, sorry, my mistake i was playing with tk8.5 (xft support) and actually fogot i had 8.5 :/
-andre ps. if theres need i recompile with tcl/tk8.4
On Thu, 2006-07-27 at 08:47 +0100, padawan12 wrote:
I got a missing libtk8.5.so, but I see what you've done I think. That's very cool.
On Wed, 26 Jul 2006 20 Andre Schmidt andre@osku.de wrote:
ok,
i made a proof of concept (or what ever)
download this: http://osku.de/pd/foo/pokesdown.tar.gz extract it and run the pokesdown.sh in it, ready. you should now hear the coolest pd tune ever :)
should look something like this: http://osku.de/pd/foo/pokesdown.png
yeah, works propably only on ubuntu dapper... -andre
ps. remember the kiosk bug, pd is still running after you close the window!
On Wed, 2006-07-26 at 18:17 +0200, Andre Schmidt wrote:
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
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
damn,
but odd, it worked on the fresh installed dapper without the pd-watchdog, and it didnt even have pd installed system wide...
i uploaded the compiled pd-watchdog from 0.40 to http://osku.de/pd/foo/pd-watchdog add it to the pokesdown/bin dir and try again (for makeself.sh, use the example on their site)
could someone who knows more than i, say what are the minimum files needed for this kind of pd usage ?
off to work -andre
ps. i (oskude) propably hang at #dataflow the whole work day as i got a boring website project to do :/
On Thu, 2006-07-27 at 14:22 +0100, padawan12 wrote:
Hey Andre, Almost, but not quite for me yet....
pearly:~$ chmod 555 pokesdown.run pearly:~$ sh pokesdown.run Verifying archive integrity... All good. Uncompressing pokesdown by andy farnell....... priority 98 scheduling enabled. sh: line 1: ./bin/pd-watchdog: No such file or directory priority 96 scheduling enabled. unknown audio API specified unknown API .... audio I/O stuck... closing audio sys_close_audio: unknown API 5 pd: watchdog process died
pearly:~$ uname -a Linux pearly 2.6.8-2-386 #1 Thu May 19 17:40:50 JST 2005 i686 GNU/Linux
pearly:~$ pd -version Pd version 0.39-2extended-test4 compiled 10:42:39 May 25 2006
pearly:~$ which pd /usr/local/bin/pd _______________________________________
Do you think it's cos I'm installed to /usr/local ?
I'm really excited to see this work. But enjoy your zzzZZZzz after your hackathon.
On Thu, 27 Jul 2006 00:27:20 +0200 Andre Schmidt andre@osku.de wrote:
ok,
recompiled it, now it should work atleast on dapper made it minimal as possible (for pokesdown.pd)
pokesdown/ pokesdown/pokesdown.sh pokesdown/bin/ pokesdown/bin/pd pokesdown/bin/pd-gui pokesdown/bin/pd.tk pokesdown/bin/pokesdown.pd
and i even made a "run" package with http://www.megastep.org/makeself/ so now you can:
- download: http://osku.de/pd/foo/pokesdown.run
(you may need to wget it, as my server shows it as text in brauser)
- run it with "sh pokesdown.run"
(or double click after "chomd +x pokesdown.run". but remember, its still running after closing the window - "killall pd")
- enjoy
gotta go sleep andre
ps. it took so long as i was lazy and installed tcl/tk8.5 with make install and then didnt knew how to get back to tcl/tk8.4 :/ (so i installed another dapper partition :)
pss. and yes, the auto scrollbar patch has errors, maybe cause i made it with tcl/tk8.5, gotta check that someday...
pssszzZZ. and for the next "kiosk" feature: only show gem/pdp window :)
On Wed, 2006-07-26 at 20:58 +0200, Andre Schmidt wrote:
oh, sorry, my mistake i was playing with tk8.5 (xft support) and actually fogot i had 8.5 :/
-andre ps. if theres need i recompile with tcl/tk8.4
On Thu, 2006-07-27 at 08:47 +0100, padawan12 wrote:
I got a missing libtk8.5.so, but I see what you've done I think. That's very cool.
On Wed, 26 Jul 2006 20 Andre Schmidt andre@osku.de wrote:
ok,
i made a proof of concept (or what ever)
download this: http://osku.de/pd/foo/pokesdown.tar.gz extract it and run the pokesdown.sh in it, ready. you should now hear the coolest pd tune ever :)
should look something like this: http://osku.de/pd/foo/pokesdown.png
yeah, works propably only on ubuntu dapper... -andre
ps. remember the kiosk bug, pd is still running after you close the window!
On Wed, 2006-07-26 at 18:17 +0200, Andre Schmidt wrote:
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
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
padawan12 wrote:
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,
Well possibly the fact that most pd patches are not strictly procedural, a list of instructions that is run through once. Messages can arrive at any time to modify what is going on... PD is already written in C and is basically a scheduler that calls functions at the appropriate times based on the messages the functions are emitting. It seems to me you can't get any further than that in C. Sure you can manually write any particular patch more efficiently as a standalone program but I doubt there is a general way to do that since there is no way to predict every possible state of every possible patch, hence no way to guarantee that a program is really the same as the original patch. IMHO, Martin
On 7/26/06, Martin Peach martin.peach@sympatico.ca wrote:
padawan12 wrote:
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,
Well possibly the fact that most pd patches are not strictly procedural, a list of instructions that is run through once. Messages can arrive at any time to modify what is going on... PD is already written in C and is basically a scheduler that calls functions at the appropriate times based on the messages the functions are emitting. It seems to me you can't get any further than that in C. Sure you can manually write any particular patch more efficiently as a standalone program but I doubt there is a general way to do that since there is no way to predict every possible state of every possible patch, hence no way to guarantee that a program is really the same as the original patch. IMHO, Martin
Does Pd actually replace the objects in a patch with their machine code? It seems like, if the behavior of the program and the behavior of any one object are derived from C code, you could just plug the necessary pieces of C code together in the same relationships as the objects in the patch. I don't think the extra step of then compiling the C code would be much of a PITA for anyone using Pd. If you really wanted a small program, you could even take out parts of objects you don't need, if that doesn't violate anyone's license. As in, if you have no [/~] objects, take that section out of the signal math file. Kind of the way Csound works. Maybe it wouldn't be much benefit for existing Pd users, but I bet it would draw new users in. Then again, I realize it wasn't part of the original vision behind Pd; but that needn't stop it.
Chuckk Hubbard wrote:
On 7/26/06, Martin Peach martin.peach@sympatico.ca wrote:
padawan12 wrote:
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,
Well possibly the fact that most pd patches are not strictly procedural, a list of instructions that is run through once. Messages can arrive at any time to modify what is going on... PD is already written in C and is basically a scheduler that calls functions at the appropriate times based on the messages the functions are emitting. It seems to me you can't get any further than that in C. Sure you can manually write any particular patch more efficiently as a standalone program but I doubt there is a general way to do that since there is no way to predict every possible state of every possible patch, hence no way to guarantee that a program is really the same as the original patch. IMHO, Martin
Does Pd actually replace the objects in a patch with their machine code?
Yes. A message arriving at an inlet results in a function call to machine code.
It seems like, if the behavior of the program and the behavior of any one object are derived from C code, you could just plug the necessary pieces of C code together in the same relationships as the objects in the patch. I don't think the extra step of then compiling the C code would be much of a PITA for anyone using Pd. If you really wanted a small program, you could even take out parts of objects you don't need, if that doesn't violate anyone's license. As in, if you have no [/~] objects, take that section out of the signal math file. Kind of the way Csound works.
That would take some kind of stripping program that could determine which parts of the ensemble were actually used in a patch and then remove the unused code, putting it back together while adjusting all the function addresses to fit the new space. Some linkers can do this when incorporating libraries into code, so a program that was statically linked against pd.lib could remove the parts of pd.lib that weren't used. Leaving aside the TCL/TK part (i.e. you won't have anything to look at or take user input), it should be feasible in many cases, but as I said, for any given patch, there is no way to guarantee that some code will never be called. (Imagine for example someone sending arbitrary messages to a netreceive object.) To me it looks easier to script pd to operate the patch as is, or remove some functionality from pd (as with kiosk mode) so an untrained user can't wreck the patch. Martin
Maybe it wouldn't be much benefit for existing Pd users, but I bet it would draw new users in. Then again, I realize it wasn't part of the original vision behind Pd; but that needn't stop it.
Hi all,
Sorry for arriving so late in this thread, but no one mentioned this...
Martin Peach wrote:
padawan12 wrote:
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,
Well possibly the fact that most pd patches are not strictly procedural, a list of instructions that is run through once. Messages can arrive at any time to modify what is going on...
...and Pd internal messages can change the program while it is running - self-modifying code would be a "fundamental reason why [that] might not be trivial".
On Thu, Jul 27, 2006 at 08:37:33AM +0100, padawan12 wrote:
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
Wouldn't it be better to make it easier to bind yr code to a library version of Pd so that you could embed Pd and patches within another application? This would certainly make it easier to use Pd in [for example] game development. Exploding a netlist into code seems like a very roundabout way to acheive the same thing.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
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
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
I think it makes the most sense to view Pd like Java. Java apps
still need to have all the Java libs installed. If we make Pd a
platform like Java, then the user can just install Pd once, then a
patch is a double-clickable application. A double-clickable jar-
style format would be good to do so that you can include more than
one file.
.hc
On Jul 26, 2006, at 10:04 PM, 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
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
A double-clickable jar-style format would be good to do so that you can include more than one file.
I second that! Distribution of patches which include other patches, specific abstractions and externals would be peasy and clean with some kind of packaged format like that. Then even if these abstractions etc were already installed on the user's machine the patch would look for anything required within this packaged file first... no longer any [scale] confusions or namespace issues! Oh, but then externals are platform dependent, so.... hmm patches become dependent too. Right... maybe not the optimal solution then?
Matt
-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org -=-=-=-=-=-=-=-=-=-=-=-
On 7/31/06, matthew jones mj@isvr.soton.ac.uk wrote:
A double-clickable jar-style format would be good to do so that you can include more than one file.
I second that! Distribution of patches which include other patches, specific abstractions and externals would be peasy and clean with some kind of packaged format like that. Then even if these abstractions etc were already installed on the user's machine the patch would look for anything required within this packaged file first... no longer any [scale] confusions or namespace issues! Oh, but then externals are platform dependent, so.... hmm patches become dependent too. Right... maybe not the optimal solution then?
Very good idea !! It could be a ZIP file with a XML file, patches and objects in it. The XML file describes the role of each file in the bundles. Therefore, one could wrap externals for, let say, Windose, Mack and Linux, and write the ".pdrc" in the xml file. If the externals are missing for the current OS, well, it doesn't work and that's it ! An example of such a XML file in a TAR.GZ package is the package system of PEAR, the PHP classes repository. See http://www.php-editors.com/pear_manual/developers.packagedef.html
Maybe that's overkill though, but it would kind of compete with Max's VSTs. :-P
Cheers,
a
Matt
-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org -=-=-=-=-=-=-=-=-=-=-=-
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, matthew jones hat gesagt: // matthew jones wrote:
A double-clickable jar-style format would be good to do so that you can include more than one file.
I second that! Distribution of patches which include other patches, specific abstractions and externals would be peasy and clean with some kind of packaged format like that.
It could be clean without a packaged format as well, it just involves a bit of organization. One could for example put all used abstractions and externals in subdirectories. A possible layout could look like this:
README.txt MYAPP.pd .abs/ """ directory for abstractions in use """ .abs/abstraction1.pd .abs/abstraction2.pd .abs/abstraction3.pd .ext/ """ dir for uncommon externals """ .ext/external.pd_linux .ext/external.dll .ext/external.pd_darwin
Then just tarzip it, and let the user untarzip it. Users are smart, they will figure out how to untarzip an archive.
The *real* problem is, how to find out which abstractions and externals are actually used. I tend to have one or more directories of abstractions that I use in many patches. It would be nice to have a "Save with abstractions and external" menu entry that would search for and save copies of used abstractions and maybe externals to a directory, or at least print a list of used abstractions and externals, so that I can easily copy them somewhere else.
DesireData's Class Browser may be or evolve into such a thing.
Frank Barknecht _ ______footils.org_ __goto10.org__
On 8/8/06, Frank Barknecht fbar@footils.org wrote:
The *real* problem is, how to find out which abstractions and externals are actually used. I tend to have one or more directories of abstractions that I use in many patches. It would be nice to have a "Save with abstractions and external" menu entry that would search for and save copies of used abstractions and maybe externals to a directory, or at least print a list of used abstractions and externals, so that I can easily copy them somewhere else.
Would it work to just remove all the -lib startup flags, put all your externals in Pd's search path, and then watch the printout when the patch loads? It might also be feasible to make an abstraction using [textfile]s to compare objects in a patch with entries in a library. If names of objects are always in the same column of the text for a patch, [list trim]s could discard all but that.
I noticed when trying to set up my sequencer for OSX that, if I didn't want to use Pd-external, I had to find all the darwin files for the individual objects, not just the libraries, and tell it to load each object I was using. It seems like something like that would actually make a smaller package, if license info from the library were included with each object.
Chuckk Hubbard wrote:
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.
At the institute where I work, some people have no idea how to use pd. So, they just start a START-ME.bat file and control the application (=pd patch) via OSC using an interface they are used to. To instal pd on a new machine, I use a self-extracting .exe file, which extracts pd, all required externals and patches to C:\pd - it's a dirty method but everything is predefined this way and the package works on almost every windows machine.
You can even start pd with the -nogui option, so your user won't even know it's there (beside the DOS-window poping out...).
br, Piotr