[PD] Threaded console output
Hans and all, There was recently a mention of threaded output in pd-extended 0.43 which prevents the console from overwhelming the main thread. Has this been implemented and if so, in which file is this implementation located? Any help on this one is most appreciated! Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] New versions of pd-l2ork now available on git
All, Pd-L2ork is now available both as a tarball and via git: http://l2ork.music.vt.edu/main/?page_id=56 https://github.com/pd-l2ork/ Testers/contributors are as always most appreciated. NB: Pd-l2ork is currently Linux-only although this may change down the road. Some of the recent changes include: 2011-10-25 *Fixed a monster segfault bug that occurred when using toggling graph-on-parent and cut in succession (usually in combination with undo/redo). 2011-10-24 *Added undo/redo for creating new objects 2011-10-22 *Implemented universal copy/paste 2011-10-21 *Fixed gop enable/disable segfault (when doing so on an empty canvas) *Added undo for the canvas properties 2011-08-24 *Fixed gop redrawing issue when passed coords message via script *Fixed pack not converting null lists into bangs Coming up soon: *graph-on-parent enable/disable does not activate undo/redo on the parent window (or the gop-ed patch unless it is open) *Infinite undo *Ability to draw red GOP rectangle *Universal copy/paste should also resize the canvas as per original script? *Consider making hslider and vslider capable of doing int data Cheers! Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) i...@vt.edu http://www.music.vt.edu/faculty/bukvic/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] New versions of pd-l2ork now available on git
> > Is this based on Pd 0.43 ? > > > Seems to be a mix, its got the 0.43 Tcl, but the 0.42 header: > > https://github.com/pd-l2ork/pd/blob/master/src/m_pd.h > > .hc Indeed, it is a mix. Some of our implementations (e.g. magicglass) got ported by Hans and some of upstream was backported. I feel like 0.43 Tcl code is not yet vetted enough for me to move in that direction (we're stuck in this in-between 0.42 and 0.43 version because a lot of time was spent squashing serious bugs, many of which appear to be present in the 0.43 branch). That said, pd-l2ork has close to 200 features and bugfixes that are unique to it. For more info, please see the Changelog. http://l2ork.music.vt.edu/data/pd/Changelog Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] New versions of pd-l2ork now available on git
> I'd love to be able to include bugfixes from pd-l2ork. I looked thru > the code and I can't really find what changes belong to what > Changelog > items. Can you point me towards the code related to these Changelog > items, and expand on what they do, if you can? Then I can work on > including them in Pd-extended: > > *Implemented universal copy/paste > *Fixed gop redrawing issue when passed coords message via script > *finally discovered the root of all double-entry bugs (fingers > crossed) and reverted all other previous workarounds for this problem. > *fixed bug where patch cords were not getting erased (due to > fundamental fixes in the previous patch how the things are being > destructed, this has resulted in this bug being "hidden" until now). Many of the older pre-git day bugs can be only traced by diff-ing our extensive snapshot repository available here: http://l2ork.music.vt.edu/data/pd/ This is in part why we've set up a git. To make this transition easier for other branches... Hope this helps! Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] New versions of pd-l2ork now available on git
> -Original Message- > From: Hans-Christoph Steiner [mailto:h...@at.or.at] > Sent: Wednesday, October 26, 2011 3:19 PM > To: Ivica Ico Bukvic > Cc: 'Roman Haefeli'; pd-list@iem.at > Subject: Re: [PD] New versions of pd-l2ork now available on git > > > On Oct 26, 2011, at 2:49 PM, Ivica Ico Bukvic wrote: > > >> I'd love to be able to include bugfixes from pd-l2ork. I looked thru > >> the code and I can't really find what changes belong to what > >> Changelog > >> items. Can you point me towards the code related to these > Changelog > >> items, and expand on what they do, if you can? Then I can work on > >> including them in Pd-extended: > >> > >> *Implemented universal copy/paste > >> *Fixed gop redrawing issue when passed coords message via script > >> *finally discovered the root of all double-entry bugs (fingers > >> crossed) and reverted all other previous workarounds for this > >> problem. > >> *fixed bug where patch cords were not getting erased (due to > >> fundamental fixes in the previous patch how the things are being > >> destructed, this has resulted in this bug being "hidden" until now). > > > > Many of the older pre-git day bugs can be only traced by diff-ing > > our extensive snapshot repository available here: > > > > http://l2ork.music.vt.edu/data/pd/ > > > > This is in part why we've set up a git. To make this transition > > easier for other branches... > > > > Hope this helps! > > > > Best wishes, > > > > Ico > > One thing that you could do that would make the history much easier to > browse is to start your git repo from the pure-data.git from Miller, > then untar each pd_l2ork release on top and check each release in, > then add the current contents of your git on top of that. > > I can do that for you, if that would be helpful. It would only be > worthwhile if this then replaces the contents of your current git repo. If you think this would yield favorable results then I'd say let's go for it. My concern is that in the process of learning the pd code which has a relatively steep learning curve I ended up a good chunk of comments and reformatted some of the code to make things more legible for me (which does not mean it would also be legible for others). I also had to backtrack some of the changes and temporary hacks until I discovered the root of the problem (e.g. double-entry bug which has been entirely solved in pd-l2ork, or the gop redrawing bugs which have been also solved, and most recently enabling and immediately disabling gop that crashes any pd but pd-l2ork). One last roadblock is that the Changelog was not date stamped right from the outset so some of the earlier patches may not be easily decipherable but I can assist with those to the best of my ability. So, please let me know if you wish to proceed and you'll have my full support. Best wishes, Ico > > .hc > > > > > > > > "It is convenient to imagine a power beyond us because that means we > don't have to examine our own lives.", from "The Idols of > Environmentalism", by Curtis White > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] New versions of pd-l2ork now available on git
> It looks like it'll take overnight to download all of the pd-l2ork-dev > tarballs. > So should be able to have this done tomorrow. You still up for swapping > this in as your git repo? > > .hc Will I have complete control over it? In other words, I need to be made into an admin for it. If that is ok with you I am perfectly fine with making it the main repo. As an alternative, we could always mirror ours with this one... Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
Indeed, pd-l2ork moves entire selection by tag, so instead of redrawing everything, out issues single tcl/tk command. The only thing that still redrawed every time when displaced is gop-enabled patcher. Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Jonathan Wilkes wrote: I believe Ivica made such a modification in Pd-l2ork-- whatever the case, moving many iemguis in Pd-l2ork is much snappier than in Vanilla or Pd-extended. But I haven't measured the cpu load. -Jonathan - Original Message - > From: Hans-Christoph Steiner > To: João Pais > Cc: katja ; "pd-list@iem.at" ; > Jonathan Wilkes > Sent: Thursday, November 3, 2011 11:07 AM > Subject: Re: [PD] how to capture window-related mouse-events when toxy is > discontinued? > > > I doubt that Tcl/Tk's drawing code is being overloaded. Instead, try > running "path/to/pd -stderr -d 3" and you'll see that 'pd' > is sending 'pd-gui' massive amounts of Tcl code to parse, compile, and > execute. In the case of a move, this could be accomplished with one line of > Tcl > to tag everything you want to move, then one move command to let Tcl/Tk do > the > moving. > > .hc > > On Nov 3, 2011, at 10:31 AM, João Pais wrote: > >> those spikes is what I was predicting with the graphic overloading of > tcl/tk (through data structures, in this case). >> >> you could also try the following: make the "selectable area" > around one corner (or middle) of the button: with a tiny bit more resolution, > but less points in the template. if you want to keep the squares, it's even > better, because it helps you selecting the structs. >> >> Or one other thing: maybe can the tcl/tk code be changed, so that it > doesn't overload that fast? Reduce the redraw rate, or something else? (I > have no idea about tcl/tk) >> >> Or change the output rate of the struct object? (this might not help much) >> >> >> About the background grid for instant jumps, an implementation of it in run > mode is easy. I could try to give an example, but don't have any time for > now. >> >> >>> - Original Message - >>>> From: katja >>>> To: pd-list@iem.at >>>> Cc: >>>> Sent: Thursday, November 3, 2011 6:10 AM >>>> Subject: Re: [PD] how to capture window-related mouse-events when > toxy is discontinued? >>>> >>>> On Thu, Nov 3, 2011 at 1:30 AM, Jonathan Wilkes > >>>> wrote: >>>> >>>>> How does the cpu usage in my demo compare to your patch where > you use >>>>> a radiobutton? >>>> >>>> Here's a cpu load comparison of objects dragged continuously > (on intel >>>> mac 2GHz): >>>> >>>> polygon in movable_box2.pd: 23 % >>>> polygon in 07.sequencer.pd (help browser): 16% >>>> radiobutton in moving_objects.pd: 12 % >>>> regular Pd slider: 13 % >>>> 2D geo in a gem window: 2.5% >>> >>> I just got intermittent rises up to 50% on a dual core 64-bit amd with >>> all of the above. >>> >>> I imagine that the cpu load for movable_box2.pd is due to the number of >>> points in the polygon. I think you could get a 20x20 draggable square > with 8 coordinates-- that >>> would be equal to the number of points in a radiobutton so maybe that > would get down >>> to a corresponding cpu load. >>> >>> I'll try some tweaks later to see if that works. >>> >>> -Jonathan >>> >>>> >>>> Your polygon method is plain vanilla Pd and that makes it > attractive >>>> for a widely shared Pd patch. No risk of broken dependencies. But I > am >>>> afraid it is too cpu-intensive, particularly on Windows. Thanks for >>>> sharing the idea though, it is inspiring. >>>> >>>> Katja >>>> >>>>_ >>>> 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
[PD] Fwd: Re: how to capture window-related mouse-events when toxy is discontinued?
Forgot to copy the list... Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Ivica Ico Bukvic wrote: The said changes are in pre-git tarballs. I think they are also listed in the changelog under a specific date which should make things a bit easier to isolate. That said, implementation alters widgetbehavior struct by adding one more entry and as such it breaks compatibility with gridflow unless recompiled from scratch using the new .h file. Even then there might be other incompatibilities. That said, I've encountered none, other than gridflow. Of course, other externals need to be recompiled as well (but no changes to their source are required). HTH Best wishes, Ico Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Hans-Christoph Steiner wrote: Hey Ico, That's great, we need to do a lot more of that. Can you point me to where these changes are so I can check them out? .hc On Nov 3, 2011, at 2:44 PM, Ivica Ico Bukvic wrote: Indeed, pd-l2ork moves entire selection by tag, so instead of redrawing everything, out issues single tcl/tk command. The only thing that still redrawed every time when displaced is gop-enabled patcher. Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Jonathan Wilkes wrote: I believe Ivica made such a modification in Pd-l2ork-- whatever the case, moving many iemguis in Pd-l2ork is much snappier than in Vanilla or Pd-extended. But I haven't measured the cpu load. -Jonathan - Original Message - > From: Hans-Christoph Steiner > To: João Pais > Cc: katja ; "pd-list@iem.at" ; > Jonathan Wilkes > Sent: Thursday, November 3, 2011 11:07 AM > Subject: Re: [PD] how to capture window-related mouse-events when toxy is > discontinued? > > > I doubt that Tcl/Tk's drawing code is being overloaded. Instead, try > running "path/to/pd -stderr -d 3" and you'll see that 'pd' > is sending 'pd-gui' massive amounts of Tcl code to pa! rse, compile, and > execute. In the case of a move, this could be accomplished with one line of > Tcl > to tag everything you want to move, then one move command to let Tcl/Tk do > the > moving. > > .hc > > On Nov 3, 2011, at 10:31 AM, João Pais wrote: > >> those spikes is what I was predicting with the graphic overloading of > tcl/tk (through data structures, in this case). >> >> you could also try the following: make the "selectable area" > around one corner (or middle) of the button: with a tiny bit more resolution, > but less points in the template. if you want to keep the squares, it's even > better, because it helps you selecting the structs. >> >> Or one other thing: maybe can the tcl/tk code be changed, so that it > doesn't overload that fast? Reduce the redraw rate, or something else? (I > h! ave no idea about tcl/tk) >> >> Or change the output rate of the struct object? (this might not help much) >> >> >> About the background grid for instant jumps, an implementation of it in run > mode is easy. I could try to give an example, but don't have any time for > now. >> >> >>> - Original Message - >>>> From: katja >>>> To: pd-list@iem.at >>>> Cc: >>>> Sent: Thursday, November 3, 2011 6:10 AM >>>> Subject: Re: [PD] how to capture window-related mouse-events when > toxy is discontinued? >>>> >>>> On Thu, Nov 3, 2011 at 1:30 AM, Jonathan Wilkes > >>>> wrote: >>>> >>>>> How does the cpu usage in my demo! compare to your patch where > you use >>>>> a radiobutton? >>>> >>>> Here's a cpu load comparison of objects dragged continuously > (on intel >>>> mac 2GHz): >>>> >>>> polygon in movable_box2.pd: 23 % >>>> polygon in 07.sequencer.pd (help browser): 16% >>>> radiobutton in mo
Re: [PD] how to capture window-related mouse-events when toxy isdiscontinued?
Because after studying the code it looked like a difficult thing to pull off. This is because the regular displacefn is used for initial posting of objects which is absolute in nature while displacewithtag is relative, so the two dont play very nice. HTH Ico _ From: Hans-Christoph Steiner [mailto:h...@at.or.at] Sent: Friday, November 04, 2011 6:26 PM To: Ivica Ico Bukvic Cc: pd-list@iem.at Subject: Re: [PD] how to capture window-related mouse-events when toxy isdiscontinued? Hey Ico, What not just use the displacefn to do the move with tags? Then we wouldn't need to change that core struct. .hc Ivica Ico Bukvic wrote: The said changes are in pre-git tarballs. I think they are also listed in the changelog under a specific date which should make things a bit easier to isolate. That said, implementation alters widgetbehavior struct by adding one more entry and as such it breaks compatibility with gridflow unless recompiled from scratch using the new .h file. Even then there might be other incompatibilities. That said, I've encountered none, other than gridflow. Of course, other externals need to be recompiled as well (but no changes to their source are required). HTH Best wishes, Ico Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu <http://disis.music.vt.edu/> l2ork.music.vt.edu <http://l2ork.music.vt.edu/> ico.bukvic.net <http://ico.bukvic.net/> Hans-Christoph Steiner wrote: Hey Ico, That's great, we need to do a lot more of that. Can you point me to where these changes are so I can check them out? .hc On Nov 3, 2011, at 2:44 PM, Ivica Ico Bukvic wrote: Indeed, pd-l2ork moves entire selection by tag, so instead of redrawing everything, out issues single tcl/tk command. The only thing that still redrawed every time when displaced is gop-enabled patcher. Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu <http://disis.music.vt.edu/> l2ork.music.vt.edu <http://l2ork.music.vt.edu/> ico.bukvic.net <http://ico.bukvic.net/> Jonathan Wilkes wrote: I believe Ivica made such a modification in Pd-l2ork-- whatever the case, moving many iemguis in Pd-l2ork is much snappier than in Vanilla or Pd-extended. But I haven't measured the cpu load. -Jonathan - Original Message - > From: Hans-Christoph Steiner > To: João Pais > Cc: katja ; "pd-list@iem.at" ; > Jonathan Wilkes > Sent: Thursday, November 3, 2011 11:07 AM > Subject: Re: [PD] how to capture window-related mouse-events when toxy is > discontinued? > > > I doubt that Tcl/Tk's drawing code is being overloaded. Instead, try > running "path/to/pd -stderr -d 3" and you'll see that 'pd' > is sending 'pd-gui' massive amounts of Tcl code to pa! rse, compile, and > execute. In the case of a move, this could be accomplished with one line of > Tcl > to tag everything you want to move, then one move command to let Tcl/Tk do > the > moving. > > .hc > > On Nov 3, 2011, at 10:31 AM, João Pais wrote: > >> those spikes is what I was predicting with the graphic overloading of > tcl/tk (through data structures, in this case). >> >> you could also try the following: make the "selectable area" > around one corner (or middle) of the button: with a tiny bit more resolution, > but less points in the template. if you want to keep the squares, it's even > better, because it helps you selecting the structs. >> >> Or one other thing: maybe can the tcl/tk code be changed, so that it > doesn't overload that fast? Reduce the redraw rate, or something else? (I > h! ave no idea about tcl/tk) >> >> Or change the output rate of the struct object? (this might not help much) >> >> >> About the background grid for instant jumps, an implementation of it in run > mode is easy. I could try to give an example, but don't have any time for > now. >> >> >>> - Original Message - >>>> From: katja >>>> To: pd-list@iem.at >>>> Cc: >>>> Sent: Thursday, November 3, 2011 6:10 AM >>>> Subject: Re: [PD] how to capture wi
Re: [PD] how to capture window-related mouse-events when toxy isdiscontinued?
The problem with the approach you suggested is that tcl would have to be aware of all unique redrawing properties of individual objects and externals that may require custom drawing commands. While not impossible, it would require at the very least requiring of all gui-based externals. OTOH, my approach only requires a recompile and I'd rather pick that over the alternative. Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Hans-Christoph Steiner wrote: The problem with changing t_widgetbehavior is that it breaks binary compatibililty, I think. That makes it a pain to manage the transition. Personally, I think it'd be worthwhile to use the struct as it. Or really, I'd like to see bigger changes to offload more stuff to the GUI, like mouse motion and click handling, resizing, etc. For a resize of an object, 'pd' only needs to know about it once its done, not while its happening. .hc On Nov 4, 2011, at 11:36 PM, Ivica Ico Bukvic wrote: > Because after studying the code it looked like a difficult thing to pull off. > This is because the regular displacefn is used for initial posting of objects > which is absolute in nature while displacewithtag is relative, so the two > don’t play very nice. > > HTH > > Ico > > From: Hans-Christoph Steiner [mailto:h...@at.or.at] > Sent: Friday, November 04, 2011 6:26 PM > To: Ivica Ico Bukvic > Cc: pd-list@iem.at > Subject: Re: [PD] how to capture window-related mouse-events when toxy > isdiscontinued? > > > Hey Ico, > > What not just use the displacefn to do the move with tags? Then we wouldn't > need to change that core struct. > > .hc > > Ivica Ico Bukvic wrote: > The said changes are in pre-git tarballs. I think they are also listed in the > changelog under a specific date which should make things a bit easier to > isolate. That said, implementation alters widgetbehavior struct by adding one > more entry and as such it breaks compatibility with gridflow unless > recompiled from scratch using the new .h file. Even then there might be other > incompatibilities. That said, I've encountered none, other than gridflow. Of > course, other externals need to be recompiled as well (but no changes to > their source are required). > > HTH > > Best wishes, > > Ico > > Ivica Ico Bukvic, D.M.A > Composition, Music Technology > Director, DISIS Interactive Sound & Intermedia Studio > Director, L2Ork Linux Laptop Orchestra > Assistant Director, CCTAD > Virginia Tech > Department of Music > Blacksburg, VA 24061-0240 > (540) 231-6139 > (540) 231-5034 (fax) > disis.music.vt.edu > l2ork.music.vt.edu > ico.bukvic.net > > Hans-Christoph Steiner wrote: > > Hey Ico, > > That's great, we need to do a lot more of that. Can you point me to where > these changes are so I can check them out? > > .hc > > On Nov 3, 2011, at 2:44 PM, Ivica Ico Bukvic wrote: > > > Indeed, pd-l2ork moves entire selection by tag, so instead of redrawing > everything, out issues single tcl/tk command. The only thing that still > redrawed every time when displaced is gop-enabled patcher. > > Ivica Ico Bukvic, D.M.A > Composition, Music Technology > Director, DISIS Interactive Sound & Intermedia Studio > Director, L2Ork Linux Laptop Orchestra > Assistant Director, CCTAD > Virginia Tech > Department of Music > Blacksburg, VA 24061-0240 > (540) 231-6139 > (540) 231-5034 (fax) > disis.music.vt.edu > l2ork.music.vt.edu > ico.bukvic.net > > Jonathan Wilkes wrote: > I believe Ivica made such a modification in Pd-l2ork-- whatever the case, > moving many iemguis in > > Pd-l2ork is much snappier than in Vanilla or Pd-extended. But I haven't > measured the cpu load. > > > > -Jonathan > > > > > > - Original Message - > > > From: Hans-Christoph Steiner > > > To: João Pais > > > Cc: katja ; "pd-list@iem.at" ; > > Jonathan Wilkes > > > Sent: Thursday, November 3, 2011 11:07 AM > > > Subject: Re: [PD] how to capture window-related mouse-events when toxy is > > discontinued? > > > > > > > > > I > doubt that Tcl/Tk's drawing code is being overloaded. Instead, try > > > running "path/to/pd -stderr -d 3" and you'll see that 'pd' > > > is sending 'pd-gui' massive amounts of Tcl code
Re: [PD] gdb and Pd WAS: testtone comments
I have not been following this thread at all, but for what it's worth in my experience these kinds of seemingly illogical errors usually arise from memory corruption (typically because something has not been properly allocated). Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Jonathan Wilkes wrote: Before I do that, below is a backtrace with a 0.43 nightly build of extended with gdb. Does it help? If not, I'll compile with the settings you mentioned below. -Jonathan Program received signal SIGSEGV, Segmentation fault. pd_typedmess (x=0x821290, s=0x6c39b0, argc=1, argv=0x7fffe0d0) at m_class.c:708 708m_class.c: No such file or directory. in m_class.c (gdb) watchdog: signaling pd... watchdog: signaling pd... (gdb) (gdb) bawatchdog: signaling pd... cktracewatchdog: signaling pd... #0 pd_typedmess (x=0x821290, s=0x6c39b0, argc=1, argv=0x7fffe0d0) at m_class.c:708 #1 0x0043c629 in pd_typedmess (x=0x830220, s=, argc=, argv=) at m_class.c:812 #2 0x0043b0f1 in bindlist_anything (x=, s=0x6c39b0, argc=1, argv=0x7fffe0d0) at m_pd.c:108 #3 0x0043c629 in pd_typedmess (x=0x8ef320, s=, argc=, argv=) at m_class.c:812 #4 0x00442511 in binbuf_eval (x=, target=0x8ef320, argc=0, argv=0x0) at m_binbuf.c:767 #5 0x004478f9 in socketreceiver_read (x=0x6d9d10, fd=8) at s_inter.c:551 #6 0x004463b1 in sys_domicrosleep (microsec=, pollem=1) at s_inter.c:191 #7 0x0044424d in m_pollingscheduler () at m_sched.c:511 #8 m_mainloop () at m_sched.c:571 #9 0x7677fead in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #10 0x004170c1 in _start () >_ >From: Hans-Christoph Steiner >To: Jonathan Wilkes >Cc: tim vets ; pd-list >Sent: Wednesday, September 28, 2011 2:19 PM >Subject: gdb and Pd WAS: [PD] testtone comments > > >On Sep 28, 2011, at 2:02 PM, Jonathan Wilkes wrote: > >>>_ >>> From: Hans-Christoph Steiner >>> To: Jonathan Wilkes >>> Cc: tim vets ; pd-list >>> Sent: Wednesday, September 28, 2011 12:14 PM >>> Subject: Re: [PD] testtone comments >>> >>> >>> >>> >>> Hey Jonathan, >>> >>> >>> Cool, thanks I'll include that. I was thinking, it would nice if the list >>> of credits at the bottom was randomized. Could you add that? Right now >>> its in a pretty arbitrary order and it would be nice to add names without >>> worrying about the order. >> >> Yes, but I found that there is a segfault that pops up for me on Ubuntu >> Maverick if I clear the subpatches >> >> and save, then close the patch. I can't get gdb working with Pd at the >> moment and so can't figure out what's causing >> >> the error (though I have suspicions it has to do with data structures...) > >You'll want to build Pd with -g in CFLAGS and remove -fomit-frame-pointer. >That should give you much better results with gdb. > >.hc > >> >>> >>> >>> .hc >>> >>> >>> On Sep 28, 2011, at 10:12 AM, Jonathan Wilkes wrote: >>> >>> Here's a fix for about.pd >>>> (Also widened the window a bit so the entire version string can be read on >>>> >>>> systems with larger fonts) >>>> >>>> >>>> -Jonathan >>>> >>>> >>>> >>>> >>>>>_ >>>>> From: tim vets >>>>> To: pd-list >>>>> Sent: Tuesday, September 27, 2011 8:02 AM >>>>> Subject: Re: [PD] testtone comments >>>>> >>>>> >>>>> oh and another detail: >>>>> when selecting "About Pd", I get: >>>>> >>>>> >>>>> error: [print Tcl Version]: got 2 args instead of at least 0, at most 1 >>>>> print Tcl Version >>>>> ... couldn't create >>>>> error: [print Pd Version]: got 2 args instead of at least 0, at most 1 >>>>> print Pd Version >>>>> ... couldn't create >>>>> >>>>> >>>>> I guess you could make those [print Tcl_Version] and
[PD] pd_free vs canvas_vis
I guess this is mainly for the Pd devs, Jonathan and I have been working on trying to have patch close itself through the script. However, even in the newest Pd the problem persists in that if one invokes menuclose via patch it crashes pd. I suspect this is because the closure happens while Pd is still traversing the tree and then trips up on newly deallocated memory pool invoked by the pd_free. Initially, I designed a workaround where pd_free is enqueued on the guiqueue and invoked a bit later ensuring that it is called after the tree navigation has ended. This works in most cases but not all. Intermittently this will crash Pd when using Jonathan's Nav abstraction which closes the current patch and also opens a new patch (navigation abstraction would be used to go between help files always keeping only one patch open at a time). Attached is Jonathan's abstraction. So, now I started investigating further and it seems that canvas_vis(x,0) closes the patch without any problems and without having to delay anything but this is not enough in and of itself to actually deallocate the actual t_canvas x and other instantiated objects associated with the canvas. So, how could one go about to implement this feature? Ico #N struct 1002-h float x float y; #N struct 1002-p float x float y; #N struct 1002-n float x float y; #N canvas 412 92 649 467 10; #X obj 281 258 f \$0; #X obj 281 185 t b b; #X msg 310 208 clear; #N canvas 450 249 573 425 \$0-p 0; #X obj 40 40 struct \$0-p float x float y; #X obj 40 62 route click; #X obj 40 84 b; #X obj 40 106 outlet; #X obj 42 132 drawpolygon 0 1 0 -7 0 0 1 0 1 -7 5 -7 5 -4 6 -4 6 -6 5 -3 1 -3; #X obj 42 167 drawpolygon 0 1 11 -5 11 -5 8 -5 8 0 9 0 9 -5; #X obj 42 189 drawpolygon 0 1 18 0 18 0 14 0 13 -1 13 -4 14 -1 14 -5 17 -5 17 -3 14 -3 18 -3 18 -4 19 -4 19 -5 20 -5 20 -2 21 -3 21 0 23 0 22 -1 23 -1 23 -3 24 -2 24 -5 25 -5 25 -4; #X obj 42 237 drawpolygon 0 1 27 -7 27 -8 28 -8 28 -7 27 -7; #X obj 42 259 drawpolygon 0 1 27 -5 27 0 28 0 28 -5 28 -5; #X obj 42 281 drawpolygon 0 1 31 -4 31 -1 32 -1 32 -5 35 -5 35 -1 36 -1 36 -4 35 -4 35 0 32 0; #X obj 42 316 drawpolygon 0 1 39 0 39 -5 40 -5 40 0 44 0 44 -5 43 -5 43 0; #X obj 42 338 drawpolygon 0 1 47 0 50 0 50 -1 51 -1 51 -2 48 -2 50 -3 47 -3 47 -4 48 -4 48 -5 51 -5 52 -5; #X obj 42 373 drawpolygon 0 1 0 2 52 2; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 2 0 3 0; #X restore 44 175 pd \$0-p; #N canvas 598 281 534 314 \$0-h 0; #X obj 40 142 drawpolygon 0 1 0 -7 0 0 1 0 1 -7 1 -4 5 -4 5 0 6 0 6 -7 5 -7 5 0; #X obj 40 177 drawpolygon 0 1 9 -4 9 -1 10 -1 10 -5 13 -5 13 -1 14 -1 14 -4 13 -4 13 0 10 0 10 -4; #X obj 40 212 drawpolygon 0 1 17 -5 17 0 18 0 18 -5 21 -5 21 0 22 0 22 -5 25 -5 25 0 26 0 26 -4; #X obj 40 247 drawpolygon 0 1 34 0 29 0 29 -5 32 -5 32 -4 33 -4 33 -3 28 -3 28 -4 28 0; #X obj 40 40 struct \$0-h float x float y; #X obj 40 62 route click; #X obj 40 84 b; #X obj 40 106 outlet; #X obj 40 287 drawpolygon 0 1 0 2 34 2; #X connect 4 0 5 0; #X connect 5 0 6 0; #X connect 6 0 7 0; #X restore 165 175 pd \$0-h; #X msg 44 197 -1; #N canvas 393 226 450 484 navigate 0; #X obj 91 6 inlet; #X obj 91 28 t a b; #N canvas 457 335 450 375 find-this-file 0; #X obj 159 29 inlet; #X obj 159 130 hcs/split_path; #X obj 186 228 f; #X obj 216 228 + 1; #X obj 240 156 sel \$1; #X obj 132 270 f; #X obj 159 53 t b b; #X msg 328 81 0; #X obj 159 103 t a b; #X obj 132 292 outlet; #X obj 332 138 t a; #X obj 332 116 list prepend; #X obj 332 282 outlet; #X obj 108 54 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 159 81 hcs/folder_list ./*.pd; #X connect 0 0 6 0; #X connect 1 1 4 0; #X connect 2 0 3 0; #X connect 3 0 2 1; #X connect 3 0 5 1; #X connect 4 0 5 0; #X connect 5 0 9 0; #X connect 6 0 14 0; #X connect 6 1 7 0; #X connect 7 0 2 1; #X connect 8 0 1 0; #X connect 8 1 2 0; #X connect 10 0 11 1; #X connect 10 0 12 0; #X connect 11 0 10 0; #X connect 13 0 14 0; #X connect 14 0 8 0; #X connect 14 0 11 0; #X restore 118 50 pd find-this-file; #X obj 235 235 list; #X text 272 234 all path/files; #X obj 91 101 +; #X msg 157 288 symbol \$1; #X obj 130 198 t b a; #X obj 157 310 hcs/split_path; #X msg 157 265 set symbol \, adddollar \$1; #X obj 91 123 moses 1; #X obj 130 145 moses; #X obj 157 103 list length; #X obj 157 125 + 1; #X obj 210 413 pack s s s; #X obj 267 310 loadbang; #X obj 267 332 symbol \$1; #X msg 210 435 \; pd-\$3 menuclose 1 \; pd open \$2 \$1; #X obj 52 150 sel; #X obj 52 71 sel 0; #X msg 52 98 1; #X obj 60 123 == 1; #X connect 0 0 1 0; #X connect 1 0 19 0; #X connect 1 1 2 0; #X connect 2 0 5 1; #X connect 2 0 21 0; #X connect 2 1 3 1; #X connect 2 1 12 0; #X connect 3 0 6 0; #X connect 5 0 10 0; #X connect 6 0 8 0; #X connect 7 0 3 0; #X connect 7 1 9 0; #X connect 8 0 14 0; #X connect 8 1 14 1; #X connect 9 0 6 0; #X connect 10 1 11 0; #X connect 11 0 7 0; #X connect 12 0 13 0; #X connect 13 0 11 1; #X connect 14 0 17 0; #X connect 15 0 16 0; #X connect 16 0 14 2; #X connect 18 1 7 0; #X connect 19 0 20 0
[PD] pd-l2ork 20111122 now available
In the spirit of Thanksgiving, DISIS/L2Ork is pleased to announce yet another release of pd-l2ork. Recent fixes include: 2011-11-22 *Ability to move/resize red GOP rectangle via GUI *Allowed GOP-enabled objects to be resized lower than what the default nlet spacing allows *Limit GOP resizing to the size of the text (if hidetext is not enabled on GOP-ed objects) 2011-11-15 *Fixed bug where "Save As" did not always add .pd extension to the file *Base path (for open/save dialog) is now updated when opening file from the command line to the directory of the file being opened 2011-11-13 *fixed graph-on-parent enable/disable does not activate undo/redo on the parent window (or the gop-ed patch unless it is open) *improved verifyquit mechanism to accomodate abstractions *fixed bug where hide text value was not properly interpreted by the canvas apply redo/undo *fixed stray stderr tcl/tk errors 2011-11-11 *Reenabled universal copy/paste (forgot to uncomment some parts) *Universal copy/paste also resizes the canvas as per original script 2011-10-25 *Fixed a monster segfault bug that occurred when using toggling graph-on-parent and cut in succession (usually in combination with undo/redo). 2011-10-24 *Added undo/redo for creating new objects For additional info please see the Changelog at: http://l2ork.music.vt.edu/data/pd/Changelog Download from: http://l2ork.music.vt.edu/main/?page_id=56 We can be also found on git (thanks to Deba and Hans for all the help!) at: https://github.com/pd-projects/pd-l2ork Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) i...@vt.edu http://www.music.vt.edu/faculty/bukvic/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Detecting audio drop outs inside a patch
I. On Sat, 2011-12-10 at 23:55 -0500, Mathieu Bouchard wrote: > Le 2011-12-09 à 09:24:00, Roman Haefeli a écrit : > > > Is there a way to detect DSP drop outs in a patch, respectively to get > > the information that is displayed in the Pd main window? > > If you have an unused channel in a [dac~] that has many outputs, play an > [osc~] in it, and connect the output back to an input so that you can pick > it up by [adc~], so that pd can listen to its own dropouts, using [env~] > or [bonk~] or whatever. I suppose that this has to be done using a cable > that goes outside of a physical soundcard and back inside. If you are using JACK then this does not require any cords and is trivial (provide you know JACK ;-) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] pd at startup creates 2 canvases, why?
I guess this is primarily for devs: The title says it all. When pd starts up, it does 2 instances of canvas_new() calls. More interestingly, it does not do canvas_free for those two instances when closing pd, suggesting this is a memory leak. So, what gives? Why does it create 2 invisible canvases, what is their function, and how do they differentiate from the regular canvases. NB: Not sure if this makes any difference but this is pd-l2ork code based on pd-extended... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd at startup creates 2 canvases, why?
> They contain templates for arrays. > > [; pd-_float vis 1; pd-_float_array vis 1 ( > > > More interestingly, it does not do canvas_free for > > those two instances when closing pd, suggesting this is a memory leak. > > So, what gives? Why does it create 2 invisible canvases, what is their > > function, and how do they differentiate from the regular canvases. > > They aren't listed in the "Window" menu. But like any other canvas, you > can send them objects and messages: > > [; pd-_float obj 20 20 keyname, obj 20 80 print > all_your_keys_are_belongs_to_us, connect 1 1 2 0 ( OK, so that explains why they are created. However, this does not answer the question why they are not being destroyed when exiting pd. Neither canvas_free nor glist_free are triggered when quitting pd, so this must be a memory leak, no? Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd at startup creates 2 canvases, why?
> The OS releases all the memory allocated by the process when it > terminates, so no. OK, however, in pd-l2ork I am currently building infinite undo which will be a doubly-linked list linked to a canvas. So, if I am going to instantiate it dynamically, once the program exits are all these dynamic things taken care of? I think not. Otherwise, why would we need destructors in the first place if the os takes care of it all (other than eventually running out of memory)? Even vanilla canvas has dynamically allocated list that is destructed upon closing the patch but this is not the case with the two invisible canvases... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd at startup creates 2 canvases, why?
On Sun, 2011-12-11 at 14:27 -0500, Ivica Ico Bukvic wrote: > > The OS releases all the memory allocated by the process when it > > terminates, so no. > > OK, however, in pd-l2ork I am currently building infinite undo which > will be a doubly-linked list linked to a canvas. So, if I am going to > instantiate it dynamically, once the program exits are all these dynamic > things taken care of? I think not. Otherwise, why would we need > destructors in the first place if the os takes care of it all (other > than eventually running out of memory)? Even vanilla canvas has > dynamically allocated list that is destructed upon closing the patch but > this is not the case with the two invisible canvases... By dynamic list in vanilla canvas I am referring here to the glist (a list of objects). ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd at startup creates 2 canvases, why?
> it does. > if it does not, file a bug report at your operating system. > I stand corrected. So, the next question is, is it considered "good coding practice" to explicitly call destructors, or is this one of those quod libet kinds of things? > > Otherwise, why would we need > > destructors in the first place if the os takes care of it all (other > > because destructors are not only called at the end of the application life. > > afaik, the only problem is, if your application locks some "shared" > system ressource, and cannot free it again (e.g. it writes a lockfile to > the filesystem, but cannot delete it if the dtor is not called on exit) > > fgamsdr > 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] ANN: pd-l2ork Holiday release now available
Greetings fellow FOSS/Audio enthusiasts, It is my great pleasure to announce pd-l2ork 20111215 a.k.a. Holiday release. In the latest version of Linux Laptop Orchestra's in-house version of Pure-Data we've squashed a number of lingering bugs, as well as added some exciting new features, including: *infinite undo that covers all editing actions (while some externals with custom dialogs may require minor adjustment to their code to work with the newfound undo, most of them will work out-of-box). *more robust paste from external clipboard. copying pd scripts from an email and pasting them directly into a canvas has never been easier. *multiple entry bug that has been plaguing pd for years has been finally squashed. *resizing GOP window via gui (just like the rest of iemgui objects). *a number of usability improvements in terms of pasting logic and other editing features (e.g. gop resize via gui now prevents users to make it smaller than its text size unless hidetext is enabled, objects are automatically resized (except for gop objects with hidden text for obvious reasons) to accommodate adequate spacing for inlets and outlets, etc.) *all known graph-on-parent redraw issues have been addressed and gop redrawing is now as robust as it has ever been. *and many more... (see Changelog and git logs for more detailed info) If interested, head to http://l2ork.music.vt.edu/main/?page_id=56 to download 32-bit builds, source, and more. Alternately, visit our git page at https://github.com/pd-l2ork For more info on L2Ork and pd-l2ork look us up at http://l2ork.music.vt.edu or join us on facebook at http://www.facebook.com/groups/l2ork/ Happy Holidays! Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] ANN: pd-l2ork Holiday release now available
On Dec 16, 2011, at 11:41, Jonathan Wilkes wrote: > - Original Message - > >> From: Ivica Ico Bukvic >> To: pd-list@iem.at; pd-...@iem.at; l2ork-...@disis.music.vt.edu; >> pik...@piksel.no; linux-audio-u...@lists.linuxaudio.org; >> linux-audio-annou...@lists.linuxaudio.org; >> linux-audio-...@lists.linuxaudio.org >> Cc: >> Sent: Friday, December 16, 2011 1:00 AM >> Subject: [PD-dev] ANN: pd-l2ork Holiday release now available >> >> G reetings fellow FOSS/Audio enthusiasts, >> >> It is my great pleasure to announce pd-l2ork 20111215 a.k.a. Holiday >> release. In the latest version of Linux Laptop Orchestra's in-house >> version of Pure-Data we've squashed a number of lingering bugs, as well >> as added some exciting new features, including: >> >> *infinite undo that covers all editing actions (while some externals >> with custom dialogs may require minor adjustment to their code to work >> with the newfound undo, most of them will work out-of-box). > > Great! > >> >> *more robust paste from external clipboard. copying pd scripts from an >> email and pasting them directly into a canvas has never been easier. > > Does "pd scripts" mean a patch's source code? Yes! > >> >> *multiple entry bug that has been plaguing pd for years has been finally >> squashed. >> >> *resizing GOP window via gui (just like the rest of iemgui objects). > > That's very handy. > >> >> *a number of usability improvements in terms of pasting logic and other >> editing features (e.g. gop resize via gui now prevents users to make it >> smaller than its text size unless hidetext is enabled, objects are >> automatically resized (except for gop objects with hidden text for >> obvious reasons) to accommodate adequate spacing for inlets and outlets, >> etc.) >> >> *all known graph-on-parent redraw issues have been addressed and gop >> redrawing is now as robust as it has ever been. >> >> *and many more... (see Changelog and git logs for more detailed info) >> >> If interested, head to http://l2ork.music.vt.edu/main/?page_id=56 to >> download 32-bit builds, source, and more. Alternately, visit our git >> page at https://github.com/pd-l2ork >> >> For more info on L2Ork and pd-l2ork look us up at >> http://l2ork.music.vt.edu or join us on facebook at >> http://www.facebook.com/groups/l2ork/ >> >> Happy Holidays! >> >> Best wishes, >> >> Ico >> >> >> ___ >> Pd-dev mailing list >> pd-...@iem.at >> http://lists.puredata.info/listinfo/pd-dev >> ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-1 test7 (!) available
Miller, If you look through the pd-l2ork C code, which is by and large near identical (at least in its core) to pd vanilla (except for comments I added while studying the code) you will find a few places where mainly due to the way pd handles GOP it is easier to simply catch a tcl/tk command than go through all the trouble of making sure the call is sane. The rest of the code contains a series of sanity checks I added and as such spews no tcl/tk warnings or errors. I suspect this would be trivial to merge with your code base. Best wishes, Ico Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Mathieu Bouchard wrote: Le 2011-12-26 à 14:33:00, Miller Puckette a écrit : > I read the thread on the bug tracker. It looks like this is an old bug > that manifests itself worse in 0.43 because its error recovery for > TCL commands coming from Pd isn't as good as 0.42 was. What you need is not as much error recovery as error reporting. Do whatever is necessary so that future bug reports are easier to make. For example, when a Tcl command fails, print the command that directly caused that error, even when -d is set to 0. > Unless someone knows how to make a tcl interpreter ignore errors when > executing scripts I don't know how to return to the more fail-soft 0.42 > way. Isn't that what the [catch] command already does ? But if anything prevents an item from being created, this will necessarily cause more errors later, for any tcl command that assumes that the creation command worked. _ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC_ 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
Re: [PD] [PD-announce] pd 0.43-1 test7 (!) available
For the few catches I do use, I don't do any follow-up simply because those have been proven (at least so far) not to cause any problems down the line so like I mentioned they were the few cases where it was easier to catch than to hunt for a way to check for their sanity. Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Jonathan Wilkes wrote: Do you throw an error if catch catches something? -Jonathan >_____ > From: Ivica Ico Bukvic >To: Mathieu Bouchard ; Miller Puckette >Cc: pd-list@iem.at >Sent: Tuesday, December 27, 2011 12:45 AM >Subject: Re: [PD] [PD-announce] pd 0.43-1 test7 (!) available > > >Miller, > >If you look through the pd-l2ork C code, which is by and large near identical >(at least in its core) to pd vanilla (except for comments I added while >studying the code) you will find a few places where mainly due to the way pd >handles GOP it is easier to simply catch a tcl/tk command than go through all >the trouble of making sure the call is sane. The rest of the code contains a >series of sanity checks I added and as such spews no tcl/tk warnings or >errors. I suspect this would be trivial to merge with your code base. > >Best wishes, > >Ico > >Ivica Ico Bukvic, D.M.A >Composition, Music Technology >Director, DISIS Interactive Sound & Intermedia Studio >Director, L2Ork Linux Laptop Orchestra >Assistant Director, CCTAD >Virginia Tech >Department of Music >Blacksburg, VA 24061-0240 >(540) 231-6139 >(540) 231-5034 (fax) >disis.music.vt.edu >l2ork.music.vt.edu >ico.bukvic.net > > >Mathieu Bouchard wrote: >Le 2011-12-26 à 14:33:00, Miller Puckette a écrit : >> >>> I read the thread on the bug tracker. It looks like this is an old bug >>> that manifests itself worse in 0.43 because its error recovery for >>> TCL commands coming from Pd isn't as good as 0.42 was. >> >>What you need is not as much error recovery as error reporting. Do >>whatever is necessary so that future bug reports are easier to make. For >>example, when a Tcl command fails, print the command that directly caused >>that error, even when -d is set to 0. >> >>> Unless someone knows how to make a tcl interpreter ignore errors when >>> executing scripts I don't know how to return to the more fail-soft 0.42 >>> way. >> >>Isn't that what the [catch] command already does ? >> >>But if anything prevents an item from being created, this will necessarily >>cause more errors later, for any tcl command that assumes that the >>creation command worked. >> >>>>_ >> >>| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC >>_ >> >>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] New snapshot of pd-l2ork available -- feedback appreciated
Fellow pd enthusiasts and devs, Apart from a couple of fixes of bugs that surfaced after we implemented infinite undo last month, as of this evening pd-l2ork has added another important feature: moving gop-ed objects via tag. This means that even a 10-point array will now be moved via gui with a single command with minimal changes to the core pd code, rather than redrawing the entire array every time the array is moved. Same goes for GOP objects and scalars. Needless to mention, this is the first time that my netbook allows me to move large arrays on screen as if they were simple objects :-) If interested, check out the git at https://github.com/pd-l2ork x86-64 and i386 builds coming up soon... I am uploading 64-bit builds as I type this, i386 should be up sometime tomorrow. In the meantime you can search older builds via L2Ork's website at http://l2ork.music.vt.edu/main/?page_id=56... Enjoy! Best wishes, -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI and DSP
Mathieu Bouchard wrote: >Le 2012-02-08 à 11:55:00, Jonathan Wilkes a écrit : > >> While technically correct that's misleading because there's a lot of >> stuff happening on the 'pd' side that a reasonable person would >assume >> to be handled on the 'pd-gui' side. Well, more than that-- there's >> stuff happening on the 'pd' side that doesn't need to happen at all, >but >> it can use massive amounts of CPU and consequently a reasonable >person >> gets dropouts when moving an array that has only 100 points visible >and >> erroneously thinks, "Wow, I get dropouts just moving some polygons >> around on the screen? Tk stinks!" Or you could simply use pd-l2ork and a move arrays and other complex graphical user interface objects using tags and never worry about that problem again. >Besides, you could save some cpu, ram and bandwidth if all those array >floats were hex-encoded instead of dec-encoded. Don't use "%g" nor "%d" > >when you can use "%x" and similar... especially fixed-width %x such as >"%04x". > >If Tcl had fast base64 support (like Perl/Ruby), the difference would >be >even bigger. And it would bigger with the ability to send binary data >(which can't happen now because "}" counts as end-of-block). > > __ >| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, >QC___ >Pd-list@iem.at mailing list >UNSUBSCRIBE and account-management -> >http://lists.puredata.info/listinfo/pd-list Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: [PD-dev] New snapshot of pd-l2ork available -- feedbackappreciated
Hi Patrice, As I already replied to you off-list you need 2 things: 1) development libraries for compiling the app (which should be unnecessary if you are using Linux as there are prebuilt binaries) 2) you need a linux machine as currently pd-l2ork may not work well (or at all) on non-Linux platforms mainly because its pd.tk file needs to be cleaned-up of Linux-centric widgets. Hope this helps! > -Original Message- > From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf > Of Patrice Colet > Sent: Thursday, February 09, 2012 11:19 PM > To: pd-list > Subject: [PD] Fwd: [PD-dev] New snapshot of pd-l2ork available -- > feedbackappreciated > > > Hello, > > I've tried to run makefile.mingw but it ends up (after a clean ^^) with > these error messages: > > s_inter.c:83:22: fatal error: execinfo.h: No such file or directory > compilation terminated. > s_audio.c:18:26: fatal error: sys/resource.h: No such file or directory > compilation terminated. > x_misc.c:23:23: fatal error: sys/times.h: No such file or directory > compilation terminated. > x_list.c:15:20: fatal error: alloca.h: No such file or directory > compilation terminated. > make: *** [makefile.dependencies] Error 1 > > it seems the compiler is calling linux headers for reasons I don't really get, > I don't really have time to go further. > > Colet Patrice > > - Mail original - > > De: "Ivica Ico Bukvic" > > À: pd-list@iem.at, pd-...@iem.at > > Envoyé: Jeudi 26 Janvier 2012 07:08:35 > > Objet: [PD-dev] New snapshot of pd-l2ork available -- feedback > appreciated > > > > Fellow pd enthusiasts and devs, > > > > Apart from a couple of fixes of bugs that surfaced after we > > implemented > > infinite undo last month, as of this evening pd-l2ork has added > > another > > important feature: moving gop-ed objects via tag. This means that > > even a > > 10-point array will now be moved via gui with a single command > > with > > minimal changes to the core pd code, rather than redrawing the entire > > array every time the array is moved. Same goes for GOP objects and > > scalars. Needless to mention, this is the first time that my netbook > > allows me to move large arrays on screen as if they were simple > > objects :-) > > > > If interested, check out the git at https://github.com/pd-l2ork > > > > x86-64 and i386 builds coming up soon... I am uploading 64-bit builds > > as > > I type this, i386 should be up sometime tomorrow. In the meantime you > > can search older builds via L2Ork's website at > > http://l2ork.music.vt.edu/main/?page_id=56... > > > > Enjoy! > > > > Best wishes, > > > > -- > > Ivica Ico Bukvic, D.M.A > > Composition, Music Technology > > Director, DISIS Interactive Sound& Intermedia Studio > > Director, L2Ork Linux Laptop Orchestra > > Assistant Director, CCTAD > > Virginia Tech > > Department of Music > > Blacksburg, VA 24061-0240 > > (540) 231-6139 > > (540) 231-5034 (fax) > > disis.music.vt.edu > > l2ork.music.vt.edu > > ico.bukvic.net > > > > > > ___ > > Pd-dev mailing list > > pd-...@iem.at > > http://lists.puredata.info/listinfo/pd-dev > > > > ___ > 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
Re: [PD] wiimote report
Try disis_wiimote (http://l2ork.music.vt.edu/main/?page_id=56). We use it as the core controller inside L2Ork with over dozen machines in the same room and it has been rock solid for over 2 years. It is multithreaded so sending rumble/led messages back to Wiimote does not block Pd. It is also driven by metro so you can decide the granularity of updates. Supports MotionPlus, etc. Wii Fit support can be added I just didn't bother with it yet but it shouldn't be too hard... > -Original Message- > From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf > Of u...@xdv.org > Sent: Friday, February 10, 2012 9:48 AM > To: pd-list@iem.at > Subject: Re: [PD] wiimote report > > to answer my question: > i changed onoff from int to float and it works such that i can turn > reports on and off. > > it still crashes a lot though ... > well, seems like i should go for supercollider/osc. or is there another > wii external for linux? > > thanks+ciao, > ub > > it still crashes a lot though, especially with > > On 09.02.2012 12:34, u...@xdv.org wrote: > > can someone help me understand, what's going on here? > > > ___ > 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
Re: [PD] wiimote report
Roman Haefeli wrote: >On Fri, 2012-02-10 at 15:48 +0100, u...@xdv.org wrote: >> to answer my question: >> i changed onoff from int to float and it works such that i can turn >> reports on and off. >> >> it still crashes a lot though ... >> well, seems like i should go for supercollider/osc. or is there >another >> wii external for linux? > >Yeah, there is also [disis_wiimote] [1] from the L2ork project. > >Since the the wiimote external you were trying is the one that is also >included in Debian as pd-wiimote, I think it's worth focusing on fixing >this one, since a lot of people would potentially benefit from it. >Could >you provide a patch for your fix? and why couldn't a lot of people benefit from the disis_wiimote? it is open source and it's just a matter of packaging it for a specific distro. > >> it still crashes a lot though, especially with > >With what? > >Roman > > > >[1] http://l2ork.music.vt.edu/main/?page_id=56 > > >___________ >Pd-list@iem.at mailing list >UNSUBSCRIBE and account-management -> >http://lists.puredata.info/listinfo/pd-list Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
> Why have two wiimote objects? Is there a specific reason why they can't > be merged? If we pool the work on it we'll have one better wiimote > object versus two different wiimote objects that are both less good. Do you mind elaborating why you believe both objects are "less good" in and of themselves? IMO disis_wiimote is much more robust than the wiimote object (at least the last time I tested) in every respect and provides entirely xrun-free functionality. If we agree the aforesaid statement is true (not that I am suggesting that you do agree) then it is not that both are less good but rather the one is better than the other literally in every respect which should in theory make the whole process of selection a lot simpler. Also, suggested pooling may not be always the best approach, particularly if there is limited transparency in terms of how such process is managed (which BTW I think is the core reason why pd-l2ork and disis_wiimote exist in the first place, and consequently why pd community at large is having trouble with the uptake). Also, let us not forget that at the very core of the open-source idea is the "survival of the fittest" model (with a caveat, however; read * below). This means if one external works better than another, it will simply supersede its operation, particularly if their output is essentially the same. Renaming it (or using other practical alternatives to "pooling"), provided credit is given where credit is due, is at this point irrelevant and should be considered synonymous to pooling, particularly in this case where disis_wiimote AFAIK does everything wiimote does except it does it in a way that is (IMO) more robust** *Of course, any dev has every right to continue to maintain their own version for whatever reason and thus defy the context of the survival of the fittest regardless whether they are maintaining one of the "fittest" or less "fit" versions. Also, obviously everyone is entitled to their own definition of what constitutes "fittest" iteration... **Based on 2.5+ years of experience of having a bunch of students with no prior Linux/PD experience messing with the system, including the wiimote external. I hope others would agree that the object's stability is best tested when used by others than the developer who usually focuses on aspects that best cater to their own needs and that may not be always as all-encompassing to cover all use cases. Thus, the greatest collection of instabilities will surface through third-party use. The same is true for pd as a whole... Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
> while i appreciate your work with pd-l2ork, i think it would be great if > you would be trying to get the fixes into "upstream" (where you forked > from). I did, but many fixes never got anywhere (we had this discussion a while ago), and while in the early days I spent most of my time providing additional documentation to Hans and others and making arguments on why they should be accepted which resulted in less than dozen fixes in the first year out of which only a few actually made it upstream, I am now running a fork that has 200+ improvements and fixes in approx. the same amount of time and have arrived at a rock-solid system* and have no interest in going back to a platform that may be stable on release and crash in another. Sure, I am missing a few novel features, but if the current version caters to my (perhaps somewhat specific) needs, there is no reason to go back. FWIW, Hans has started taking some of our patches and merging it upstream (e.g. magicglass that I ported and cleaned up that has been sitting on the sourceforge database for over half a decade untouched) which is great and I would love to see the rest of it there as well. It is just that this way Hans will have to review it (which is something he would have to do anyhow), and merge it at his discretion, rather than me having to spend copious amounts of time to promote adoption of such patches and providing context that is difficult to make unless one spends some time studying the issue on their own... *based on experiences from ongoing L2Ork rehearsals involving dozen or more networked performers. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
Not really, there are a bunch of features pd-l2ork has that pd and pd-extended dont have and even more bugfixes. Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net "András Murányi" wrote: Well, what I understand is that pd-l2ork has already been synthesised as a pile of patches over pd 0.42. If I'm getting it right, disis_wiimote could be too, but is not yet, go on git as a set of patches over a certain version of wiimote, which would open the possibility to merge patches upstream. I don't know however if it's in anyone's interest to actually do it. András ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI and DSP
JUCE is amazing in terms of gui speed-up. Just check out bundled demos that come with the sdk... Half of Gem could be easily reimplemented using JUCE sdk... Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Jonathan Wilkes wrote: - Original Message - > From: Mathieu Bouchard > To: Jonathan Wilkes > Cc: Hans-Christoph Steiner ; Ivica Ico Bukvic ; > "pd-list@iem.at List" > Sent: Saturday, February 11, 2012 11:59 AM > Subject: Re: [PD] GUI and DSP > > Le 2012-02-10 à 20:09:00, Jonathan Wilkes a écrit : > >> For me the create-delete method uses more CPU but both are pretty > intensive. Any Qt devs out there? Or gtk'ers? Maybe a JUCEr? Would those > toolkits be able to utilize the GPU? Those would be nice to compare, too. > > In the end, switching toolkits wouldn't be a bad idea, but it's not the > only solution. Some things inside of tk could be improved. Modifying tk can > be > scary, more so if we have to think seriously about bundling alpha versions of > tk > 8.7 together with pd-extended, but the alternative is to rewrite large > amounts > of code (everything using sys_gui or implicitly referring to Tcl), which is > error-prone, hard to test, and too many changes in one chunk. > > So, it's not very clear to me which one is best. > > I had tried making some changes to Tk 8.5, and it seemed somewhat promising. > I > was getting large speedups for some cases, and large slowdowns for some other > cases. With more work, the latter could have been eliminated. It would > benefit > most other uses of Tk Canvas in other apps as well, so it could be integrated > to > Tk itself. Do you still have any of those changes you made to Tk? If so, how do they compare to unpatched Tk when running Hans' array-demo? -Jonathan > >_ > | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: [PD-dev] New snapshot of pd-l2ork available -- feedback appreciated
> Thanks a lot! > > Ivica, what about using this for backtrace? > > http://code.google.com/p/backtrace-mingw/ It is not necessary. It is a matter of making sure you use proper build system. The current code should build just fine on Windows (although I never tried it) as its build system is based on Pd-extended which also builds for Windows. The problem does not lie therefore in backtracing but rather revamping pd.tk to circumvent fixes and improvements that do not take into account OSs other than Linux. Some work has been already done with this in the early days when I was working on having these improvements submitted upstream. Also, understand that while pd.tk is on paper one version behind latest 0.43 tcl implementation, it also has plenty of improvements that do not exist in 0.43, so in some respects is ahead of curve (but is also behind in terms of code-cleanliness). At some point those may have to be reconciled (likely once 0.43 branch is rock solid tcl-wise (which may be already the case), I find enough time to do this, and a reason to do it). Hope this helps! Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
> Yeah, no doubt that disis-wiimote has been well tested. I'm just > highlighting different cases. I know a couple projects that needed 6 > wiimotes connected to 1 computer, where I think L2Ork does one > wiimote per computer. Now, it would be good to rely on a single object > to handle all cases. Good point. We only did as many as 2 per computer. Then again, I cannot imagine why more would not work other than hardware/driver limitations that have nothing to do with the external. > Just to illustrate this point, pd-l2ork is based on Pd-extended, which > includes the work of over 100 people. Any of those chunks of work would > be much less valuable without the rest. There is additional work just to > make all those chunks of work into one, of course. Indeed. Some of those chunks are my own spread across Pd, Gem, and other externals. Please don't get me wrong, I would love to see all these changes integrated into one uniform package but the key stepping stone to this is that pd/extended (unlike pd-l2ork) is trying too hard to maintain binary compatibility. I see no benefit in that when the core design is still a moving target. Besides, some of the early architectural choices have been undoubtedly less than optimal as it was difficult if not impossible to anticipate ways pd would evolve and yet they to this day continue to hamper progress. This is why pd-l2ork can do things that pd or pd-extended cannot without *major* code rewrites. Of course, major code rewrite is the ideal way but also one that is very unlikely to happen unless someone is paid to do just that for a year or two (which again is not the most likely thing). So, iterative improvements seem to me the most plausible way for a project like Pd to move forward and that is exactly what I am doing. However, due to the core difference in opinion as to how this should be approached (namely binary compatibility) makes merging pd-l2ork and pd/extended difficult if not impossible without considerable adaptations to the patches themselves and/or architectural choices. For me to spend time on those differences or worse yet guess what those architectural choices might mean to Miller or you would be just as inefficient as it was early on when I was submitting patches upstream. And this is why I leave such decisions/merging efforts to Miller and you. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI and DSP
> Well, yes, I have them, but it's not very relevant, as I already know that > those changes make Pd really worse in too many cases. > > The interface common to all item-types has a function to return one > bbox > (bounding-box : x1 y1 x2 y2). It is assumed that the whole bbox has to be > redrawn whenever any aspect of the item has changed. For long > diagonal > lines, this means a damn lot of stuff that isn't even close to the line. > I didn't change this. > > Then this info is centralised as a single bbox that tells which part of > the canvas to redraw. There's only one. In my diff, I replace this by a > grid each representing a 8x8 or 32x32 zone, I don't remember what > precise > size. But that was all, and this caused draw-commands to be duplicated > many times the way I did it, because I drew each zone separately with a > clipmask. There would have been other ways to reduce the waste, some > involving redrawing multiple zones at once in the grid system, and some > involving handling multiple bboxes at once and merging them into > something > that is not a bbox. > > I also had other ideas, such as making items modify the grid instead of > returning a bbox, which would greatly speed up things like diagonal lines > and perhaps pd's arrays (any item in which the bbox has a much greater > area than the item). I think a lot of this would be alleviated for the most part if not entirely if: 1) pd completely removed redrawing logic from the c code and migrated it into tcl (which is what you may have done in great part already inside desire-data) 2) pd used a different toolkit that allowed for more intelligent addressing of individual gui components (again, JUCE IMO comes at the very top here) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: [PD-dev] New snapshot of pd-l2ork available -- feedback appreciated
> -Original Message- > From: Mathieu Bouchard [mailto:ma...@artengine.ca] > Sent: Sunday, February 12, 2012 12:27 PM > To: Ivica Ico Bukvic > Cc: 'Patrice Colet'; 'pd-list' > Subject: RE: [PD] Fwd: [PD-dev] New snapshot of pd-l2ork available -- > feedback appreciated > > Le 2012-02-12 à 12:22:00, Ivica Ico Bukvic a écrit : > > > (but is also behind in terms of code-cleanliness). > > Do you mean something else than sprinkling colon-colon namespacing > all > over the source and splitting it over N files ? Not really. But there are also some foundational changes how some of those basic functions operate. Otherwise, porting everything to the new version would be a breeze. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
> I thought I saw a comment in your code that said it only handled one > controller. > > -Jonathan It's been a while since I edited the source and/or tested more than one wiimote per computer. It may be just a leftover comment. Also, I think this is in part because each wiimote would have its own instance (one wiimote object per connection, which makes sense from the visual perspective). Let me investigate and I'll let you know... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
> -Original Message- > From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf > Of Ivica Ico Bukvic > Sent: Sunday, February 12, 2012 2:00 PM > To: 'Jonathan Wilkes'; 'Hans-Christoph Steiner' > Cc: 'pd-list' > Subject: Re: [PD] wiimote report > > > I thought I saw a comment in your code that said it only handled one > > controller. > > > > -Jonathan > It's been a while since I edited the source and/or tested more than one > wiimote per computer. It may be just a leftover comment. Also, I think this > is in part because each wiimote would have its own instance (one > wiimote object per connection, which makes sense from the visual > perspective). Let me investigate and I'll let you know... Just checked the code and it seems at some point I hardwired it to only one wiimote at a time. I changed a MAXWIIMOTES define to support up to 16 (which is a completely arbitrary number I haven't tested), recompiled it, and it connected 2 without problems. I suspect it will connect many more before hardware/drivers gives out... Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
> Cool. I guess the other question is this: does the threading stuff in your > class solve > a problem with dropouts that still exists in the other wiimote class? Can > you put > together a demo patch that would cause dropouts on the old wiimote > class before > you revised it, but which doesn't cause dropouts in your revised wiimote > class? Then > someone using the other wiimote class can test to see if they get > dropouts. (Unfortunately > I don't have a wiimote so I can't test.) I can guarantee there are no dropouts since this is what L2Ork does at all times. disis_wiimote always runs in the same pd instance as the audio parts and does not require clumsy things like two instances of pd running concurrently. This is because elements that may cause dropouts (namely things that are sent back to wiimote, like rumble and LED; rumble is used extensively in L2Ork) are run in a separate thread. So, the only time you could potentially get dropouts is if the patch has maxed out cpu which is an entirely different issue... > Also, could the person who has six wiimotes test with Ivica's class and see > if there are > dropouts? I can easily test this at the next rehearsal. But I think the more important question is whether that would make any difference. In other words, are the wiimote maintainers interested in merging disis_wiimote functionality. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI and DSP
On 02/12/2012 06:10 PM, Hans-Christoph Steiner wrote: I think a lot of this would be alleviated for the most part if not entirely if: 1) pd completely removed redrawing logic from the c code and migrated it into tcl (which is what you may have done in great part already inside desire-data) 2) pd used a different toolkit that allowed for more intelligent addressing of individual gui components (again, JUCE IMO comes at the very top here) I agree. I think a lot of this can be done incrementally. Basically, take a chunk of logic and refactor it so that Tcl/Tk handles the GUI stuff and pd sends pd messages rather than lines of Tcl. One example of where that could be done is the key press/release handling code. Right now, there is a lot of code for this in g_canvas.c. It is possible that the tag/move code could also be done this way. .hc Moving by tag requires a major rewrite on c side of things or reimplementation of widgetbehavior as is the case with pd-l2ork. This is mainly because there are some actions that simply require absolute positioning while others can work through relative positioning (e.g. creating vs. moving). This is why pd-l2ork uses expanded version of widgetbehavior and now is capable (through an iterative improvement) of moving by tag pretty much everything (albeit at the expense of binary compatibility, which IMO is not a problem when pd-l2ork pretty much packages most of additional externals with it and others can be simply recompiled with no changes to the source, with the exception of gridflow that uses unusual approaches to deal with GUI matters). ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
> I can easily test this at the next rehearsal. But I think the more important > question is whether that would make any difference. In other words, are > the wiimote maintainers interested in merging disis_wiimote functionality. OK, so studied the wiimote structure and decided to adopt its output model for disis_wiimote to streamline interoperability between the two. This means I adopted dynamic number of wiimotes, removed reliance on cwiid_internal.h, and included single data outlet model with prepended descriptors. I added also multidongle operation even though I did not test it. I did test 3 wiimotes connected to the same computer (single bluetooth interface--I think there was a scientific research done a while ago that said up to 8 of them can be done reliably on a single bt interface, but that of course in part depends on the quality of the said interface) and will test 6 later tonight. So far no audio dropouts (other than when connecting a wiimote due to the way cwiid is structured) even when using rumble/settled options (those are the ones that cause most problems anyhow). You can try new disis_wiimote from the L2Ork's software page. It does rely on the latest cwiid git snapshot which is also mirrored on the page below: http://l2ork.music.vt.edu/main/?page_id=56 One curious thing is that it appears that cwiid can only do 2 continuous streams (accelerometer + expansion, accelerometer + ir, or ir + expansion, never all three; buttons always work). I saw that someone did try to enqueue messages in the other version of wiimote external but that should have no effect as this is something that comes from cwiid and I suspect it is the way how hardware works... I did contact the original cwiid dev to hear their thoughts and am awaiting his response. In the meantime, if anyone has any thoughts on this I would love to hear them. Cheers! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
On Thu, 2012-02-16 at 15:09 -0500, Ivica Ico Bukvic wrote: > > I can easily test this at the next rehearsal. But I think the more important > > question is whether that would make any difference. In other words, are > > the wiimote maintainers interested in merging disis_wiimote functionality. So, I just tested the system with 4 wiimotes and it worked without any xruns. I could not connect the 5th one not because of Pd but rather limitations of the bluetooth chip in a netbook. I suspect a better computer would allow for more connections and/or use of 2 bluetooth dongles... Hope this helps! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
> I just tested that with the [wiimote] from pd-svn and it seems I can > have three continuous streams going at the same time (though the > update > rate seems to lower). I enabled accelerometers, IR and motionplus and > got updates on all three. Is it really a limitation by cwiid, then? > > Roman Cwiid demos (e.g. wmgui) exhibit the same limit of 2 streams which suggests it is indeed a problem with cwiid. To clarify my observation, while you do get "updates" on all three, one of them is frozen (does not change values but just outputs the same over and over). ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
On 02/17/2012 03:42 PM, Roman Haefeli wrote: What version of libcwiid are you running? I tried both wiimote and disis_wiimote and both are limited by the same limitation. It appears there may have been some kind of a regression in libcwiid if the older version works fine. Sorry, I meant to say, this is with version 0.6.00+svn201 of libcwiid. Which version are you using? Latest git checkout (svn has older version, if it even exists any more). ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
On 02/17/2012 01:27 PM, Roman Haefeli wrote: On Fri, 2012-02-17 at 11:31 -0500, Ivica Ico Bukvic wrote: I just tested that with the [wiimote] from pd-svn and it seems I can have three continuous streams going at the same time (though the update rate seems to lower). I enabled accelerometers, IR and motionplus and got updates on all three. Is it really a limitation by cwiid, then? Roman Cwiid demos (e.g. wmgui) exhibit the same limit of 2 streams which suggests it is indeed a problem with cwiid. To clarify my observation, while you do get "updates" on all three, one of them is frozen (does not change values but just outputs the same over and over). Again, this is not the case with [wiimote]. I tested the following setups: * accelerometers, IR, motionplus * accelerometers, IR, classic controller All three sensors are updated frequently (I was wrong when I claimed it got significantly slower; this was due to having the Pd GUI be shown in a VNC session). This doesn't work: * accelerometers, motionplus, classic controller It seems, you cannot use two extensions at the same time. It's either motionplus or classic controller, but not both at the same time. Note: This is with 0.6.00+svn201 (in Ubuntu 11.04), probably this matters? AFAICT, [wiimote] from svn does _not_ use a local version of cwiid.h. Another note: I experience the same behaviour with wmgui: It only lets me display two stream simultaneously and it lacks a section for motionplus. Roman OK, I finally figured it out. It seems that the RPT_EXT call is not working properly any more as it invokes all known extensions and this results in failed enabling of the extension. OTOH if one explicitly enables external they wish to use (eg. RPT_NUNCHUK), then all is well... I just fixed this in the disis_wiimote. That said, after further study of wiimote.c I would conclude it has progressed considerably since I last checked it and it poses code legibility advantages over disis_wiimote. Where it still falls short is it causes unnecessary xruns when sending changes to the report mode, setLED and setRumble, particularly on weaker cpus (e.g. atom netbooks), even if using a real-time kernel. It would be therefore perhaps a good idea if someone considered merging disis_wiimote's threaded design plus its ability to be driven by a metro, rather than outputting data as quickly as possible (which seems in many cases unnecessary and may result in redundant ways of slowing down such a stream, e.g. using speedlim kinds of workarounds). Cheers! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
explicitly enables external they wish to use (eg. RPT_NUNCHUK), then all is well... I just fixed this in the Ugh, too tired... that should've been "extension," not an "external" last checked it and it poses code legibility advantages over disis_wiimote. Where it still falls short is And that should've been "offers" instead of "poses"... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] ANN: L2Ork Tour
Apologies for cross-posting as well as for a bit belated announcement. It is that time of the year and L2Ork is getting ready for our first mini-tour of the 2012 with following performances and presentations: February 19th @5pm - University of Maryland Baltimore County February 20th @12pm - Rutgers University February 21st @12pm - Temple University February 21st @2:30pm - A talk at Community College of Philadelphia Hope you can join us at one of our destinations! For additional info: http://l2ork.music.vt.edu Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) i...@vt.edu http://www.music.vt.edu/faculty/bukvic/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd 0.43-2 test 1 released
> > unfortunately not entirely (i could only test the git version (rev: > > bb91ad26e16), due to my bad internet connection). > > > > i still get a tcl error, when trying to change the number of items > > of an [hradio] in a closed subpatch [1]. > > > > see attached patch that illustrates the problem. > > > > it would be great if this minor annoyance could somehow be fixed. You may want to try out pd-l2ork's version of iemgui objects that in addition to offering resize/move hooks also take care of unnecessary redraws. I suspect merging those source files with core pd should be relatively seamless as they've been for the most part edited as independent entities. Cheers! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] ANN: pd-l2ork 20120226 snapshot now available
This release includes following fixes: *MyCanvas does not become invisible if it is partially visible in GOP mode *copy-paste from console does not work with the ctrl+c shortcut *Proper focusing out of the selection (where typing into .printout console makes problems for textedfor objects) *Resizing window when text is hidden still prevents resizing below the text size *GOP resize hooks should be visible only if no object is selected *when re-saving prototype abstraction it disappears on the parent canvas *disis_wiimote does not re-detect motion plus every time when re-connecting and re-enabling the extension (partially fixed (needs update to libCwiid, will be updated soon)--for the time being, easiest thing is to enable extension twice; NB: this will not be necessary once the libCwiid is updated) *image and other non-vanilla objects do not translate with the GOP *ggee objects button and image updated, gcanvas disabled as it has too many bugs to be worth fixing (IMO) *implemented gop legacy redraw *selection as part of the infinite undo (for those tricky selections that take a while to do and can be messed up with a single mis-click) NB: ctrl+a is currently ignored, mainly because it is easy to do but will be likely addressed in the next release L2Ork now also supports builds for both 32-bit and 64-bit Linux systems and can be downloaded from the usual place: http://l2ork.music.vt.edu/main/?page_id=56 Bug reports are in high demand, so get busy and let me know of any potential hiccups. -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork 20120226 snapshot now available
> Any chance of these fixes being submitted upstream? These two in > particular seem useful and probably easily applicable: Not really. Please see below: > > *image and other non-vanilla objects do not translate with the GOP This is because pd-l2ork moves GOP objects by tag (as of sometime in January), including arrays and scalars, which makes moving them vastly faster. This change is gargantuan and requires widgetbehavior to be expanded by one additional call. This latest addition simply makes sure that the system falls back on the old erase/redraw whenever gop is moved in case one of its displayed objects does not support the added widgetbehavior (this was the case with non-gop objects but now gop is supporting the same fallback method as well and thus ensuring that all properly working legacy objects are supported). So, no, porting this upstream means a lot more changes than just this. It also does not affect upstream since it does not support moving gop objects by tag. > > *ggee objects button and image updated Ditto for this one as it also includes aspects that incorporate the aforesaid widgetbehavior. Long story short, the fundamental question is whether the core pd devs are conducive to the idea of overhauling g_canvas.h and breaking binary compatibility which is the only way you'll get these kinds of changes in without rewriting a lot more than what has gone into this (which is already a pretty decent chunk). Best wishes, Ico > > .hc > > On Feb 26, 2012, at 8:52 PM, Ivica Ico Bukvic wrote: > > > This release includes following fixes: > > > > *MyCanvas does not become invisible if it is partially visible in GOP > mode > > *copy-paste from console does not work with the ctrl+c shortcut > > *Proper focusing out of the selection (where typing into .printout > console makes problems for textedfor objects) > > *Resizing window when text is hidden still prevents resizing below the > text size > > *GOP resize hooks should be visible only if no object is selected > > *when re-saving prototype abstraction it disappears on the parent > canvas > > *disis_wiimote does not re-detect motion plus every time when re- > connecting and re-enabling the extension (partially fixed (needs update > to libCwiid, will be updated soon)--for the time being, easiest thing is to > enable extension twice; NB: this will not be necessary once the libCwiid is > updated) > > *image and other non-vanilla objects do not translate with the GOP > > *ggee objects button and image updated, gcanvas disabled as it has > too many bugs to be worth fixing (IMO) > > *implemented gop legacy redraw > > *selection as part of the infinite undo (for those tricky selections that > take a while to do and can be messed up with a single mis-click) NB: > ctrl+a is currently ignored, mainly because it is easy to do but will be > likely > addressed in the next release > > > > L2Ork now also supports builds for both 32-bit and 64-bit Linux systems > and can be downloaded from the usual place: > > > > http://l2ork.music.vt.edu/main/?page_id=56 > > > > Bug reports are in high demand, so get busy and let me know of any > potential hiccups. > > > > -- > > Ivica Ico Bukvic, D.M.A > > Composition, Music Technology > > Director, DISIS Interactive Sound& Intermedia Studio > > Director, L2Ork Linux Laptop Orchestra > > Assistant Director, CCTAD > > Virginia Tech > > Department of Music > > Blacksburg, VA 24061-0240 > > (540) 231-6139 > > (540) 231-5034 (fax) > > disis.music.vt.edu > > l2ork.music.vt.edu > > ico.bukvic.net > > > > > > ___ > > Pd-list@iem.at mailing list > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > > Looking at things from a more basic level, you can come up with a more > direct solution... It may sound small in theory, but it in practice, it can > change entire economies. - Amy Smith ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork 20120226 snapshot now available
> Great! One question: what is "implemented gop legacy redraw" about? Great question. Since January pd-l2ork by default moves gop/array/scalar groups of objects via tag. In layman terms this means instead of having to redraw entire gop object every time it is moved even by one pixel (e.g. dragging gop with mouse would generate dozens of these events per second), moves it all with a single tcl command. This newly implemented feature however did not account for objects that do not support moving by tag (mainly 3rd party gui externals that do not have moving by tag implemented). This has made gop displacing with such objects embedded not work properly for the said objects. So, now if you have a gop object that also includes one of the said 3rd party gui externals, it falls back gracefully to the old way of redrawing the gop object which is terribly inefficient but at least it works seamlessly for both cases. >From L2Ork's perspective, we use almost exclusively built-in iemgui objects >for all our needs with the ggee/image being one notable exception that has >been also updated and cleaned-up for this release, including support for >moving with tag. To give you some perspective just what kind of a difference this makes performances-wise, make a gop object that has iemgui/vanilla objects only, and then create another with the ggee/button object (for instance) and observe the difference. For a really fun experience try running pd-l2ork with -d 1 debugging enabled to see the console printout difference. Hope this helps! P.S. if there is an exhaustive list of 3rd party gui externals and their breakdown between those that are well supported and those that are not, this would be particularly helpful as I could then try to tackle them one-by-one until they've all been revamped. NB: text objects and other 3rd party externals that don't have custom guis are supported out-of-box even prior to the aforesaid fix. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
The new release includes following fixes: *tooltips (partially based on Jonathan Wilkes's implementation) that appear in form of speech bubbles next to the object they relate to. Reliable detection of objects. Also works with gop objects. *major overhaul of the font resizing dialog/logic--font resizing made simple (everything scales proportionately except for gui objects whose properties obey user-set settings) *font-based zoom using ctrl+mousewheel *font resizing integrated in the infinite undo *hslider/vslider instead of possibly corrupting data due to its values tied to the drawing logic output unaltered data where possible (e.g. float values that fall within the range of the slider) *minor cosmetic improvements to hslider/vslider *several minor bug-fixes *hslider and vslider redraw their slider properly when resized *Minor build/documentation improvements *Removed selection as part of the undo queue as it vastly limits ability to use infinite undo's potential L2Ork supports builds for both 32-bit and 64-bit Linux systems and can be downloaded from the usual place: http://l2ork.music.vt.edu/main/?page_id=56 On a related note, disis_wiimote has been bumped to version 0.8.0. It now supports automatic detection of all extensions including motionplus. New l2ork version of libcwiid required (also available on the same page). Coming up in the next release (hopefully!) soon, support for pass-through mode (e.g. motionplus + nunchuk). As usual, bug reports are in high demand, so get busy and let me know of any potential hiccups. Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
> Sounds great. I'll try it out in a bit. > > Just curious-- if I send [tip 1 Hello Canvas( to a canvas, where on the > canvas does the tooltip appear? > > -Jonathan Next to the cursor. We can alter that if this proves to be unintuitive. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
> Well, I personally prefer the "status bar" approach than tooltips that nestle > up next to > my mouse-- that's why I always printed out the tooltip at the bottom of > the patch (or > at the top if the user is mousing at the bottom). This is basically the > Firefox > approach > seen when you mouse over a link on a web page and a little label > appears at the bottom > right of the patch (or bottom left, depending on where your mouse is). > > However, I think I combined two related features that may not belong > together: > 1) tooltips > 2) canvas tips > > Even though it's not my preference, your tooltip placement seems to > work well and is > probably the clearest placement for the new user (who will probably > benefit most from > using them). No problem, I can make the canvas tips appear at the bottom whereas all others will appear in place. This has been already fixed in the newest version I am currently building (20120305). > > Btw-- one thing I notice is that a) I can generate a tip for the object itself > while the inlet > appears highlighted, and b) once I generate an inlet tip, if I move the > mouse horizontally > to the right the inlet will continue to be highlighted even though the > mouse is no longer over > it. The nlet highlighting is "magnetic" by default to allow for easier patching. I can however see how this could be distracting in terms of object tip "trumping" the nlet tip. Part of this I suspect is toolkit's limitations because tcl/tk's "current" tag inside canvas is rather crude and not necessarily very useful within the context of Pd patching (e.g. when you click on an outlet, "current" tag is stuck to whatever you've clicked even if you are dragging a mouse to another nlet, which means there is no way to highlight nlets when patching). 20120305 version that is currently building now does all the binding logic inside c code and things run a lot smoother. Cheers! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
...please note that some file links on the webpage don't work (because the file naming scheme has been altered). Oops, thanks for the bug report! Will fix that shortly (and while at it I am already uploading 20120305 version which makes tooltips even more robust) Zooming is cool! There are, however, some objects which don't scale appropriately - the red GOP box is one. (See attached screenshot) That is because GOP objects are of user-selected size, just like iemgui objects (which also do not resize for the same reason). Font based zooming simply changes font sizes and repositions all objects to be still in the same relation to each other. True zooming (ala desiredata), while desireable (no pun intended) is at this point IMO too much work for too little gain. Entire internals need to be addressed because the object mapping and selection logic is split between the toolkit and c which makes the entire thing a nightmare. I think this is a good compromise that should work in the interim. I am also convinced that instead of having one monolithic pd that can do both editor and headless operation, we really need 2 instances. One that is based essentially off of libpd and another that is a robust editor with none of the convoluted client server model between the editor and the engine itself that has made improving on the code so cumbersome Hope this helps! András ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] ANN: pd-l2ork v.20120306 bug-fix release now out
A few minor bugs crept into the new tooltip implementation, so 20120306 version is now out. Tooltips now support both dockable behavior for the manual tooltips and cursor-centric text bubbles for dynamic tooltips. Also, all the shortcomings of tcl/tk's Enter/Leave events has been circumvented by using C implementation of tooltips. Other improvements include scalable fonts, removal of redundant tooltips, and correct offset calculation for objects. http://l2ork.music.vt.edu/main/?page_id=56 Pd-l2ork can be also found on git at https://github.com/pd-l2ork Cheers! Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] tooltips in pd-extended 0.43
> I think that we should be pushing GUI stuff to the Tcl side of things as > much as possible, plus I prefer the current tooltip display down on the > lower right. I find that popups right next to the mouse are often annoying. I agree, except I don't want to push this notion to the point where unpredictable nature of tcl/tk's canvas implementation entirely hampers or limits tool's productivity and provides a half-baked feature. E.g. it's impossible to highlight nlets or show tooltips when trying to patch a cord because tcl/tk's canvas keeps "current" tag on the object that was last clicked on, and yet arguably this is where a new user needs tooltips the most. Selection of nlets and their detection is finicky at best, is very unforgiving (you really need to nail that pixel on the screen to get it), and the list goes on. Also, the status bar tooltips are really not very intuitive and from the HCI perspective represent a considerable increase in cognitive load over text bubbles because one's eyes have to move at times relatively far from the point with which the tooltip is associated (heck, it is not even that obvious to which object it belongs to if there are two objects located near the cursor). Even a long arrow from an object to a status bar tooltip can cause a considerably higher cognitive load than a co-located tooltip. There is a reason why co-located tooltips exist even in browsers in addition to the somewhat arcane status bar model. The only context where I see the status bar approach as the optimal way to display tooltips is when the tooltip emanates from a manual invocation that Jonathan pointed out earlier where it makes perfect sense to post it in one uniform place that is not dependent on the mouse position and thus potentially misleading. Best wishes, ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] tooltips in pd-extended 0.43
> Even better, off load this to a GUI plugin, then people can choose the > method that works best for them. But I still like Jonathan's original > implementation the best. While there may be "better," neither of them will be best when one relies on the Tcl/tk's implementation that delivers inconsistent results (which is BTW yet another frustrating form of cognitive load whose scope is significantly larger than either of the ones discussed below). > > I find that the slightly increased load of moving my eyes down to the > lower left corner a worthy sacrifice for not being interrupted by a popup > bubble. Interruptions also increase cognitive load, and should be > reserved for things that are the most important. One's interruption, is other person's expectation. If I have tooltips enabled, I am expecting them to pop-up. Whether they do that in the bottom left corner or next to my cursor is irrelevant in terms of cognitive overhead associated with a pop-up action itself, except that one that is not co-located bears additional workload akin to that of shifting your gaze away from the road to check on your cell phone who is calling... > > Most of the time, most users will not need the popup describing the inlet, > so most of the time it'll just be an interruption. In my experience, I found that new users really need that guidance. If not, they can always turn the pop-up off. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] some observations and questions on Pd-ext 0.43.1 beta
_ From: Marco Donnarumma [mailto:de...@thesaddj.com] Sent: Friday, March 09, 2012 7:45 AM To: pd-list@iem.at Cc: Ivica Ico Bukvic Subject: Re: [PD] some observations and questions on Pd-ext 0.43.1 beta (sorry to quote but this will keep the conversation on the list..) Thanks Ivica, it makes sense to try this out. I should have thought about it yesterday. The student and her machine are gone now, but I'll write her and ask to try this out. I still wish to know if anybody is experiencing something similar to better understand the issue. Can't try on my machine 'cause I've got 10.04 and don't wanna change it or alter it by now. This is the exact version of Ubuntu we use in L2Ork (FWIW). On my testing machine I also use 11.10 so I can confirm that pd-l2ork runs on both just fine as long as you have supporting libs (identical to pd-extended). Pd-l2ork also installs in a separate folder from pd-extended/pd so there should be no problems. The only thing you may need to check is /usr/local/lib/pd-l2ork/defaults.pdl2ork (or whatever its name is) and make sure to exclude /usr/local/lib/pd folder in case you use that for other versions of pd as you don't want to mix externals from the two versions (it will cause crashes). Best wishes, Ico Will keep you updated, best, Marco ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] tooltips in pd-extended 0.43
On Mar 12, 2012, at 13:00, Mathieu Bouchard wrote:
> Le 2012-03-06 à 21:04:00, Ivica Ico Bukvic a écrit :
>
>> I agree, except I don't want to push this notion to the point where
>> unpredictable nature of tcl/tk's canvas implementation entirely hampers or
>> limits tool's productivity and provides a half-baked feature.
>
> I found Tk to be quite predictable...
>
>> E.g. it's impossible to highlight nlets or show tooltips when trying to
>> patch a cord because tcl/tk's canvas keeps "current" tag on the object that
>> was last clicked on,
>
> ... but then I never tried using a tag named "current". Here's a relevant
> piece of DesireData :
Both of my comments refer to the implementation that is currently in Pd-ext vs.
what I have come up with.
Also, what you're suggesting is essentially doubling the work that is already
done inside C (again, assuming that one simply applies what you are proposing
to the existing C code). C code already has getrect function that takes care of
things like fuzzy logic, particularly when trying to connect a cord to an inlet
where code already selects nearest inlet (at least it does in pd-l2ork).
I do understand that moving this into tcl/tk domain is ultimately a good thing
as it strives toward separation of the GUI from the engine. However, since I am
particularly interested in making sure that even interim solutions are as
robust and as possible, I decided to alter the system to rely on the C
implementation as that has proven to be a more robust (or perhaps I should say
more complete and less redundant) approach than the original version.
In addition, and I think I may have already pointed this out earlier, FWIW I am
also not convinced that having one system serve both headless runtime mode and
network-based GUI editor is a good thing, particularly now that we have libpd.
I am much more interested in having direct GUI implementation plus a separate
(and if need be GUI-less) runtime client, as dealing with networked GUI has
been a huge overhead for the pd-dev community both in terms of implementing new
features as well as fixing existing bugs. If one agrees with this approach,
then spending time on migrating things into tcl/tk domain may not be the time
best spent...
>
> def Canvas identify_target {x y f} {
>set c [$self widget]
>set cx [expr $x*$@zoom]
>set cy [expr $y*$@zoom]
>set stack [$c find overlapping [expr $cx-2] [expr $cy-2] [expr $cx+2]
> [expr $cy+2]]
># reversing the stack is necessary for some things
># not reversing the stack is also necessary for some other things
># we have to figure out something.
>set stack [lreverse $stack]
>set target ""
>foreach tag $stack {set target [$self target $x $y $f $tag]; if
> {[llength $target] > 1} {break}}
>if {[llength $target] > 1} {return $target} {return [list "nothing"]}
> }
>
> def Canvas target {x y f tag} is a much longer method, which looks at tags of
> a canvas-item to figure out where it comes from.
>
>> and yet arguably this is where a new user needs tooltips the most. Selection
>> of nlets and their detection is finicky at best, is very unforgiving (you
>> really need to nail that pixel on the screen to get it), and the list goes
>> on.
>
> In that code, I detect using a square of 5x5 pixels in size, where $cx $cy is
> the centre of it. This allows fuzzier detection. This is not necessarily the
> best solution, but that's what we came up with.
>
> __
> | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array resize : bug?
FWIW this has been fixed in L2Ork but only for the newly created arrays.
Opening old patches requires resizing them as they are saved incorrectly in the
patch.
Best wishes,
Ico
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Director, CCTAD
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net
Jonathan Wilkes wrote:
- Original Message -
> From: katja
> To: pd-list@iem.at
> Cc:
> Sent: Friday, March 16, 2012 6:35 PM
> Subject: Re: [PD] Array resize : bug?
>
> On Fri, Mar 16, 2012 at 10:35 PM, Pierre Massat
> wrote:
>> Hi Katja,
>>
>> I confirm this behaviour in windows too. So I understand that the actual
>> number of samples is the same, the only difference being that they all fit
>> within the GOP frame when resized by a message, whereas the last sample is
>> out of the frame when the size is set upon creation.
>>
>> Should I report a bug? Or is there a reason to this?
>
> Oops, seems I responded off-list by accident.
>
> The initial situation with the last sample outside the frame is
> annoying, I guess this could be reported as a bug.
In 0.43.1-extended-20120201 at least, it is definitely a bug. When you create
an
array with, say 10 elements, the last one extends 20 pixels outside of the gop
box!
-Jonathan
>
>>
>> 2012/3/16 katja
>>>
>>> Hello Pierre,
>>>
>>> With Pd-extended 0.42.5 for OSX it's similar to your description.
>>> However, when resizing to a low size like 10, and manually counting
>>> the number of 'sliders', it can be verified that the correct
> number of
>>> points is visually represented.
>>>
>>> Katja
>>>
>>>
>>> On Fri, Mar 16, 2012 at 6:05 PM, Pierre Massat
> wrote:
>>> > Dear list,
>>> >
>>> > I've just noticed a strange behaviour of arrays in Pd-extended
> 0.42.5
>>> > running in Win XP.
>>> > When I manually create an array and set it's size through its
> properties
>>> > (right-click, etc.), say, to 44100 samples, the range on the X
> axis is 0
>>> > to
>>> > 44099. Fine.
>>> > Now when I resize it by sending it a message ("array1 resize
> 44100"),
>>> > the X
>>> > axis now spans from 0 to 44100 (that is 44101 samples).
>>> >
>>> > Anybody noticed this in other versions/platforms?
>>> >
>>> > Cheers,
>>> >
>>> > Pierre.
>>> >
>>> >_
>>> > 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
Re: [PD] Array resize : bug?
Could you direct us to the fix?
I don't have the info handy-this has been something I did long before git
(IIRC), but I think it is noted on the pre-Git changelog which means you could
easily track it with a diff between those releases. It was either inside
g_graph.c or g_array.c but there might be other source files involved as well.
HTH
.hc
On Mar 16, 2012, at 7:15 PM, Ivica Ico Bukvic wrote:
FWIW this has been fixed in L2Ork but only for the newly created arrays.
Opening old patches requires resizing them as they are saved incorrectly in the
patch.
Best wishes,
Ico
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Director, CCTAD
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu <http://disis.music.vt.edu/>
l2ork.music.vt.edu <http://l2ork.music.vt.edu/>
ico.bukvic.net <http://ico.bukvic.net/>
Jonathan Wilkes wrote:
- Original Message -
> From: katja
> To: pd-list@iem.at
> Cc:
> Sent: Friday, March 16, 2012 6:35 PM
> Subject: Re: [PD] Array resize : bug?
>
> On Fri, Mar 16, 2012 at 10:35 PM, Pierre Massat
> wrote:
>> Hi Katja,
>>
>> I confirm this behaviour in windows too. So I understand that the actual
>> number of samples is the same, the only difference being that they all fit
>> within the GOP frame when resized by a message, whereas the last sample is
>> out of the frame when the size is set upon creation.
>>
>> Should I report a bug? Or is there a reason to this?
>
> Oops, seems I responded off-list by accident.
>
> The initial situation with
the last sample outside the frame is
> annoying, I guess this could be reported as a bug.
In 0.43.1-extended-20120201 at least, it is definitely a bug. When you create
an
array with, say 10 elements, the last one extends 20 pixels outside of the gop
box!
-Jonathan
>
>>
>> 2012/3/16 katja
>>>
>>> Hello Pierre,
>>>
>>> With Pd-extended 0.42.5 for OSX it's similar to your description.
>>> However, when resizing to a low size like 10, and manually counting
>>> the number of 'sliders', it can be verified that the correct
> number of
>>> points is visually represented.
>>>
>>> Katja
>>>
>>>
>>> On Fri, Mar 16, 2012 at 6:05 PM, Pierre Massat
> wrote:
>>> > Dear list,
>>> >
>>> > I've just noticed a strange behaviour of arrays in Pd-extended
> 0.42.5
>>> > running in Win XP.
>>> > When I manually create an array and set it's size through its
> properties
>>> > (right-click, etc.), say, to 44100 samples, the range on the X
> axis is 0
>>> > to
>>> > 44099. Fine.
>>> > Now when I resize it by sending it a message ("array1 resize
> 44100"),
>>> > the X
>>> > axis now spans from 0 to 44100 (that is 44101 samples).
>>> >
>>> > Anybody noticed this in other versions/platforms?
>>> >
>>> > Cheers,
>>> >
>>> > Pierre.
>>> >
>>> >
_
>>> >
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
"A cellphone to me is just an opportunity to be irritated wherever you are." -
Linus Torvalds
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
[PD] ANN: pd-l2ork v.20120317 now available
This release includes backported font-sizing logic, minor improvements to the tooltips engine, and a couple of cosmetic bug-fixes. For a complete list of changes please see the pd-l2ork git changelog (https://github.com/pd-l2ork). L2Ork supports builds for both 32-bit and 64-bit Linux systems and can be downloaded from the usual place: http://l2ork.music.vt.edu/main/?page_id=56 As usual, bug reports are in high demand, so get busy and let me know of any potential hiccups. -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120317 now available
> Great-- the fonts look right in Debian Wheezy now. > Good to hear :-) You should've reported this earlier--I did not know this was an issue until I tried Ubuntu 12.04 beta :-) > One question, though-- given that the optimal patch-zooming > functionality is not possible with Tk without a lot of work, would > it be better to actually resize any iemguis in the patch? They > all have methods for setting the size, and it wouldn't change the > functionality of the objects. Well, I did some thinking about this and here's what I've come up with so far: Since iemgui objects are customized as "gui" objects, they should be treated separately from the rest of the font matters since they are indeed treated as such when it comes to editing/integrating them into a gui. This is particularly true for tight GOP objects that would go entirely out of whack unless we implement a truly global zoom rather than just a font change. So, this would be an argument for not touching them. On the other hand, this is not entirely true as they do pull current font size at creation time but do not react to latter changes (so this is definitely argument in favor of what you are proposing). So, I am a bit torn on them for the time being as changing them would mess everything else up (e.g. aforesaid GOP objects), but on the other hand there is a precedent for them being adjustable. For this reason, I am simply imagining that at some point down the road the font sizing will be replaced by a genuine zoom (which I already implemented from a visual perspective except that I did not account for the object location changes that then mess everything up inside the editor). > > Also, could you map zoom-in to and and zoom-out > to ? Good idea. > > -Jonathan > > > minor improvements to the > > tooltips engine, and a couple of cosmetic bug-fixes. For a complete list > of > > changes please see the pd-l2ork git changelog > (https://github.com/pd-l2ork). > > > > L2Ork supports builds for both 32-bit and 64-bit Linux systems > > and can be downloaded from the usual place: > > > > http://l2ork.music.vt.edu/main/?page_id=56 > > > > As usual, bug reports are in high demand, so get busy and let me know > of any > > potential hiccups. > > > > -- Ivica Ico Bukvic, D.M.A > > Composition, Music Technology > > Director, DISIS Interactive Sound& Intermedia Studio > > Director, L2Ork Linux Laptop Orchestra > > Assistant Director, CCTAD > > Virginia Tech > > Department of Music > > Blacksburg, VA 24061-0240 > > (540) 231-6139 > > (540) 231-5034 (fax) > > disis.music.vt.edu > > l2ork.music.vt.edu > > ico.bukvic.net > > > > > > ___ > > 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
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
(A late) Thanks for the explanation! So am I getting your vision right: to have a sort of 'server' which runs pd patches and an editor which only edits patches and submits them to the server to run? Plus I guess dynamic patching and changes graphical objects' attributes which will make it all more complicated...? András Actually I am thinking more of two separate instances. One is headless server if you like, the other one is fully integrated system/editor that also encapsulates the server. This is because as soon as you start transporting things over a socket, any busy gui stuff, particularly redrawing large arrays, becomes a terribly slow feat. OTOH, the system would still have to be threaded to prevent gui from messing with the engine, so to say. I think this is essentially how Max works but I honestly don't know for sure. HTH Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
> Curiously, I would have said exactly that about your fontsize thing. I > would say that true zooming is the only way to go, and anything else > distracts by creating bigger complications. Well, code-wise it is not. I simply change font size and automate stretch values and don't worry about GOP objects because GOP design is in part conceived around specific pixel size. Resizing them could potentially wreak complete havoc on the organization of visual data inside them. To complicate matters further, tcl/tk treats canvas text differently than canvas objects (vectors), so a true zoom can be never achieved completely accurately. Imagine for instance having an iemgui object that has a label with a font size of 16 and the rest of the patch using font size 10. When you resize things one step up (since you are limited by what font sizes are feasible, meaning zoom factor is restricted to workable font sizes) from 10 to 12, you are still severely limited by tcl/tk--while the increase in 120% can easily translate to vectors using canvas scale call, it does not account for images, or outlier font sizes (120% of a font size 16 is 19.2 and unless I am missing something there is no such font size possible inside tcl/tk). So, I do think this is the most sensible way of dealing with this until pd-l2ork shifts to a different toolkit altogether that is not so font-centric. BTW, Pd-l2ork currently has a way to resize everything that is disabled because resizing of the aforesaid issue, as well as the fact that everything on tcl/tk's side of things does not account for all the changes necessary on C side of things that would require updating each object's location and size and updating its C-based structs that contain that info. This is why in part client-server separation (for the editor) makes little sense when so much of the client is already contained inside the server... > > > we really need 2 instances. One that is based essentially off of libpd > > and another that is a robust editor with none of the convoluted client > > server model between the editor and the engine itself that has made > > improving on the code so cumbersome > > You want to replace the current client-server model by what exactly ? > Most > likely another kind of client-server model ? Yes, but one that does not use sockets to communicate critical data and as such is severely limited in its performance, nor is it severely limited by the toolkit. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
Jonathan Wilkes wrote: >- Original Message - > >> From: Ivica Ico Bukvic >> To: 'Mathieu Bouchard' >> Cc: pd-list@iem.at >> Sent: Tuesday, March 27, 2012 2:32 PM >> Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote >external now available >> >>> Curiously, I would have said exactly that about your fontsize >thing. I >>> would say that true zooming is the only way to go, and anything >else >>> distracts by creating bigger complications. >> >> Well, code-wise it is not. I simply change font size and automate >stretch values >> and don't worry about GOP objects because GOP design is in part >conceived >> around specific pixel size. Resizing them could potentially wreak >complete havoc >> on the organization of visual data inside them. >> >> To complicate matters further, tcl/tk treats canvas text differently >than canvas >> objects (vectors), so a true zoom can be never achieved completely >accurately. >> Imagine for instance having an iemgui object that has a label with a >font size >> of 16 and the rest of the patch using font size 10. When you resize >things one >> step up (since you are limited by what font sizes are feasible, >meaning zoom >> factor is restricted to workable font sizes) from 10 to 12, you are >still >> severely limited by tcl/tk--while the increase in 120% can easily >translate to >> vectors using canvas scale call, it does not account for images, or >outlier font >> sizes (120% of a font size 16 is 19.2 and unless I am missing >something there is >> no such font size possible inside tcl/tk). So, I do think this is the >most >> sensible way of dealing with this until pd-l2ork shifts to a >different toolkit >> altogether that is not so font-centric. > >What does font-centric mean? It means that zoom levels news to be driven by integer font sizes as tcl/tk canvas is incapable of displaying non-int font sizes. This is why the pd object drawing mechanism first queries font width and height to decide how big of a box to draw. It is simply incapable of doing out the other way around. > >> >> BTW, Pd-l2ork currently has a way to resize everything that is >disabled because >> resizing of the aforesaid issue, as well as the fact that everything >on >> tcl/tk's side of things does not account for all the changes >necessary on C >> side of things that would require updating each object's location and >size >> and updating its C-based structs that contain that info. This is why >in part >> client-server separation (for the editor) makes little sense when so >much of the >> client is already contained inside the server... >> >>> >>> > we really need 2 instances. One that is based essentially off of >libpd >>> > and another that is a robust editor with none of the convoluted >client >>> > server model between the editor and the engine itself that has >made >>> > improving on the code so cumbersome… >>> >>> You want to replace the current client-server model by what >exactly ? >>> Most >>> likely another kind of client-server model ? >> >> Yes, but one that does not use sockets to communicate critical data >and as such >> is severely limited in its performance, nor is it severely limited by >the >> toolkit. >> >> Best wishes, >> >> Ico >> >> >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
Jonathan Wilkes wrote: > > > > >- Original Message - >> From: Mathieu Bouchard >> To: Ivica Ico Bukvic >> Cc: pd-list@iem.at >> Sent: Tuesday, March 27, 2012 11:45 AM >> Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote >external now available >> >> Le 2012-03-06 à 00:42:00, Ivica Ico Bukvic a écrit : >> >>> Font based zooming simply changes font sizes and repositions all >objects to >> be still in the same relation to each other. True zooming (ala >desiredata), >> while desireable (no pun intended) >> >> Well, in desiredata, puns were intended. The name was made from >> desiderata, a latin word to allude to todo-lists and wish-lists. >> >>> is at this point IMO too much work for too little gain. >> >> Curiously, I would have said exactly that about your fontsize thing. >I would say >> that true zooming is the only way to go, and anything else distracts >by creating >> bigger complications. > >I don't agree. The pd-extended/vanilla font dialog is good for >choosing an initial >font size, and _nearly_ useless for changing font sizes. Pd-l2ork font >dialog >is good for choosing an initial font size, perfectly fine for changing >font sizes when >normal text objects are all that is in the patch, somewhat useful for >changing font >size in a patch mixed with text objects and iemguis, and only >completely useless >when changing font size for a patch in which only iemguis are visible. But even this is debatable if you consider that the zoom tool is actually a patcher font size change tool (not gui zoom tool) that can be misrepresented as a zoom tool. In this case it makes no sense to resize iemgui objects when they are explicitly designed as gui objects whose properties are adjusted independently of core fonts. This is why also true zooming is impossible to do on tcl/tk canvas that has both vectors and fonts. And this is exactly why I chose not to bother with this feature. > >This isn't just theoretical. I wanted to read a help patch in a larger >font, and on >pd-l2ork I just increased the font size and stretched the patch window >to be >bigger. On pd-extended/vanilla the text objects would have collided >with a bigger >font and would have been illegible. > >-Jonathan > >> >>> we really need 2 instances. One that is based essentially off of >libpd and >> another that is a robust editor with none of the convoluted client >server model >> between the editor and the engine itself that has made improving on >the code so >> cumbersome… >> >> You want to replace the current client-server model by what exactly ? >Most >> likely another kind of client-server model ? >> >> >__________ >> | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, >QC >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hslider/vslider - mismatch of input and output
Indeed, that is the most likely reason. If you have ability/willpower to try pd-l2ork version of hslider/vslider, this problem is solved in that any values that pass through the slider set to linearly scale between specific values remain unaltered (apart from outer edges of the slider). However, any values that result from moving the slider will be adjusted based on the slider's position in respect to the overall slider. HTH Ico On 04/01/2012 07:35 PM, Hans-Christoph Steiner wrote: I think that's because it normalizes the values based on the pixel granularity of the slider. That's just a guess. .hc On Apr 1, 2012, at 7:14 AM, Iain Mott wrote: Hi, I've noticed something strange with hslider and vslider. I you give them a large range, the inputs and outputs aren't always equal or at least they are out by a factor greater than 1. For example with the range 0 - 55000, if you connect a number object to hslider's input and enter 6034, the output reads 6032.68. Couldn't find this reported elsewhere - though perhaps i didn't search hard enough. This result is on linux. Cheers, i ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list "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-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hslider/vslider - mismatch of input and output
The old changelog is only up to the end of the last year (or thereabouts). All the latest changes are a part of the git now and I do believe that there is a mention of the aforesaid fix in there. HTH On 04/02/2012 12:22 PM, Jonathan Wilkes wrote: Nice fix. I don't see it listed in your change log. Is it simple enough to make a patch for the sourceforge tracker? *From:* Ivica Ico Bukvic *To:* Hans-Christoph Steiner *Cc:* pd-list@iem.at *Sent:* Sunday, April 1, 2012 8:11 PM *Subject:* Re: [PD] hslider/vslider - mismatch of input and output Indeed, that is the most likely reason. If you have ability/willpower to try pd-l2ork version of hslider/vslider, this problem is solved in that any values that pass through the slider set to linearly scale between specific values remain unaltered (apart from outer edges of the slider). However, any values that result from moving the slider will be adjusted based on the slider's position in respect to the overall slider. HTH Ico On 04/01/2012 07:35 PM, Hans-Christoph Steiner wrote: > I think that's because it normalizes the values based on the pixel granularity of the slider. That's just a guess. > > .hc > > On Apr 1, 2012, at 7:14 AM, Iain Mott wrote: > >> Hi, I've noticed something strange with hslider and vslider. I you give >> them a large range, the inputs and outputs aren't always equal or at >> least they are out by a factor greater than 1. For example with the >> range 0 - 55000, if you connect a number object to hslider's input and >> enter 6034, the output reads 6032.68. >> >> Couldn't find this reported elsewhere - though perhaps i didn't search >> hard enough. This result is on linux. >> >> Cheers, >> i >> >> >> >> >> ___ >> Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > > > "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-list@iem.at <mailto:Pd-list@iem.at> mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu <http://disis.music.vt.edu> l2ork.music.vt.edu <http://l2ork.music.vt.edu> ico.bukvic.net <http://ico.bukvic.net> ___ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
On 04/09/2012 06:38 PM, Julian Brooks wrote: Apologies for dredging up old posts... Did we ever get one good/merged [wiimote]? Julian Funny you asked. I made several releases of disis_wiimote since, including making it output-compatible with vanilla wiimote. Also, the latest version 0.9.0 has a working passthrough mode (MotionPlus + Nunchuk at the same time). Documentation is still a bit basic regarding this one, but it is also fairly straightforward (basically requires an additional flag called togglePassthrough). This version requires custom L2Ork version of cwiid library (also downloadable from the l2ork site) which has a number of bug fixes and some fundamental changes to the way the code works. NB: this library is not backwards compatible. One of them includes complete auto-detection of extensions without having to deal with separate flags for each of the extensions (with the exception of the passthrough mode since that does some really unusual init things from the hardware perspective that have warranted an entirely new thread in libcwiid to deal with it). AFAIK this is currently the only FOSS implementation that gives you working passthrough support. My hope is to submit cwiid changes upstream soon... http://l2ork.music.vt.edu/main/?page_id=56 Cheers! -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Upcoming DISIS/L2Ork Spring Event
Apologies for cross-posting as well as for the 10-minute notice... DISIS presents "A New Beginning" Digital iD Spring Event - 7:30 pm, Monday, April 30, 2012 - Virginia Tech Squires Studio Theatre As part of the Arts Fusion festival, VT Institute for Creativity, Arts and Technology ( <http://www.icat.vt.edu/> ICAT) and Digital Interactive Sound and Intermedia Studio ( <http://disis.music.vt.edu/> DISIS) presents the "A New Beginning " Spring Showcase, a part of the "Digital iD" performance series featuring an evening of multisensory performances that fit no preexisting form or template. Sponsored by the Institute for Creativity, Arts and Technology and School of Performing Arts & Cinema, and in collaboration with Kids' Tech University, the event will feature performances by guest artists Jillian Harris, Benjamin Knapp, and Gascia Ouzounian, Virginia Tech's <http://l2ork.music.vt.edu/> Linux Laptop Orchestra (L2Ork) and DISIS students. "Digital iD" offers an exploration of synergies among music, technology, arts, gesture, collaboration, interactivity, and ultimately community. <http://www.facebook.com/events/264246753670634/> Facebook Page <http://disis.music.vt.edu/images/main/events/120430_poster.jpg> Official Poster (~500KB 11x17 JPG) <mailto:ico_AT_vt_DOT_edu> Contact Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) i...@vt.edu http://www.music.vt.edu/faculty/bukvic/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ubuntu 12.04 precise pangolin pd-extended 0.43.1 amd64 deb package for download - link included
Does anyone else have a problem with creb/blosc~ not outputting any audio (its signal output is stuck at -0.5 and that's it). This is on 64-bit Ubuntu. The problem affects both pd-extended and pd-l2ork. Any thoughts? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] for ivo - and others - re:mu integration of PD with Unity 3.5?
I presume ivo == ico? ;-) At any rate, the key is using the netsend/netreceive objects and formatting messages the same way as the max patch does. The one thing you won't be able to use is send textures via socket as that is tailored specifcially towards jitter formatting of matrix/texture data. Other than that, it should be straightforward implementation. I also have a version lying around that I never got around to releasing that uses jit.net.send/receive to avoid instabilities of 3rd-party netsend/receive objects (they tend to crash things after a while). This however is not an issue (AFAIK) with pd's versions of the same objects. HTH On 05/03/2012 08:46 PM, Scott R. Looney wrote: hey PD listers, my question is about the use of the mu 1.00 tools from DISIS for use in PD. these tools allow integration of the Unity game engine with Max/MSP and potentially PD according to the authors. i downloaded the demo which is very Max-oriented. is there a plan or sketch or some way of setting up communication with PD instead? i'm also waiting for information on how to use libpd as the sound engine for a Unity project. the developer of the game Fract, Henk Boom, was supposed to detail some bit about this soon, but curious if anyone on the list has ever used PD with the Unity game engine... any advice appreciated... scott ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] for ivo - and others - re:mu integration of PD with Unity 3.5?
On 05/03/2012 09:15 PM, Peter Brinkmann wrote: but I gather that C# bindings are a prerequisite for using libpd with Unity. Hey Peter! Long time no hear. Hope all is well. Regarding Unity and C#. Unity also does seamless integration of java, javascript, C#, boo (python-like language), as well as C (IIRC). Cheers! -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ubuntu 12.04 precise pangolin pd-extended 0.43.1 amd64 deb package for download - link included
On 05/03/2012 09:24 PM, Ivica Ico Bukvic wrote: Does anyone else have a problem with creb/blosc~ not outputting any audio (its signal output is stuck at -0.5 and that's it). This is on 64-bit Ubuntu. The problem affects both pd-extended and pd-l2ork. Any thoughts? Preliminary data suggests it's a 64-bit issue (I just learned Jonathan apparently built the deep note on 32-bit pd-l2ork where it worked just fine). -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] for ivo - and others - re:mu integration of PD with Unity 3.5?
On 05/03/2012 10:42 PM, Scott R. Looney wrote:
sorry Ico (for some reason i though somebody mistyped - i should have
just checked some back
No worries :-)
posts). i didn't think Unity was friendly towards straight C, but yes
to Javascript, C# and Boo.
i'm mainly asking because i'm interested in a way that students can
experience adaptive audio at work in the Unity game environment.
texture sending and receiving is unimportant - it's mainly messages.
so essentially i just redo what i see in the max patch in a generic
way using PD objects. OK will give a port of your test patch a try...
thanks for the info!
No problem! One thing I would suggest is using disis_netsend and
disis_netreceive as using the vanilla netsend/receive objects tends to
crash the gui in situations with heavy network traffic.
i am also intrigued by the possibilities of using PD (libpd) as an
audio middleware engine, ala Fmod or Wwise. ideally something like
Juce on top doing a nice intuitive GUI with drag and drop elements.
the advantage to all this being that it would be free to use and not
have a license fee like the aforementioned do. i've worked a bit with
Fmod and i can envision some alternatives in terms of visual options.
i have zero in the way of coding experience of course, but i think the
game market needs an open source audio engine.
scott
On Thu, May 3, 2012 at 6:30 PM, Ivica Ico Bukvic <mailto:i...@vt.edu>> wrote:
On 05/03/2012 09:15 PM, Peter Brinkmann wrote:
but I gather that C# bindings are a prerequisite for using
libpd with
Unity.
Hey Peter! Long time no hear. Hope all is well.
Regarding Unity and C#. Unity also does seamless integration of
java, javascript, C#, boo (python-like language), as well as C (IIRC).
Cheers!
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound& Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Director, CCTAD
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu <http://disis.music.vt.edu>
l2ork.music.vt.edu <http://l2ork.music.vt.edu>
ico.bukvic.net <http://ico.bukvic.net>
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound& Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Director, CCTAD
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] ubuntu 12.04 precise pangolin pd-extended 0.43.1 amd64 deb package for download - link included
Here's the fix for the 64-bit Linux (and I suspect OSX as well). Change around lines 33 or so: typedef unsigned long long u64; typedef unsigned long u32; To: #ifdef _WIN32 typedef unsigned long long u64; typedef unsigned long u32; #else #include typedef uint64_t u64; typedef uint32_t u32; #endif Cheers! ico On 05/04/2012 04:26 AM, katja wrote: On Fri, May 4, 2012 at 5:14 AM, Hans-Christoph Steiner wrote: Does it does type-punning? Does compilation give warnings about that? That's my guess. [blosc~] does type punning indeed, it uses type unsigned long in phase conversion, blosc~.cc line 86/87. But there is no literal bitmask defined, only a scaling. Not sure if this type punning gives a problem. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Multiline text using [text2d]/[text3d]
With 10 instead of 13 in the message box, it looks fine under ubuntu and pd vanilla. Ditto for pd-l2ork ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] what makes Pd-extended 0.43 so CPU-hungry?
On 05/05/2012 03:58 PM, Jonathan Wilkes wrote: Have you compared with pd-l2ork in Debian? Without doing any direct measurements, I seem to remember the pd-0.43-ext nightly build looking sluggish on my laptop when moving around GUI objects, which I didn't see with pd-l2ork. -Jonathan That is because pd-l2ork does moving of objects using tcl/tk tags which is *much* more efficient than trying to redraw them on every gui update, particularly GOP objects. On my netbook (Atom) things are as smooth as butter because of this, whereas they used to make larger patches literally unresponsive. Cheers! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] what makes Pd-extended 0.43 so CPU-hungry?
Could it be the VU meters embedded in the main window? Those are known to be fairly cpu intensive if updated too often. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] new disis_wiimote : undefined symbol: sys_flushtogui
On 05/07/2012 07:06 PM, Benjah @ 01xy.fr wrote: Hello, while trying to compile the new disis_wiimote with the L2Ork version of CWiid library on ubuntu 10.04 against Pd extended 0.42.5 or Pd 0.43.2, I get "disis_wiimote.pd_linux: undefined symbol: sys_flushtogui" when trying to load the help patch disis_wiimote-help.pd and the object is not created. Any idea why ? Because pd-l2ork exposes this function to externals and default pd doesn't. Current disis_wiimote only works with pd-l2ork and with L2Ork version of CWiid library. In return, it provides features that no other FOSS external can, such as passthrough mode support and xrun-free bidirectional communication. HTH Ico thanks Benjamin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] new disis_wiimote : undefined symbol: sys_flushtogui
On 05/07/2012 07:33 PM, Ivica Ico Bukvic wrote: On 05/07/2012 07:06 PM, Benjah @ 01xy.fr wrote: Hello, while trying to compile the new disis_wiimote with the L2Ork version of CWiid library on ubuntu 10.04 against Pd extended 0.42.5 or Pd 0.43.2, I get "disis_wiimote.pd_linux: undefined symbol: sys_flushtogui" when trying to load the help patch disis_wiimote-help.pd and the object is not created. Any idea why ? Because pd-l2ork exposes this function to externals and default pd doesn't. Current disis_wiimote only works with pd-l2ork and with L2Ork version of CWiid library. In return, it provides features that no other FOSS external can, such as passthrough mode support and xrun-free bidirectional communication. HTH Ico Forgot to mention, if using pd-l2ork is not an option (which it shouldn't be, at least not on Linux since it is 100% backwards compatible), you could comment out the line in the source containing the said call as it is more of a cosmetic thing (it posts message to console before trying to connect, otherwise, the text "press 1 and 2 simultaneously to connect..." due to threaded design ends up being posted after the wiimote has connected. HTH thanks Benjamin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] new disis_wiimote : undefined symbol: sys_flushtogui
> Why do you think that this can only be done by exposing sys_flushtogui()? > My guess is that this can be done using the current public API, but I'd to know > more about the issue to make a concrete suggestion. Indeed... To make any suggestions, like the one below, you would need to look at the external's behavior. In this case, connection is handled in the same thread as pd which means the thread freezes until wiimote connects. Because connection happens immediately after requesting the posting of a message "please press 1+2 buttons on a wiimote to connect" (which I would argue is rather important bit of information for a user), the message never reaches the gui because the thread freezes waiting on the Bluetooth stack to report that the connection has succeeded/failed. Flushtogui placed in between the post() call and the connect() call allows for the said message to be indeed displayed before the pairing takes place. If you can think of a better way to do this I'd certainly appreciate suggestions. As for bidirectionality of communication, this has nothing to do with examples listed below. Rather, on lower-powered cpus (e.g. Atom netbooks) request to enable rumble on a wiimote most of the times results in an xrun. disis_wiimote handles this and other thread-unsafe actions in a separate thread so that one can send as many rumble/led/etc. requests back to wiimote without that having to result in an xrun. > > There are a number of objects that handle bidirectional communication with > hardware and they don't need sys_flushtogui(). [comport] and [hidio] come > to mind. Then there are the network objects, which also handle bidirectional > communication. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] new disis_wiimote : undefined symbol: sys_flushtogui
On 5/11/12 10:24 AM, Hans-Christoph Steiner wrote: On May 10, 2012, at 1:45 PM, Ivica Ico Bukvic wrote: Why do you think that this can only be done by exposing sys_flushtogui()? My guess is that this can be done using the current public API, but I'd to know more about the issue to make a concrete suggestion. Indeed... To make any suggestions, like the one below, you would need to look at the external's behavior. In this case, connection is handled in the same thread as pd which means the thread freezes until wiimote connects. Because connection happens immediately after requesting the posting of a message "please press 1+2 buttons on a wiimote to connect" (which I would argue is rather important bit of information for a user), the message never reaches the gui because the thread freezes waiting on the Bluetooth stack to report that the connection has succeeded/failed. Flushtogui placed in between the post() call and the connect() call allows for the said message to be indeed displayed before the pairing takes place. If you can think of a better way to do this I'd certainly appreciate suggestions. It sounds to me like the issue in the thread programming. Using threads in Pd externals is tricky since the thread has to sync up with Pd, which uses an entirely different kind of scheduling than threads. Yes, and that's in part why options are rather limited as to how to handle this issue. Why not handle the connect in the other thread? Or even better, maybe there is a non-blocking way to do it where [wiimote] registers a callback, then sends the connect message, and carries on normally.. Then once the wiimote finished connecting, cwiid calls the callback in Pd, and Pd registers the wiimote as connected. .hc That would be a lot harder to pull off as the current design is where the secondary thread only receives cues to do things, it does not send anything back. In the design you suggested (and which BTW I already considered before) the secondary thread would also have to return something to the main thread (namely pointer to the wiimote instance as cwiid instantiates wiimote struct and supporting variables at connection and destroys them when the wiimote disconnects). This means either having another entirely independent thread that exits as soon as the wiimote connects returning the object or having some seriously ugly code that tries to notify main thread when the wiimote has been fully instantiated. Between that and exposing one call (which is AFAIK benign to use in this context), I'd call with the exposing the call. Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
Another quick update includes following, mainly cosmetic fixes/improvements: *made iemgui use default $select_color as defined in pd.tk while leaving legacy definition for IEM_GUI_COLOR_SELECTED color (as defined in g_all_guis.h) for other externals that may rely upon it *cleaned up bugs in mycanvas where label did not follow the object *cleaned up segfault on number2 when creating a label *modularized highlight nlet color and width and moved them to pd.tk *changed the way highlight nlet filters different objects and reverts their nlet color properly to original state (e.g. iemgui uses black as default whereas text objects use gray nlets You can grab it from: http://l2ork.music.vt.edu/main/?page_id=56 This way anyone interested in bigger highlight or different default select colors can alter it all from the pd.tk menu (search for $select_color and below color section you'll find also highlight customization options). Now the only remaining thing is to test various externals, which has so far gone quite well, requiring only in some cases (e.g. moonlib/mknob) a recompile of the original external with no changes to their respective sources (typically those who rely upon core .h files that may have changed slightly, namely g_canvas.h and g_all_guis.h). NB: m_pd.h and m_imp.h have remained unchanged. Cheers! Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Fri, 2010-11-26 at 21:26 -0500, Ivica Ico Bukvic wrote: > Another quick update includes following, mainly cosmetic > fixes/improvements: > > *made iemgui use default $select_color as defined in pd.tk while leaving > legacy definition for IEM_GUI_COLOR_SELECTED color (as defined in > g_all_guis.h) for other externals that may rely upon it > *cleaned up bugs in mycanvas where label did not follow the object > *cleaned up segfault on number2 when creating a label > *modularized highlight nlet color and width and moved them to pd.tk > *changed the way highlight nlet filters different objects and reverts > their nlet color properly to original state (e.g. iemgui uses black as > default whereas text objects use gray nlets > > You can grab it from: > http://l2ork.music.vt.edu/main/?page_id=56 Ugh, 20101127 is now out fixing two regressions. Namely, 1) segfault due to the way iemgui's implementation of universal color did not allocate proper memory for the char array 2) stale GOP elements due to incorrect check for an open window This latest snapshot should be considered 1st release candidate. Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
On Sat, 2010-11-27 at 15:36 +0100, Martin . wrote: > Hi, > I'd like to test this. Can I install it alongside my other pd > installation or will installing this take over other installations of > pd-extended? > > If it is possible, how do I go about doing this? > > cheers, > martin See one of the early correspondences in this thread. Namely, you can simply download the tarball and recompile it (if necessary--it does come with i386 version precompiled) by doing aclocal; autoconf; ./configure (with flags); make; (do not do "make install"). Then you can simply go to pd/bin directory and run ./pd from there to test things out. Other way you could do it is to pass a --prefix command to ./configure script so that the pd is installed elsewhere. This however does not resolve the problem of the executable having the same name (if you already have another version of pd installed). All that said, I am using this version in L2Ork's production environment with 16 netbooks and am very pleased with it (although a slew of changes/additions I've done over the past week may need additional testing). NB: Some externals may require a recompile due to changes to some of the .h files. No source changes should be necessary, however, for such a recompile to be successful. HTH Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
> > I think I'll take a stab at this one soon. > > Before you do, you should ask Miller what exactly his comments mean in: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1056914&group_id=55736&atid=478072 > > Also see: > > http://sourceforge.net/tracker/index.php?func=detail&aid=2838176&group_id=55736&atid=478072 > Interesting. What I am missing in this patch is a prototype tooltip entries (the symbol). Are there any examples of this? Also what is not clear to me from the patch file itself is whether the tooltip is per-object or per-nlet. Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Compiling pd-extended externals
Hans, I just finished recompiling externals using L2Ork iteration of Pd, according to the script that came with the Pd-extended's externals/ folder. It appears with the "make install" command all externals have been built inside the build/lib/pd/extra (with doc/) folders. Is this now simply a matter of copying these over into the /usr/lib/pd/extra and doc folders respectively or is there another step in between? Please advise. Many thanks! Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
This looks like an incompatibility between tagged moving of an object and something in the gridflow. Does this occur with any object or just some specific object(s)? Mathieu, The offending call should be the same like the Regular call except that is this place is using a tag. It can be found in the g_text.c file. Cheers! ALAN BROOKER wrote: >Hi Mathieu, > >Thanks for this, I have done a trace back with the following output on the >terminal : > >(gdb) run >Starting program: /usr/local/bin/pd -oss -channels 2 my-bug-test.pd >[Thread debugging using libthread_db enabled] >[New Thread 0xb6168b70 (LWP 5214)] > : Avifile RELEASE-0.7.48-100119-21:44-../src/configure > : Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr >pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext >fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_api > : 3200.00 MHz AMD Phenom(tm) II X2 555 Processor detected >where > >Program received signal SIGSEGV, Segmentation fault. >0x0011 in ?? () >(gdb) where >#0 0x0011 in ?? () >#1 0x080a9665 in gobj_displace_withtag (x=0x8215790, >dx=, dy=0) at g_editor.c:70 >#2 canvas_displaceselection (x=0x8215790, dx=, dy=0) >at g_editor.c:1913 >#3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, fmod=2) >at g_editor.c:2102 >#4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, >argv=0xb08c) at m_class.c:792 >#5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, >argv=0xb08c) at m_class.c:813 >#6 0x080cff0a in binbuf_eval (x=0x814d610, target=, >argc=0, argv=0x0) at m_binbuf.c:726 >#7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at s_inter.c:560 >#8 0x080ddb7a in sys_domicrosleep (microsec=, >pollem=) at s_inter.c:198 >#9 0x080de662 in sys_pollgui () at s_inter.c:862 >#10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 >#11 m_mainloop () at m_sched.c:560 >#12 0x080dcc09 in sys_main (argc=5, argv=0xb4e4) at s_main.c:310 >#13 0x080e56cb in main (argc=5, argv=0xb4e4) at s_entry.c:32 >(gdb) where >#0 0x0011 in ?? () >#1 0x080a9665 in gobj_displace_withtag (x=0x8215790, >dx=, dy=0) at g_editor.c:70 >#2 canvas_displaceselection (x=0x8215790, dx=, dy=0) >at g_editor.c:1913 >#3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, fmod=2) >at g_editor.c:2102 >#4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, >argv=0xb08c) at m_class.c:792 >#5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, >argv=0xb08c) at m_class.c:813 >#6 0x080cff0a in binbuf_eval (x=0x814d610, target=, >argc=0, argv=0x0) at m_binbuf.c:726 >#7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at s_inter.c:560 >#8 0x080ddb7a in sys_domicrosleep (microsec=, >pollem=) at s_inter.c:198 >#9 0x080de662 in sys_pollgui () at s_inter.c:862 >#10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 >#11 m_mainloop () at m_sched.c:560 >#12 0x080dcc09 in sys_main (argc=5, argv=0xb4e4) at s_main.c:310 >#13 0x080e56cb in main (argc=5, argv=0xb4e4) at s_entry.c:32 > >Thanks again > >Al >On Sat, Nov 27, 2010 at 11:37 AM, Mathieu Bouchard wrote: > >> On Sat, 27 Nov 2010, ALAN BROOKER wrote: >> >> Also Gridflow as mentioned previously causes crashes but not so hard as >>> py. When I swapped the L2Orkt file to normal extended, I could use Gridflow >>> in the new gui as normal- so perhaps the issue is not in the tk file but >>> else where? >>> >> >> If you (or someone else) can narrow down the l2ork<->gridflow problems, I >> could try to fix them. >> >> Is it something happening mostly with the helpfiles, or also with something >> else ? Is it happening at startup, or later ? >> >> What is the "L20rkt file" ? >> >> ___ >> | Mathieu Bouchard - Aix-en-Provence > >___ >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
Re: [PD] Gridflow+ L2Ork pd-extended (was: L2Ork pd-extended release candidate 1 now available)
I am not sure if you already mentioned this but did you actually try recompiling gridflow from scratch or are you using one of the precompiled packages in conjunction with the l2ork pd-extended? ALAN BROOKER wrote: >If I press ctrl+1 to create an object that's when it crashes out, opening pd >patches is fine but if I try to edit them then a crash will occur as well. >Also opening Grdiflow help index causes crashes without loading the index >patch at all > >On Sat, Nov 27, 2010 at 5:43 PM, Ivica Ico Bukvic wrote: > >> This looks like an incompatibility between tagged moving of an object and >> something in the gridflow. >> >> Does this occur with any object or just some specific object(s)? >> >> Mathieu, The offending call should be the same like the Regular call except >> that is this place is using a tag. It can be found in the g_text.c file. >> >> Cheers! >> >> ALAN BROOKER wrote: >> >> >Hi Mathieu, >> > >> >Thanks for this, I have done a trace back with the following output on the >> >terminal : >> > >> >(gdb) run >> >Starting program: /usr/local/bin/pd -oss -channels 2 my-bug-test.pd >> >[Thread debugging using libthread_db enabled] >> >[New Thread 0xb6168b70 (LWP 5214)] >> > : Avifile RELEASE-0.7.48-100119-21:44-../src/configure >> > : Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr >> >pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext >> >fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc >> extd_api >> > : 3200.00 MHz AMD Phenom(tm) II X2 555 Processor detected >> >where >> > >> >Program received signal SIGSEGV, Segmentation fault. >> >0x0011 in ?? () >> >(gdb) where >> >#0 0x0011 in ?? () >> >#1 0x080a9665 in gobj_displace_withtag (x=0x8215790, >> >dx=, dy=0) at g_editor.c:70 >> >#2 canvas_displaceselection (x=0x8215790, dx=, dy=0) >> >at g_editor.c:1913 >> >#3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, fmod=2) >> >at g_editor.c:2102 >> >#4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, >> >argv=0xb08c) at m_class.c:792 >> >#5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, >> >argv=0xb08c) at m_class.c:813 >> >#6 0x080cff0a in binbuf_eval (x=0x814d610, target=, >> >argc=0, argv=0x0) at m_binbuf.c:726 >> >#7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at s_inter.c:560 >> >#8 0x080ddb7a in sys_domicrosleep (microsec=, >> >pollem=) at s_inter.c:198 >> >#9 0x080de662 in sys_pollgui () at s_inter.c:862 >> >#10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 >> >#11 m_mainloop () at m_sched.c:560 >> >#12 0x080dcc09 in sys_main (argc=5, argv=0xb4e4) at s_main.c:310 >> >#13 0x080e56cb in main (argc=5, argv=0xb4e4) at s_entry.c:32 >> >(gdb) where >> >#0 0x0011 in ?? () >> >#1 0x080a9665 in gobj_displace_withtag (x=0x8215790, >> >dx=, dy=0) at g_editor.c:70 >> >#2 canvas_displaceselection (x=0x8215790, dx=, dy=0) >> >at g_editor.c:1913 >> >#3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, fmod=2) >> >at g_editor.c:2102 >> >#4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, >> >argv=0xb08c) at m_class.c:792 >> >#5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, >> >argv=0xb08c) at m_class.c:813 >> >#6 0x080cff0a in binbuf_eval (x=0x814d610, target=, >> >argc=0, argv=0x0) at m_binbuf.c:726 >> >#7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at s_inter.c:560 >> >#8 0x080ddb7a in sys_domicrosleep (microsec=, >> >pollem=) at s_inter.c:198 >> >#9 0x080de662 in sys_pollgui () at s_inter.c:862 >> >#10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 >> >#11 m_mainloop () at m_sched.c:560 >> >#12 0x080dcc09 in sys_main (argc=5, argv=0xb4e4) at s_main.c:310 >> >#13 0x080e56cb in main (argc=5, argv=0xb4e4) at s_entry.c:32 >> > >> >Thanks again >> > >> >Al >> >On Sat, Nov 27, 2010 at 11:37 AM, Mathieu Bouchard > >wrote: >> > >> >> On Sat, 27 Nov 2010, ALAN BROOKER wrote: >> >> >> >> Also Gridflow as mentioned previously causes crashes but not so hard as >> >>> py. When I swapped the L2Orkt file to normal extended, I
Re: [PD] Gridflow+ L2Ork pd-extended (was: L2Ork pd-extended release candidate 1 now available)
Some externals that rely upon g_canvas.h and/or g_all_guis.h will require a recompile but likely no changes to the source are needed. Please try recompiling and let us know how it goes. HTH Best wishes, Ico ALAN BROOKER wrote: >It's a precompiled package downloaded from Ubuntu puredyne ppa launch >pad-I'll try recompiling a source package and see if that makes a difference > >On Sat, Nov 27, 2010 at 7:20 PM, Ivica Ico Bukvic wrote: > >> I am not sure if you already mentioned this but did you actually try >> recompiling gridflow from scratch or are you using one of the precompiled >> packages in conjunction with the l2ork pd-extended? >> >> ALAN BROOKER wrote: >> >> >If I press ctrl+1 to create an object that's when it crashes out, opening >> pd >> >patches is fine but if I try to edit them then a crash will occur as well. >> >Also opening Grdiflow help index causes crashes without loading the index >> >patch at all >> > >> >On Sat, Nov 27, 2010 at 5:43 PM, Ivica Ico Bukvic wrote: >> > >> >> This looks like an incompatibility between tagged moving of an object >> and >> >> something in the gridflow. >> >> >> >> Does this occur with any object or just some specific object(s)? >> >> >> >> Mathieu, The offending call should be the same like the Regular call >> except >> >> that is this place is using a tag. It can be found in the g_text.c file. >> >> >> >> Cheers! >> >> >> >> ALAN BROOKER wrote: >> >> >> >> >Hi Mathieu, >> >> > >> >> >Thanks for this, I have done a trace back with the following output on >> the >> >> >terminal : >> >> > >> >> >(gdb) run >> >> >Starting program: /usr/local/bin/pd -oss -channels 2 my-bug-test.pd >> >> >[Thread debugging using libthread_db enabled] >> >> >[New Thread 0xb6168b70 (LWP 5214)] >> >> > : Avifile RELEASE-0.7.48-100119-21:44-../src/configure >> >> > : Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic >> mtrr >> >> >pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext >> >> >fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc >> >> extd_api >> >> > : 3200.00 MHz AMD Phenom(tm) II X2 555 Processor detected >> >> >where >> >> > >> >> >Program received signal SIGSEGV, Segmentation fault. >> >> >0x0011 in ?? () >> >> >(gdb) where >> >> >#0 0x0011 in ?? () >> >> >#1 0x080a9665 in gobj_displace_withtag (x=0x8215790, >> >> >dx=, dy=0) at g_editor.c:70 >> >> >#2 canvas_displaceselection (x=0x8215790, dx=, >> dy=0) >> >> >at g_editor.c:1913 >> >> >#3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, >> fmod=2) >> >> >at g_editor.c:2102 >> >> >#4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, >> >> >argv=0xb08c) at m_class.c:792 >> >> >#5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, >> >> >argv=0xb08c) at m_class.c:813 >> >> >#6 0x080cff0a in binbuf_eval (x=0x814d610, target=> out>, >> >> >argc=0, argv=0x0) at m_binbuf.c:726 >> >> >#7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at >> s_inter.c:560 >> >> >#8 0x080ddb7a in sys_domicrosleep (microsec=, >> >> >pollem=) at s_inter.c:198 >> >> >#9 0x080de662 in sys_pollgui () at s_inter.c:862 >> >> >#10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 >> >> >#11 m_mainloop () at m_sched.c:560 >> >> >#12 0x080dcc09 in sys_main (argc=5, argv=0xb4e4) at s_main.c:310 >> >> >#13 0x080e56cb in main (argc=5, argv=0xb4e4) at s_entry.c:32 >> >> >(gdb) where >> >> >#0 0x0011 in ?? () >> >> >#1 0x080a9665 in gobj_displace_withtag (x=0x8215790, >> >> >dx=, dy=0) at g_editor.c:70 >> >> >#2 canvas_displaceselection (x=0x8215790, dx=, >> dy=0) >> >> >at g_editor.c:1913 >> >> >#3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, >> fmod=2) >> >> >at g_editor.c:2102 >> >> >#4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, >> >> >argv=0xb
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
Thx for the report. Let me investigate once I get back home. András Murányi wrote: >with today's build, i got this upon clicking a [tgl] in a nested GOP >(couldn't reproduce it from scratch) > >*** buffer overflow detected ***: ./pd terminated >=== Backtrace: = >/lib/libc.so.6(__fortify_fail+0x37)[0x7f7189d6d217] >/lib/libc.so.6(+0xfe0d0)[0x7f7189d6c0d0] >/lib/libc.so.6(+0xfd539)[0x7f7189d6b539] >/lib/libc.so.6(_IO_default_xsputn+0xcc)[0x7f7189ce3d1c] >/lib/libc.so.6(_IO_vfprintf+0x14c)[0x7f7189cb34ec] >/lib/libc.so.6(__vsprintf_chk+0x99)[0x7f7189d6b5d9] >/lib/libc.so.6(__sprintf_chk+0x7f)[0x7f7189d6b51f] >./pd[0x479cd4] >./pd(sys_pollgui+0xb8)[0x49ed78] >./pd(m_mainloop+0x84b)[0x4984db] >./pd(sys_main+0x225)[0x49d0b5] >/lib/libc.so.6(__libc_start_main+0xfd)[0x7f7189c8cc4d] >./pd[0x414159] >=== Memory map: >0040-0050b000 r-xp 08:12 2769414 >/home/muranyia/Download/pd/bin/pd >0070a000-0070b000 r--p 0010a000 08:12 2769414 >/home/muranyia/Download/pd/bin/pd >0070b000-0070d000 rw-p 0010b000 08:12 2769414 >/home/muranyia/Download/pd/bin/pd >0070d000-00b1d000 rw-p 00:00 0 >01694000-0d33e000 rw-p 00:00 0 >[heap] >7f71798b6000-7f71798b8000 r-xp 08:12 877193 >/usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux >7f71798b8000-7f7179ab7000 ---p 2000 08:12 877193 >/usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux >7f7179ab7000-7f7179ab8000 r--p 1000 08:12 877193 >/usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux >7f7179ab8000-7f7179ab9000 rw-p 2000 08:12 877193 >/usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux >7f7179ab9000-7f7179aba000 r-xp 08:12 459292 >/usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux >7f7179aba000-7f7179cba000 ---p 1000 08:12 459292 >/usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux >7f7179cba000-7f7179cbb000 r--p 1000 08:12 459292 >/usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux >7f7179cbb000-7f7179cbc000 rw-p 2000 08:12 459292 >/usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux >7f7179cbc000-7f7179cbd000 r-xp 08:12 880139 >/usr/lib/pd-extended/extra/maxlib/divmod.pd_linux >7f7179cbd000-7f7179ebc000 ---p 1000 08:12 880139 >/usr/lib/pd-extended/extra/maxlib/divmod.pd_linux >7f7179ebc000-7f7179ebd000 r--p 08:12 880139 >/usr/lib/pd-extended/extra/maxlib/divmod.pd_linux >7f7179ebd000-7f7179ebe000 rw-p 1000 08:12 880139 >/usr/lib/pd-extended/extra/maxlib/divmod.pd_linux >7f7179ebe000-7f7179ec2000 r-xp 08:12 1467325 >/usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux >7f7179ec2000-7f717a0c1000 ---p 4000 08:12 1467325 >/usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux >7f717a0c1000-7f717a0c2000 r--p 3000 08:12 1467325 >/usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux >7f717a0c2000-7f717a0c3000 rw-p 4000 08:12 1467325 >/usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux >7f717a0c3000-7f717a0c7000 r-xp 08:12 911395 >/usr/lib/pd-extended/extra/flatspace/popup.pd_linux >7f717a0c7000-7f717a2c6000 ---p 4000 08:12 911395 >/usr/lib/pd-extended/extra/flatspace/popup.pd_linux >7f717a2c6000-7f717a2c7000 r--p 3000 08:12 911395 >/usr/lib/pd-extended/extra/flatspace/popup.pd_linux >7f717a2c7000-7f717a2c8000 rw-p 4000 08:12 911395 >/usr/lib/pd-extended/extra/flatspace/popup.pd_linux >7f717a2c8000-7f717a2ce000 r-xp 08:12 2762244 >/usr/lib/pd-extended/extra/cyclone/switch.pd_linux >7f717a2ce000-7f717a4cd000 ---p 6000 08:12 2762244 >/usr/lib/pd-extended/extra/cyclone/switch.pd_linux >7f717a4cd000-7f717a4ce000 r--p 5000 08:12 2762244 >/usr/lib/pd-extended/extra/cyclone/switch.pd_linux >7f717a4ce000-7f717a4cf000 rw-p 6000 08:12 2762244 >/usr/lib/pd-extended/extra/cyclone/switch.pd_linux >7f717a4cf000-7f717a4d6000 r-xp 08:12 2762328 >/usr/lib/pd-extended/extra/cyclone/prepend.pd_linux >7f717a4d6000-7f717a6d5000 ---p 7000 08:12 2762328 >/usr/lib/pd-extended/extra/cyclone/prepend.pd_linux >7f717a6d5000-7f717a6d6000 r--p 6000 08:12 2762328 >/usr/lib/pd-extended/extra/cyclone/prepend.pd_linux >7f717a6d6000-7f717a6d7000 rw-p 7000 08:12 2762328 >/usr/lib/pd-extended/extra/cyclone/prepend.pd_linux >7f717a6d7000-7f717a6d8000 r-xp 08:12 1630422 >/usr/lib/pd-extended/extra/jasch_lib/strcut.pd_linux >7f717a6d8000-7f717a8d8000 ---p 1000 08:12 1630422 >/usr/lib/pd-extended/extra/jasch_lib/strcut.pd_linux >7f717a8d8000-7f717a8d9000 r--p 1000 08:12 1630422 >/usr/lib/pd-extended/extra/jasch_lib/strcut.pd_linux >7f717a8d9000-7f717a8da000 rw-p 2000 08:12 1630422 >/usr/lib/pd-extended/extra/jasch_lib/strcut.pd_linux >7f717a8da000-7f717a8dc000 r-xp 08:12 1638450 >/home/muranyia/Download/pd/extra/moonlib/absolutepath.pd_linux >7f717a8dc000-7f717aadb000 ---p 2000 08:12 1638450 >/home/muranyia/Download/pd/extra/moonlib/absolutepath.pd_linux >7f717aadb000-7f717aadc000 r--p 1000 08:12 1638450 >/home/muranyia/Download/pd/extra/moonlib/absolutepath.pd_linux >7f717a
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Sat, 2010-11-27 at 20:44 +0100, András Murányi wrote: > with today's build, i got this upon clicking a [tgl] in a nested GOP > (couldn't reproduce it from scratch) Figured this one out--forgot to update one place in the g_numbox.c actually. It should be fine now. That said, there are still a few gop problems when using gop within gop and I've traced these down to the fact that tcl/tk tends to recycle window_names for some reason (not sure if this is a part of the undo/redo/cut/copy/paste system or native tcl/tk). Anyone has any idea? http://l2ork.music.vt.edu/main/?page_id=56 Cheers! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Sat, 2010-11-27 at 22:47 -0800, Jonathan Wilkes wrote: > Small detail-- your 'Put' menu is tearoff-able. This is intentional. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Sat, 2010-11-27 at 23:18 -0800, Jonathan Wilkes wrote: > Hi, > Here are some scrolling observations: > In the attached patch, drag the [pd] object far down into the > bottom right-hand corner, so that you get some scrollbars to appear. > Now, on the current pd-extended, you can scroll down to that object, > and when you drag it back to its original location, the scrollbars > respond in realtime so that the object swoops back up the patch > until, finally, the scrollbars disappear. In your version the > scrollbars don't react until you stop dragging and release the mouse > button. Just an observation-- I suppose both methods have their > strengths and weaknesses. I prefer the current Pd-ext behavior-- > for example, if I happen to paste an object into another patch with a smaller > window size, it makes it quick to drag it back up. > > But notice that once you drag the [pd] object back near its original > position, the [f] object looks as if it's at (0,0), when it's really > at (10,10). However, if you save the patch and reopen it the [f] > will appear at its proper, original position-- (10,10). I think this > is a bug, because it means any time one adds or takes away the > scrollbars the absolute positioning of the objects on the canvas is > temporarily lost, forcing the user to close and open to see the > real positioning. > > -Jonathan Both of these are actually a feature. I actually used to have real-time scrollbar updates but that simply bogged the cpu down too much, so I opted to updating them only once an object has stopped moving which in most if not all cases makes perfect sense. The reason canvas is displaced in l2ork version is because our philosophy is "if a patch can fit in a window, it should." Granted, it has some shortcomings like patches opening and then having to readjust as well as having them not (0,0)-centric which makes them potentially less compatible with vanilla version. That said, I believe this is a much better way of dealing with patches, and if one really wants to "lock-in" patch positioning, they should simply use a cnv (canvas) object whose name in many ways suggests exactly that. NB: repositioning of window upon load can be avoided only if the format of saving the patch also includes the top-left corner of the canvas, which current format does not support. Please note that l2ork's scrolling algorithm also accounts for all other operations, such as undo/redo/cut/copy/paste, even key presses that may extend the width of an object. Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
OK, release candidate 2 is now up with following changes: *This one was *really* bad: Cut/Paste/Undo/Redo creates double entries on gop-in-gop patches. Basically, after literally a day of troubleshooting and posting hooks all over the pd source (heck, I even got to study binbuf stuff :-) it appears in these instances window_name never changes upon restore (in other words tcl/tk canvas's documentation lies about not reusing id with every new object--why am I not surprised?) NB: this finally solves every instance I am familiar with in which pd suddenly starts spewing two or more objects per each key-press/action. Consequently, even though I've said it many times before, I finally believe this solves all of the GOP redraw/bug issues. To best test this problem you can simply create a simple patch using either vanilla pd or pd-extended with a GOP abstraction that has another visible GOP abstraction inside it. Now on the parent window cut and undo (or paste) the GOP-ed abstraction and open it. Try creating a new object inside it and presto, everything is doubled. As you do more cut/undos you can get as many of them per action as you like :-). This can also result in a crash as window close will be also registered multiple times. If you are wondering how the fix works, it's the ugliest hack on the planet made for the comparably attractive toolkit: every time the undo/copy queue is copied I insert a bogus object prior to the selection (in this case a comment with an appropriately redundant name) and offset all connections by one. Once the buffer is restored, the fact it is different from the original scene (seems to me that the tcl/tk might be caching things id-wise without properly disconnecting HID hooks to those widgets, hence multiple entries per action) forces tcl/tk to assign truly unique ids to newly pasted objects. Upon restoring the queue, I erase the bogus object. Now, how ugly is that? So, the next time you have an opportunity to read tcl/tk documentation don't forget to take it with a boulder of salt. Other fixes: *recreation of gop-ed objects when selecting their text (a.k.a. activating them) must not apply to gop-ed pd patchers (when clicked to change their names) *changing name on a gop-ed pd patcher automatically resizes patcher gop window and correctly positions outlets *Added ctrl+enter reselect option *cleaned up stderr errors about canvases/widgets not found *when closing dirty patch and dirty abstraction, prompts are incorrectly focusing on and pointing to wrong windows *cord inspector uses globally defined font size *removed xy stretch option from the font menu as it appears to be unstable *corrected text color on pd patcher Latest snapshot is available at: http://l2ork.music.vt.edu/main/?page_id=56 As always, feedback is most appreciated. Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
> > I think it makes a lot of sense to only have the Cord Inspector > > available during Edit Mode, like Ico said, play/run mode should not have > > other things drawing on the CPU. > > sure. > i was rather saying that i find it weird that if i am in edit mode and > press Ctrl-R i get the cord inspector, whereas if i am in run mode and > press Ctrl-R i get nothing. i would expect it to flip to edit mode and > turn the inspector on. > (similar to what happens if i press Ctrl-1 in run mode) What you suggested is actually rather simple (boils basically down to one line of code). The difference between Ctrl+r and Ctrl+1 (object creation) is that former is a state, while latter a one-time event. So, for instance if in the current iteration you wish to have cord monitoring on at all times during the editing process it simply requires one Ctrl+R press at any point in time (regardless whether the editor is on or off), after which it stays on once again regardless of the editor's state so from that point on it only requires a Ctrl+e and you are ready to go. That said, rigging Ctrl+r to also open editor makes sense only in the case both the editor and Cord Inspector are off. Latest version now includes this little alteration. HTH Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
> > Both of these are actually a feature. I actually used to > > have real-time > > scrollbar updates but that simply bogged the cpu down too > > much, so I > > opted to updating them only once an object has stopped > > moving which in > > most if not all cases makes perfect sense. > > That makes sense. It will make cutting and pasting from a > different window size a bit more difficult (because objects > are pasted at the coords from the original patch) but unless > pasting from the bottom corner of a 1000px canvas it shouldn't make > much difference. Actually, this is an excellent point. Consequently, 3rd release candidate is now up where I've made the following adjustments: *changed paste action so that it pastes where the current mouse position is rather than duplicating original x/y positions. more so, the newly spawned objects are grabbed (as if creating an object from a menu), allowing easy repositioning. This change will greatly help in making sure that objects are not spawned very far from the current canvas location (as per Jonathan's comment/suggestion) due to the new scrolling algorithm. *duplicate now works on other canvases as well (does not require duplicating within the same canvas) thus replacing the functionality of the old paste action which preserves x/y positions. There is no offset if the newly pasted canvas is different than the old one. *fixed bug where scrollbars would not redraw after initial dragging of a newly created object. *enabled autopatch for iemgui objects. *Invoking disabled ctrl+r now enables both the edit mode and the cord inspector (as per Iohannes's suggestion). As usual feedback is most appreciated. http://l2ork.music.vt.edu/main/?page_id=56 Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
