Hi,
So this is my first post to the list.
back story: I'm running pd in Linux on a small wearable computer. I do not use a screen, mouse, or keyboard, just an arduino box with a button and some other doo dads to control patch loading / activation.
I've successfully automated pd in Windows using a python windows testing library to grab widgets and send keys to applications, but the Gnome alternative cannot see tcl/tk widgets ... I'm better off running without a gui anyway. :P
I've hacked a quick controller patch using the ;open message for a show, but that was only a temp fix as I have no way to close patches from within pd ... or is there? I do not want to have to open an entire set of patches at once as my machine only has 256 Mb of ram and, if I start using lots of samples, this could be a problem.
So now I'm exec launching and SIGINT'ing pd in C :
- lauch pd with the current patch and remember the process id
- the patch contains an osc object to receive all of my controllers
- sigint pd when I'm done (btw Whats the cleanest kill signal to send?)
Now my questions are:
- Is there a built in way to close an open pd patch from within pd ...?
My thinking is that I can open pd with a small control patch that receives messages to open and close patches.
- If not, has anyone made an automation object? Would anyone be interested
if I attempted to write one?
- Does having a built-in method to do this provide any advantage over my
current solution of launching/killing pd?
The advantage I have now is that I can monitor the running status of pd so if it crashes, which it has done when using the aforementioned temp hack, I can safely kill and restart on the current patch.
Thanks!
I don't know anthing about this, but Robot Cowboy is awsome dude!
~Kyle
On 5/5/07, Daniel Wilcox danomatika@gmail.com wrote:
Hi,
So this is my first post to the list.
back story: I'm running pd in Linux on a small wearable computer. I do not use a screen, mouse, or keyboard, just an arduino box with a button and some other doo dads to control patch loading / activation.
I've successfully automated pd in Windows using a python windows testing library to grab widgets and send keys to applications, but the Gnome alternative cannot see tcl/tk widgets ... I'm better off running without a gui anyway. :P
I've hacked a quick controller patch using the ;open message for a show, but that was only a temp fix as I have no way to close patches from within pd ... or is there? I do not want to have to open an entire set of patches at once as my machine only has 256 Mb of ram and, if I start using lots of samples, this could be a problem.
So now I'm exec launching and SIGINT'ing pd in C :
- lauch pd with the current patch and remember the process id
- the patch contains an osc object to receive all of my controllers
- sigint pd when I'm done (btw Whats the cleanest kill signal to send?)
Now my questions are:
- Is there a built in way to close an open pd patch from within pd ...?
My thinking is that I can open pd with a small control patch that receives messages to open and close patches.
- If not, has anyone made an automation object? Would anyone be interested
if I attempted to write one?
- Does having a built-in method to do this provide any advantage over my
current solution of launching/killing pd?
The advantage I have now is that I can monitor the running status of pd so if it crashes, which it has done when using the aforementioned temp hack, I can safely kill and restart on the current patch.
Thanks!
-- Dan Wilcox danomatika www.robotcowboy.com _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Daniel,
I don't know if it has advantages, but it is possoble to open/close patches from another patch. Maybe an advantage would be that it is faster, because you don't have to resart pd. but I don't know how to handle crashes... anyway, have a look at manuals/pd-msg/2.message_and_pd/2.open_close.pd you open a patch by using a message to pd (starting with ";pd"). the first argument is open, the second the patchname and the third the directory. to close you give the argument menuclose and then the prefix "pd-" and the patchname. some time ago it was not possible to use abbreviations for directories (like a dot). maybe this works now. but you can always use the full path name. regarding closing, many people are talking about a "closebang" but I am not sure if that is about shutting down pd or closing a patch. it should provide a clean shutdown. maybe this affects serial connections? I don't know. For me it worked the way I described it above and I had no problems. [that is a message( [;pd open mypatch.pd /home/marius/pd( [;pd menuclose pd-mypatch.pd(
marius.
Daniel Wilcox wrote:
Hi,
So this is my first post to the list.
back story: I'm running pd in Linux on a small wearable computer. I do not use a screen, mouse, or keyboard, just an arduino box with a button and some other doo dads to control patch loading / activation.
I've successfully automated pd in Windows using a python windows testing library to grab widgets and send keys to applications, but the Gnome alternative cannot see tcl/tk widgets ... I'm better off running without a gui anyway. :P
I've hacked a quick controller patch using the ;open message for a show, but that was only a temp fix as I have no way to close patches from within pd ... or is there? I do not want to have to open an entire set of patches at once as my machine only has 256 Mb of ram and, if I start using lots of samples, this could be a problem.
So now I'm exec launching and SIGINT'ing pd in C :
- lauch pd with the current patch and remember the process id
- the patch contains an osc object to receive all of my controllers
- sigint pd when I'm done (btw Whats the cleanest kill signal to send?)
Now my questions are:
- Is there a built in way to close an open pd patch from within pd ...?
My thinking is that I can open pd with a small control patch that receives messages to open and close patches.
- If not, has anyone made an automation object? Would anyone be
interested if I attempted to write one?
- Does having a built-in method to do this provide any advantage over my
current solution of launching/killing pd?
The advantage I have now is that I can monitor the running status of pd so if it crashes, which it has done when using the aforementioned temp hack, I can safely kill and restart on the current patch.
Thanks!
-- Dan Wilcox danomatika www.robotcowboy.com http://www.robotcowboy.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sat, 2007-05-05 at 14:45 -0400, marius schebella wrote:
[;pd open mypatch.pd /home/marius/pd(
woks here the same (note: you can use relative pathes, but they are relative to the location, where you started pd from)
[;pd menuclose pd-mypatch.pd(
this doesn't work on my computer with my version of (pd 0.40.2): "unkown message menuclose". are you sure about that? in order to dynamically close patches, i use:
[; pd-nameofthepatch.pd menuclose 1(
the '1' avoids the 'close this window?'-popup.
roman
marius.
Daniel Wilcox wrote:
Hi,
So this is my first post to the list.
back story: I'm running pd in Linux on a small wearable computer. I do not use a screen, mouse, or keyboard, just an arduino box with a button and some other doo dads to control patch loading / activation.
I've successfully automated pd in Windows using a python windows testing library to grab widgets and send keys to applications, but the Gnome alternative cannot see tcl/tk widgets ... I'm better off running without a gui anyway. :P
I've hacked a quick controller patch using the ;open message for a show, but that was only a temp fix as I have no way to close patches from within pd ... or is there? I do not want to have to open an entire set of patches at once as my machine only has 256 Mb of ram and, if I start using lots of samples, this could be a problem.
So now I'm exec launching and SIGINT'ing pd in C :
- lauch pd with the current patch and remember the process id
- the patch contains an osc object to receive all of my controllers
- sigint pd when I'm done (btw Whats the cleanest kill signal to send?)
Now my questions are:
- Is there a built in way to close an open pd patch from within pd ...?
My thinking is that I can open pd with a small control patch that receives messages to open and close patches.
- If not, has anyone made an automation object? Would anyone be
interested if I attempted to write one?
- Does having a built-in method to do this provide any advantage over my
current solution of launching/killing pd?
The advantage I have now is that I can monitor the running status of pd so if it crashes, which it has done when using the aforementioned temp hack, I can safely kill and restart on the current patch.
Thanks!
-- Dan Wilcox danomatika www.robotcowboy.com http://www.robotcowboy.com
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
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Thanks guys.
On 5/5/07, marius schebella marius.schebella@gmail.com wrote:
Hi Daniel,
I don't know if it has advantages, but it is possoble to open/close patches from another patch. Maybe an advantage would be that it is faster, because you don't have to resart pd. but I don't know how to handle crashes...
Currently, I call ps every now and then to get the status of pd using pd's pid. If it has stalled I can kill and restart it. I'm setting up my whole system as a Linux daemon that runs in the background and handles patch control and input devices. It starts jack for me and connects all of my midi connections. Currently, I'm using udev to tell the daemon when a new device is connected so it will start a new listener that sends OSC from the device or to shut it down on a removal (device = sdl joystick). That way, everything is plug and play since I have no way of setting anything up without a gui and mouse/keyboard. If anyone is interested, I'm thinking of making a release available to try out. There is a client mode that will only handle the devices so multiple machines can send input info. (ahh OSC power). It's all hackish alpha, but it is starting to work ...
anyway, have a look at
manuals/pd-msg/2.message_and_pd/2.open_close.pd
I swear I went through the whole manual and didnt notice this!
you open a patch by using a message to pd (starting with ";pd").
the first argument is open, the second the patchname and the third the directory. to close you give the argument menuclose and then the prefix "pd-" and the patchname. some time ago it was not possible to use abbreviations for directories (like a dot). maybe this works now. but you can always use the full path name. regarding closing, many people are talking about a "closebang" but I am not sure if that is about shutting down pd or closing a patch. it should provide a clean shutdown. maybe this affects serial connections? I don't know. For me it worked the way I described it above and I had no problems. [that is a message( [;pd open mypatch.pd /home/marius/pd( [;pd menuclose pd-mypatch.pd(
Awesome .. I will have to try this out!
marius.
Daniel Wilcox wrote:
Hi,
So this is my first post to the list.
back story: I'm running pd in Linux on a small wearable computer. I do not use a screen, mouse, or keyboard, just an arduino box with a button and some other doo dads to control patch loading / activation.
I've successfully automated pd in Windows using a python windows testing library to grab widgets and send keys to applications, but the
Gnome
alternative cannot see tcl/tk widgets ... I'm better off running without a gui anyway. :P
I've hacked a quick controller patch using the ;open message for a show, but that was only a temp fix as I have no way to close patches from within pd ... or is there? I do not want to have to open an entire set of patches at once as my machine only has 256 Mb of ram and, if I start using lots of samples, this could be a problem.
So now I'm exec launching and SIGINT'ing pd in C :
- lauch pd with the current patch and remember the process id
- the patch contains an osc object to receive all of my controllers
- sigint pd when I'm done (btw Whats the cleanest kill signal to send?)
Now my questions are:
- Is there a built in way to close an open pd patch from within pd ...?
My thinking is that I can open pd with a small control patch that receives messages to open and close patches.
- If not, has anyone made an automation object? Would anyone be
interested if I attempted to write one?
- Does having a built-in method to do this provide any advantage over my
current solution of launching/killing pd?
The advantage I have now is that I can monitor the running status of pd so if it crashes, which it has done when using the aforementioned temp hack, I can safely kill and restart on the current patch.
Thanks!
-- Dan Wilcox danomatika www.robotcowboy.com http://www.robotcowboy.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Max Neupert wrote:
Am 06.05.2007 um 02:28 schrieb Daniel Wilcox:
[;pd open mypatch.pd /home/marius/pd( [;pd menuclose pd-mypatch.pd(
Awesome .. I will have to try this out!
just keep in mind that this will crash pd if you have two patches
with this (same) name opened.
yea, this and also some other bad combinations of these commands. for example if you want to open a new patch, and at the same time close the patch that opens the new patch in a recursion message... marius.
On Sat, May 05, 2007 at 12:41:24PM +0200, Daniel Wilcox wrote:
- Is there a built in way to close an open pd patch from within pd ...?
What I usually do in this situation is have several container subpatches like [pd instrument1] [pd instrument2] etc.. and then send internal messages to each one to instantiate objects:
[; pd-instrument1 obj 10 10 my-awesome-patch arg1 arg2 arg3...; (
And to delete/close your patch:
[; pd-instrument1 clear; (
I'm not sure if I can say why this is better than using open and close. It just seems cleaner and more programmatic to me for some reason.
Best,
Chris.
-
Chris McCormick -
Daniel Wilcox -
Kyle Klipowicz -
marius schebella -
Max Neupert -
Roman Haefeli