hi all !
recently i found it quite inconvenient to allow any user to open a sub-patch/abstraction from within a running patch (by simply clicking on it).
since the new release introduced the "properties"-option, maybe it would make sense, to add a flag for abstraction which makes them non-openable from within their parent-patch.
thus you could open it via file/open (or changing it to "enable open on double click" via the properties.)
by the way : would it make sense to create a "pd-play", that lacks of the editing-possibility ? i just think that it might be more secure in several cases (to keep users from incidently damaging patches).
mfg.gtr.ztr IOhannes
by the way : would it make sense to create a "pd-play", that lacks of the editing-possibility ? i just think that it might be more secure in several cases (to keep users from incidently damaging patches).
mfg.gtr.ztr IOhannes
A very good idea! Sometimes I would need to have pd-playback capabilities on machines without pd installed. I still write stand-alone C++ programms that could be created much more easily using pd just because of the easier use of a stand-alone-programms. A small (filesize) pd-player would be a dream for publishing pd-patches in the internet for non-pd users!
Olaf
This reminds me...
I was always wondering if it would be possible to have an interface-less pd. Since there is the loadbang object, it is quite plausible to have a patch that does everything it needs to do without any user interaction at all (or perhaps only interacts via midi or some other non-gui method).
There would need to be an "exit" object tho, so that pd could close itself when it was finished.
A little crzy, but it would permit the creation of 'command line' tools in pd. Possibly commandline arguments could be fed into the $1, $2.. etc positional parameters.
pix.
On Thu, 4 Jan 2001, Olaf Matthes wrote:
by the way : would it make sense to create a "pd-play", that lacks of the editing-possibility ? i just think that it might be more secure in several cases (to keep users from incidently damaging patches).
mfg.gtr.ztr IOhannes
A very good idea! Sometimes I would need to have pd-playback capabilities on machines without pd installed. I still write stand-alone C++ programms that could be created much more easily using pd just because of the easier use of a stand-alone-programms. A small (filesize) pd-player would be a dream for publishing pd-patches in the internet for non-pd users!
Olaf
|I was always wondering if it would be possible to have |an interface-less pd. Since there is the loadbang object, it is quite |plausible to have a patch that does everything it needs to do without any |user interaction at all (or perhaps only interacts via midi or some other |non-gui method). | |There would need to be an "exit" object tho, so that pd could close itself |when it was finished.
guenther had/has a -nogui version of pd somewhere ...
additionally you can do
pd quit;
which might do the "exit" job ..
|A little crzy, but it would permit the creation of 'command line' tools in |pd. Possibly commandline arguments could be fed into the $1, $2.. etc |positional parameters.
-- I x d U · O r 6
of course, there is the "-nogui" in the new (?) pd-release, and i am really fond of this.
but what i meant with "protecting objects" (or a "pd-play", which would lack of the editing-possibility) is, that you really still have your gui (so let any user click on the buttons and use sliders etc) but make the patches not editable.. Something like these digusting things like the "ReBirth",... Simply for users that do not know anything of signal-processing, mathematics or even pcs
(in fact, you would have to modify the pd-gui so that it wouldn't turn to edit-mode, this should be really simple)
mfg.dsa.rse IOhannes
actually, what would be handy is an edit option where you can't edit connections... for when your patch has evolved into digital spaghetti, and you need to shift things around to make it useable/understandable. it would be good to not have to live in fear of accidentally breaking a connection :)
pix.
On Mon, 8 Jan 2001, Johannes M Zmoelnig wrote:
of course, there is the "-nogui" in the new (?) pd-release, and i am really fond of this.
but what i meant with "protecting objects" (or a "pd-play", which would lack of the editing-possibility) is, that you really still have your gui (so let any user click on the buttons and use sliders etc) but make the patches not editable.. Something like these digusting things like the "ReBirth",... Simply for users that do not know anything of signal-processing, mathematics or even pcs
(in fact, you would have to modify the pd-gui so that it wouldn't turn to edit-mode, this should be really simple)
mfg.dsa.rse IOhannes
Not to shamelessly self promote, but you can check out the gui objects at http://mambo.peabody.jhu.edu/~jsarlo/pd. They don't require the pd gui so you can use the -nogui option.
-- __________________________ | | Joseph A. Sarlo | Computer Music Dept. | Peabody Conservatory | Johns Hopkins University | | jsarlo@peabody.jhu.edu |__________________________
On Mon, 8 Jan 2001, Johannes M Zmoelnig wrote:
of course, there is the "-nogui" in the new (?) pd-release, and i am really fond of this.
but what i meant with "protecting objects" (or a "pd-play", which would lack of the editing-possibility) is, that you really still have your gui (so let any user click on the buttons and use sliders etc) but make the patches not editable.. Something like these digusting things like the "ReBirth",... Simply for users that do not know anything of signal-processing, mathematics or even pcs
(in fact, you would have to modify the pd-gui so that it wouldn't turn to edit-mode, this should be really simple)
mfg.dsa.rse IOhannes
|Not to shamelessly self promote, but you can check out the gui objects at |http://mambo.peabody.jhu.edu/~jsarlo/pd. They don't require the pd gui so |you can use the -nogui option.
just tried those .. when i load one of the examples and hit the bang, pd says
bind: Address already in use
and sorta freezes ..
?
-- X d ¥ · o 7 g
If the pygtk bindings are working (you can test them with the examples that come with the pygtk distribution) then two things to try are:
1.) whether you're starting PD from pd/bin. The python scripts (sliderbox.py, buttonbox.py, togglebox.py) need to be in the same directory where you start pd from. Make puts them in pd/bin by default, but you can move them or probably just add them to your path.
2.) whether the port actually is already in use (probably not). I think the example patches use 2000, 2001, and 2002. You can try creating a patch of your own with an object "sliderbox 1 port_no" where port_no is some port not in use.
Hope this helps!
-- __________________________ | | Joseph A. Sarlo | Computer Music Dept. | Peabody Conservatory | Johns Hopkins University | | jsarlo@peabody.jhu.edu |__________________________
On Sun, 11 Feb 2001, [ISO-8859-1] _-�-_ wrote:
|Not to shamelessly self promote, but you can check out the gui objects at |http://mambo.peabody.jhu.edu/~jsarlo/pd. They don't require the pd gui so |you can use the -nogui option.
just tried those .. when i load one of the examples and hit the bang, pd says
bind: Address already in use
and sorta freezes ..
?
-- X d � � o 7 g
|If the pygtk bindings are working (you can test them with the examples |that come with the pygtk distribution) then two things to try are: | |1.) whether you're starting PD from pd/bin. The python scripts |(sliderbox.py, buttonbox.py, togglebox.py) need to be in the same |directory where you start pd from. Make puts them in pd/bin by default, |but you can move them or probably just add them to your path.
yi, just had copy them to cwd .. up + running
-- × d ¥ . 0 R g
pix@test.at writes:
This reminds me...
I was always wondering if it would be possible to have an interface-less pd.
It's all there in the new version. You could use your pd "patch" as sound server and write a completely new gui using commands like in the pdsend example.
Guenter
-
unknown＠example.com -
_-¯-_ -
Guenter Geiger -
Johannes M Zmoelnig -
Joseph A. Sarlo -
jsarlo＠peabody.jhu.edu
-
Olaf Matthes -
pix＠test.at