[PD-dev] [ pure-data-Bugs-3393013 ] Pd won't start with Novation keyboard connected
Bugs item #3393013, was opened at 2011-08-17 12:31 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=3393013group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.43 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Pd won't start with Novation keyboard connected Initial Comment: I can't get Pd 0.43.0 to launch when I have a Novation ReMOTE 25 LE keyboard connected to my MacBook Pro (OS X 10.6.8, 2.2GHz Core 2 Duo). The icon bounces in the dock, then stops loading. Attach is the console log. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=3393013group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-3393135 ] pd midi problems
Bugs item #3393135, was opened at 2011-08-17 17:11 Message generated for change (Tracker Item Submitted) made by lucos You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=3393135group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.43 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Luc Deschenaux (lucos) Assigned to: Nobody/Anonymous (nobody) Summary: pd midi problems Initial Comment: Running on ubuntu 11.04 natty amd64 with kernel 2.6.38-8-generic, i have a midi interface on hw:1 (a Tascam US-122L soundcard, but only the midi interface is usable) I can see incoming midi messages with amidi -d -p hw:1 - - Pd 0.43.1extended-20110817 amd 64 (run with -alsamidi -mididev 1) I try to send sysex via midiout but it doesn't works (the led on the midi interface is not blinking) Although noteout and pgmout are working in midi-help.pd (but crash pd when i dont unload module snd_seq_dummy or aconnect -d the kernel midithru port before) midiin and sysexin aren't working (i cannot test notein or ctlin) :-( - Pd-0.43.1test2 amd 64 (from git 20110817) and ran with -alsamidi -mididev 1: (same for version 0.42.6) midiout sends data to the interface, but midiin and sysexin aren't receiving any data from the interface, although they echo data i send to midiout when the kernel midi thru port (snd_seq_dummy) is connected -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=3393135group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-3383901 ] word wrap in pdwindow
Patches item #3383901, was opened at 2011-08-01 16:21 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=3383901group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: word wrap in pdwindow Initial Comment: This patch changes the Pd window to make line breaks at word boundaries. This is more legible than the default text widget behavior, which is to break at character boundaries. -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-08-17 11:35 Message: In all the tools I use, from terminals to log viewers to programming editors, they wrap on characters rather than words. That's pretty typical for UNIX or GNU tools. I am sure many people would prefer word wrapping, therefore a GUI plugin gives us both options. -- Comment By: Jonathan Wilkes (jancsika1) Date: 2011-08-17 01:17 Message: I'm not quite sure what the purpose would be. I'm submi tting this as an improvement over tk's default wrapping , which splits atoms in the pdwindow. I suppose there's the slight side effect of introducing more ambiguity b etween word wrapping and the line breaks which represen t the end of a message, but generally one scans for pr int or whatever one specified as an argument to print, followed by a colon. (Anyhow, the way to get rid of t hat ambiguity altogether is to have two bgcolors that a lternate each time something is posted to the pdwindow. ) -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-08-16 23:30 Message: this would make a good GUI plugin, it would be simple, something like: .pdwindow.text configure -wrap word -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=3383901group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tkwidgets
Hey Jonathan, I'm cc'ing pd-dev since this is a topic that could interest others and others could contribute to. I've started a private git branch of tkwidgets that I intent to push once I get somewhere with it. The idea is to try out a new idea for how GUI objects can work. Basically, I think I can make it so that Tcl handles more of the interaction with the user, minimizing on pd-gui -- pd communications, and making it easier to write GUI objects. Its not trivial to do, but should be doable. .hc On Aug 17, 2011, at 12:26 PM, Jonathan Wilkes wrote: Never mind, I see it now inside canvas_vis... too bad canvas' window subcommand doesn't have something like pack's -in option... But I guess I could make a toplevel checkbutton widget and just manually clone it. -Jonathan From: Jonathan Wilkes jancs...@yahoo.com To: Hans- Christoph Steiner h...@at.or.at Sent: Wednesday, August 17, 2011 3:14 AM Subject: tkwidgets Hi Hans, Do I have it right that your tkwidgets get destroyed when the containing patch is vis'd 0? If so, any hints on how this happens? Specifically, I'm playing around with [checkbutton], and even if I comment out everything in eraseme and checkbutton_free, and every single destroy subcommand, I still get a tcl error when sending a bang or float to a [checkbutton] that's in a subpatch with no window mapped: (Tcl) INVALID COMMAND NAME: invalid command name .x252a690.c.widget25272b0 while executing .x252a690.c.widget25272b0 cget -onvalue (uplevel body line 2) invoked from within uplevel #0 $cmd_from_pd Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tkwidgets
How does your private git branch differ from what's currently in svn? One thing I'd like to point out is that your tkwidgets suffer from the same problem tot/widget did -- by handling all the widget state in tcl you make it impossible to use your objects inside a subpatch/abstraction that doesn't have a visible canvas (because the widget no longer exists). I was considering create a master widget as a child of the main window and sync it to the widget drawn on the canvas, but that seems like a lot of trouble. Is there some other workaround? Another thing: to get Pd-style interaction, bind $canvas EditMode to a proc that sets -state to disabled for all tkwidgets in that $canvas when editmode == 1. That way you don't end up triggering the widget when you want to edit it. -Jonathan From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev List pd-dev@iem.at Sent: Wednesday, August 17, 2011 2:54 PM Subject: Re: tkwidgets Hey Jonathan, I'm cc'ing pd-dev since this is a topic that could interest others and others could contribute to. I've started a private git branch of tkwidgets that I intent to push once I get somewhere with it. The idea is to try out a new idea for how GUI objects can work. Basically, I think I can make it so that Tcl handles more of the interaction with the user, minimizing on pd-gui -- pd communications, and making it easier to write GUI objects. Its not trivial to do, but should be doable. .hc On Aug 17, 2011, at 12:26 PM, Jonathan Wilkes wrote: Never mind, I see it now inside canvas_vis... too bad canvas' window subcommand doesn't have something like pack's -in option... But I guess I could make a toplevel checkbutton widget and just manually clone it. -Jonathan From: Jonathan Wilkes jancs...@yahoo.com To: Hans- Christoph Steiner h...@at.or.at Sent: Wednesday, August 17, 2011 3:14 AM Subject: tkwidgets Hi Hans, Do I have it right that your tkwidgets get destroyed when the containing patch is vis'd 0? If so, any hints on how this happens? Specifically, I'm playing around with [checkbutton], and even if I comment out everything in eraseme and checkbutton_free, and every single destroy subcommand, I still get a tcl error when sending a bang or float to a [checkbutton] that's in a subpatch with no window mapped: (Tcl) INVALID COMMAND NAME: invalid command name .x252a690.c.widget25272b0 while executing .x252a690.c.widget25272b0 cget -onvalue (uplevel body line 2) invoked from within uplevel #0 $cmd_from_pd Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tkwidgets
On Aug 17, 2011, at 6:23 PM, Jonathan Wilkes wrote: How does your private git branch differ from what's currently in svn? I pushed my git to github, my latest work is in the 'newentry' branch. I basically focused on the [entry] widget to see if I could get it going with this new approach. https://github.com/pd-projects/tkwidgets One thing I'd like to point out is that your tkwidgets suffer from the same problem tot/widget did -- by handling all the widget state in tcl you make it impossible to use your objects inside a subpatch/ abstraction that doesn't have a visible canvas (because the widget no longer exists). I was considering create a master widget as a child of the main window and sync it to the widget drawn on the canvas, but that seems like a lot of trouble. Is there some other workaround? That is true, but tkwidgets are all about using Tk widgets in Pd as easily as possible. If the Tk widget is not drawn to the screen, then the Tk widget is not involved. What is the problem in particular? You want to change its state while its not visible? I think the idea there is to have the state stored in the standard struct as a dump from the Tk widget. So when its not visible, store the state-changes, when it becomes visible, dump the state to the Tk widget. Another thing: to get Pd-style interaction, bind $canvas EditMode to a proc that sets -state to disabled for all tkwidgets in that $canvas when editmode == 1. That way you don't end up triggering the widget when you want to edit it. Yeah, tkwidgets was mostly written about the same time as I starting the pd-gui-rewrite. As I rewrote a lot of pd-gui, I realized I should wait on tkwidgets since I could fix a lot of things in pd-gui first. The EditMode message is one example. tkwdigets is not complete yet, so this is not fully in there. I think the [entry] in github does this kind of stuff. .hc Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev List pd-dev@iem.at Sent: Wednesday, August 17, 2011 2:54 PM Subject: Re: tkwidgets Hey Jonathan, I'm cc'ing pd-dev since this is a topic that could interest others and others could contribute to. I've started a private git branch of tkwidgets that I intent to push once I get somewhere with it. The idea is to try out a new idea for how GUI objects can work. Basically, I think I can make it so that Tcl handles more of the interaction with the user, minimizing on pd-gui -- pd communications, and making it easier to write GUI objects. Its not trivial to do, but should be doable. .hc On Aug 17, 2011, at 12:26 PM, Jonathan Wilkes wrote: Never mind, I see it now inside canvas_vis... too bad canvas' window subcommand doesn't have something like pack's -in option... But I guess I could make a toplevel checkbutton widget and just manually clone it. -Jonathan From: Jonathan Wilkes jancs...@yahoo.com To: Hans- Christoph Steiner h...@at.or.at Sent: Wednesday, August 17, 2011 3:14 AM Subject: tkwidgets Hi Hans, Do I have it right that your tkwidgets get destroyed when the containing patch is vis'd 0? If so, any hints on how this happens? Specifically, I'm playing around with [checkbutton], and even if I comment out everything in eraseme and checkbutton_free, and every single destroy subcommand, I still get a tcl error when sending a bang or float to a [checkbutton] that's in a subpatch with no window mapped: (Tcl) INVALID COMMAND NAME: invalid command name .x252a690.c.widget25272b0 while executing .x252a690.c.widget25272b0 cget -onvalue (uplevel body line 2) invoked from within uplevel #0 $cmd_from_pd Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tkwidgets
The problem is for a subpatch that isn't vis'd: [inlet] | [checkbutton] | [outlet] Will give an error on bang because checkbutton_bang has: sys_vgui(%s invoke\n, x-widget_id-s_name); That could be solved by using a -variable option, but then that limits you because the nonzero value cannot be changed.* So yeah, the best solution is stored state in the struct so you can access it in the c functions without caring about the vis state of the obj. Is that the idea behind the options_binbuf? * also note that checkbutton's default behavior is the opposite from tgl: tgl: zero = off, nonzero = on checkbutton: onvalue = on, everything else = off From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev List pd-dev@iem.at Sent: Wednesday, August 17, 2011 7:24 PM Subject: Re: tkwidgets On Aug 17, 2011, at 6:23 PM, Jonathan Wilkes wrote: How does your private git branch differ from what's currently in svn? I pushed my git to github, my latest work is in the 'newentry' branch. I basically focused on the [entry] widget to see if I could get it going with this new approach. https://github.com/pd-projects/tkwidgets One thing I'd like to point out is that your tkwidgets suffer from the same problem tot/widget did -- by handling all the widget state in tcl you make it impossible to use your objects inside a subpatch/abstraction that doesn't have a visible canvas (because the widget no longer exists). I was considering create a master widget as a child of the main window and sync it to the widget drawn on the canvas, but that seems like a lot of trouble. Is there some other workaround? That is true, but tkwidgets are all about using Tk widgets in Pd as easily as possible. If the Tk widget is not drawn to the screen, then the Tk widget is not involved. What is the problem in particular? You want to change its state while its not visible? I think the idea there is to have the state stored in the standard struct as a dump from the Tk widget. So when its not visible, store the state-changes, when it becomes visible, dump the state to the Tk widget. Another thing: to get Pd-style interaction, bind $canvas EditMode to a proc that sets -state to disabled for all tkwidgets in that $canvas when editmode == 1. That way you don't end up triggering the widget when you want to edit it. Yeah, tkwidgets was mostly written about the same time as I starting the pd-gui-rewrite. As I rewrote a lot of pd-gui, I realized I should wait on tkwidgets since I could fix a lot of things in pd-gui first. The EditMode message is one example. tkwdigets is not complete yet, so this is not fully in there. I think the [entry] in github does this kind of stuff. .hc Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev List pd-dev@iem.at Sent: Wednesday, August 17, 2011 2:54 PM Subject: Re: tkwidgets Hey Jonathan, I'm cc'ing pd-dev since this is a topic that could interest others and others could contribute to. I've started a private git branch of tkwidgets that I intent to push once I get somewhere with it. The idea is to try out a new idea for how GUI objects can work. Basically, I think I can make it so that Tcl handles more of the interaction with the user, minimizing on pd-gui -- pd communications, and making it easier to write GUI objects. Its not trivial to do, but should be doable. .hc On Aug 17, 2011, at 12:26 PM, Jonathan Wilkes wrote: Never mind, I see it now inside canvas_vis... too bad canvas' window subcommand doesn't have something like pack's -in option... But I guess I could make a toplevel checkbutton widget and just manually clone it. -Jonathan From: Jonathan Wilkes jancs...@yahoo.com To: Hans- Christoph Steiner h...@at.or.at Sent: Wednesday, August 17, 2011 3:14 AM Subject: tkwidgets Hi Hans, Do I have it right that your tkwidgets get destroyed when the containing patch is vis'd 0? If so, any hints on how this happens? Specifically, I'm playing around with [checkbutton], and even if I comment out everything in eraseme and checkbutton_free, and every single destroy subcommand, I still get a tcl error when sending a bang or float to a [checkbutton] that's in a subpatch with no window mapped: (Tcl) INVALID COMMAND NAME: invalid command name .x252a690.c.widget25272b0 while executing .x252a690.c.widget25272b0 cget -onvalue (uplevel body line 2) invoked from within uplevel #0 $cmd_from_pd Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams We have nothing to fear from love and
Re: [PD-dev] tkwidgets
On Aug 17, 2011, at 8:17 PM, Jonathan Wilkes wrote: The problem is for a subpatch that isn't vis'd: [inlet] | [checkbutton] | [outlet] Will give an error on bang because checkbutton_bang has: sys_vgui(%s invoke\n, x-widget_id-s_name); That could be solved by using a -variable option, but then that limits you because the nonzero value cannot be changed.* So yeah, the best solution is stored state in the struct so you can access it in the c functions without caring about the vis state of the obj. Is that the idea behind the options_binbuf? Yeah, options_binbuf is related to dumping/setting the Tk configuration for the widget. Once the resizing, Tk configuration saving, interaction technique, etc. is settled, then we can nail down details like what needs to happen when the Tk widget does not exist but the object receives a message. * also note that checkbutton's default behavior is the opposite from tgl: tgl: zero = off, nonzero = on checkbutton: onvalue = on, everything else = off One of the goals of tkwidgets is to have the Tk widgets represented in Pd as directly as possible. Then the Tk docs apply, for example. And it will hopefully be easier to manage more complicated configurations if there isn't a layer of abstraction between Tk and Pd. If you are interested in working on tkwidgets, that would be great! I think the easiest place to start would be to make a 'label' object based on the Tk label widget. .hc From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev List pd-dev@iem.at Sent: Wednesday, August 17, 2011 7:24 PM Subject: Re: tkwidgets On Aug 17, 2011, at 6:23 PM, Jonathan Wilkes wrote: How does your private git branch differ from what's currently in svn? I pushed my git to github, my latest work is in the 'newentry' branch. I basically focused on the [entry] widget to see if I could get it going with this new approach. https://github.com/pd-projects/tkwidgets One thing I'd like to point out is that your tkwidgets suffer from the same problem tot/widget did -- by handling all the widget state in tcl you make it impossible to use your objects inside a subpatch/ abstraction that doesn't have a visible canvas (because the widget no longer exists). I was considering create a master widget as a child of the main window and sync it to the widget drawn on the canvas, but that seems like a lot of trouble. Is there some other workaround? That is true, but tkwidgets are all about using Tk widgets in Pd as easily as possible. If the Tk widget is not drawn to the screen, then the Tk widget is not involved. What is the problem in particular? You want to change its state while its not visible? I think the idea there is to have the state stored in the standard struct as a dump from the Tk widget. So when its not visible, store the state-changes, when it becomes visible, dump the state to the Tk widget. Another thing: to get Pd-style interaction, bind $canvas EditMode to a proc that sets -state to disabled for all tkwidgets in that $canvas when editmode == 1. That way you don't end up triggering the widget when you want to edit it. Yeah, tkwidgets was mostly written about the same time as I starting the pd-gui-rewrite. As I rewrote a lot of pd-gui, I realized I should wait on tkwidgets since I could fix a lot of things in pd-gui first. The EditMode message is one example. tkwdigets is not complete yet, so this is not fully in there. I think the [entry] in github does this kind of stuff. .hc Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev List pd-dev@iem.at Sent: Wednesday, August 17, 2011 2:54 PM Subject: Re: tkwidgets Hey Jonathan, I'm cc'ing pd-dev since this is a topic that could interest others and others could contribute to. I've started a private git branch of tkwidgets that I intent to push once I get somewhere with it. The idea is to try out a new idea for how GUI objects can work. Basically, I think I can make it so that Tcl handles more of the interaction with the user, minimizing on pd-gui -- pd communications, and making it easier to write GUI objects. Its not trivial to do, but should be doable. .hc On Aug 17, 2011, at 12:26 PM, Jonathan Wilkes wrote: Never mind, I see it now inside canvas_vis... too bad canvas' window subcommand doesn't have something like pack's -in option... But I guess I could make a toplevel checkbutton widget and just manually clone it. -Jonathan From: Jonathan Wilkes jancs...@yahoo.com To: Hans- Christoph Steiner h...@at.or.at Sent: Wednesday, August 17, 2011 3:14 AM Subject: tkwidgets Hi Hans, Do I have it right that your tkwidgets get destroyed when the containing patch is vis'd 0? If so, any hints on how this happens? Specifically, I'm playing around with [checkbutton], and even if I comment out everything in eraseme
