Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
On Tue, 14 Dec 2010, Jonathan Wilkes wrote: --- On Wed, 12/15/10, Mathieu Bouchard ma...@artengine.ca wrote: It seems that Pd on Windows takes several times more time instantiating abstractions than on Linux and OSX, especially with a full-blown path of 40 folders or so. This could be mostly fixed if Claude's abstraction-cache had been included in Pd, which can dramatically speed up abstraction-loading on all platforms, but probably especially on Windows (but I didn't check). Is this patch on the tracker? I can't find it. I don't know, I don't look there. Ask Claude. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ 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 Sun, 28 Nov 2010, João Pais wrote: I had a small look at [#many]. Do you think it would be better to use C-coded objects instead for this kind of complex gop abstractions? Well, you see, Pd *has* to grow more means to solve problems using abstractions, so, I'm making the bet that I can solve this problem with abstractions. I don't know whether it'd really take less time with C code, and if I did, I wouldn't end up with more means to solve problems using abstractions. (I wrote small externals to support [#many]). What makes you think that it would be better ? I use lots of abstractions with gop (from my library, specially [m-i] for midi input), and it seems to me that at some point I have so many abstractions, that my patches take longer to load. But I didn't do a real test to prove this. It seems that Pd on Windows takes several times more time instantiating abstractions than on Linux and OSX, especially with a full-blown path of 40 folders or so. This could be mostly fixed if Claude's abstraction-cache had been included in Pd, which can dramatically speed up abstraction-loading on all platforms, but probably especially on Windows (but I didn't check). But this does not especially affect [#many], I'd guess. It would be a lot worse if [#many]'s elements could be abstractions, which is a planned feature. Then if you used a gop-abstraction name as the first arg of [#many], you'd trigger an insane number of lookups. This might be mitigated by specifying the absolute path to the abstraction when instantiating. This wouldn't be a bad idea to have an external that can lookup that, because as it is, [#many foo 16 16] can't see foo.pd in the folder of the patch that has [#many foo 16 16] in it, and that's more than annoying, so, this issue has to be tackled anyway. But apart from that... can you find any abstraction instances inside of [#many] ? I don't see any... so, it shouldn't be much longer to load. GridFlow's three big abstractions are [doc_h] (9k), [#many] (10k), and [#camera] (12.5k), and among them, [#many] is the only to not load any other abstractions. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ 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 Wed, 12/15/10, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: João Pais jmmmp...@googlemail.com Cc: pd-list@iem.at Date: Wednesday, December 15, 2010, 1:11 AM On Sun, 28 Nov 2010, João Pais wrote: I had a small look at [#many]. Do you think it would be better to use C-coded objects instead for this kind of complex gop abstractions? Well, you see, Pd *has* to grow more means to solve problems using abstractions, so, I'm making the bet that I can solve this problem with abstractions. I don't know whether it'd really take less time with C code, and if I did, I wouldn't end up with more means to solve problems using abstractions. (I wrote small externals to support [#many]). What makes you think that it would be better ? I use lots of abstractions with gop (from my library, specially [m-i] for midi input), and it seems to me that at some point I have so many abstractions, that my patches take longer to load. But I didn't do a real test to prove this. It seems that Pd on Windows takes several times more time instantiating abstractions than on Linux and OSX, especially with a full-blown path of 40 folders or so. This could be mostly fixed if Claude's abstraction-cache had been included in Pd, which can dramatically speed up abstraction-loading on all platforms, but probably especially on Windows (but I didn't check). Is this patch on the tracker? I can't find it. But this does not especially affect [#many], I'd guess. It would be a lot worse if [#many]'s elements could be abstractions, which is a planned feature. Then if you used a gop-abstraction name as the first arg of [#many], you'd trigger an insane number of lookups. This might be mitigated by specifying the absolute path to the abstraction when instantiating. This wouldn't be a bad idea to have an external that can lookup that, because as it is, [#many foo 16 16] can't see foo.pd in the folder of the patch that has [#many foo 16 16] in it, and that's more than annoying, so, this issue has to be tackled anyway. But apart from that... can you find any abstraction instances inside of [#many] ? I don't see any... so, it shouldn't be much longer to load. GridFlow's three big abstractions are [doc_h] (9k), [#many] (10k), and [#camera] (12.5k), and among them, [#many] is the only to not load any other abstractions. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC -Inline Attachment Follows- ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
On Sun, 5 Dec 2010, Ivica Ico Bukvic wrote: 2) 0.43 will likely never merge some of the UI L2Ork improvements as they are for the lack of a better word a hack, a temporary fix if you like until something better comes around to replace aging Tcl/Tk. Why do you say Tcl/Tk is «aging» ? What's the rationale for this ? Changing toolkits is a tremendous task, and, if you ask me, it's rather hard to find something vaguely like TkCanvas. IIRC, there's nothing like it directly in Gtk and Qt. May I ask you which widget do you intend to replace TkCanvas with ??? And if you have trouble getting your diffs into pd, can you imagine the trouble of getting into pd the diffs for a change of toolkit ? 3) 0.42.5 code-base is IMHO more friendly towards porting the entire thing to a different toolkit as all tcl/tk stuff is encapsulated into one (albeit ugly) big file. Frankly, I don't think that this is true. Whether there is one or several files, hardly matters, though I found out I preferred one big file (but I could change my mind and it still wouldn't be a big issue). What matters is that no matter whether you use 0.42 or 0.43, the tcl/tk stuff is NOT encapsulated in whatever way, because there's Tcl code all over the g_*.c files. I don't know how you can be hacking that code while claiming that all the tcl/tk stuff is «encapsulated». What do you mean by that ? As such, I see it as a better springboard for such a transition. Don't be fooled... (please) FWIW, I did some digging through the Juce platform and it is rather amazing. I will dig a bit more to see how quickly one could port the core Pd. A big note to you : find an equivalent for TkCanvas, or how you're going to make one, before looking for anything else in there. But another big note to you : afaict, Miller will not accept any C++ in the project. I also understand that this process will undoubtedly require a huge rewrite of all gui-based externals but sometimes one simply has to take a fews steps back to start leaping forward. If Juce is any better than Tcl/Tk, the rewrite should be much easier than the original write, no ? If it's not, then perhaps Juce is not the answer, or perhaps Tcl/Tk doesn't really suck, or perhaps the sucky part is really something else that you are not addressing. You will see. For example, when I rewrote a lot of gui classes, I kept C and I kept Tcl/Tk, but used them in a different way than Pd does, which very radically cut down the amount of code (per gui class) by much more than half. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ 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 Sun, 5 Dec 2010, Martin Peach wrote: That's funny. I thought the whole 0.43 thing was about putting the tcl/tk into one place. It isn't doing that at all. All the sys_vgui calls are still there. There is no such thing in 0.43. The way it's been talked about, though, it was misleading to people who didn't look at the code difference. tcl/tk (one of the slowest languages around) Benchmarks indicate that Tcl/Tk 8.5 is quite faster than 8.4. But if anyone insists on sticking with Tcl/Tk 8.4, they're sticking with year 2002 and rejecting all the speed improvements that were made between 2002 and 2007, for instance. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ 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)
2) 0.43 will likely never merge some of the UI L2Ork improvements as they are for the lack of a better word a hack, a temporary fix if you like until something better comes around to replace aging Tcl/Tk. Why do you say Tcl/Tk is aging ? What's the rationale for this ? Because its performance, appearance (at least on Linux), and buggy/incorrect documentation remind me of good ole' nineties. Changing toolkits is a tremendous task, and, if you ask me, it's rather hard to find something vaguely like TkCanvas. IIRC, there's nothing like it directly in Gtk and Qt. May I ask you which widget do you intend to replace TkCanvas with ??? How about: Qt Canvas http://doc.trolltech.com/4.2/graphicsview-portedcanvas-canvas-cpp.html Or better yet, how about Juce's drawable class that supports just about anything under the Sun: http://www.rawmaterialsoftware.com/api/classDrawable.html Both of these are way faster than Tk's canvas. See the juce demo if you have a chance. On my netbook it runs circles around the Tk's editor which feels very slow. Even with l2ork improvements that cut the C-Tk socket chatter to a fraction of what is in vanilla, it is still considerably slower than Juce doing simpler tasks. And if you have trouble getting your diffs into pd, can you imagine the trouble of getting into pd the diffs for a change of toolkit ? That's why I mentioned that I won't mind maintaining L2Ork iteration of Pd for as long as there is a need to do so. 3) 0.42.5 code-base is IMHO more friendly towards porting the entire thing to a different toolkit as all tcl/tk stuff is encapsulated into one (albeit ugly) big file. Frankly, I don't think that this is true. Whether there is one or several files, hardly matters, though I found out I preferred one big file (but I could change my mind and it still wouldn't be a big issue). What matters is that no matter whether you use 0.42 or 0.43, the tcl/tk stuff is NOT encapsulated in whatever way, because there's Tcl code all over the g_*.c files. I don't know how you can be hacking that code while claiming that all the tcl/tk stuff is encapsulated. What do you mean by that ? Please check my changes and you'll see it is not that bad. Selection is already partially circumvented using tagged approach, so is moving by tag (at least for vanilla objects). So, even though there are seemingly a lot of calls, it all pretty much boils down to draw/erase/select/move which can be easily replaced with appropriate calls once you've become comfortable with the basic code structure. As such, I see it as a better springboard for such a transition. Don't be fooled... (please) I am not. Please check out the L2Ork iteration of Pd if you doubt my resolve. FWIW, I did some digging through the Juce platform and it is rather amazing. I will dig a bit more to see how quickly one could port the core Pd. A big note to you : find an equivalent for TkCanvas, or how you're going to make one, before looking for anything else in there. Please check the Juce Demo that comes with Juce SDK (it builds pretty quickly) and all your concerns will be laid to rest. You may also check Max/MSP (or some of its videos) and you'll see what its canvas can or cannot do. But another big note to you : afaict, Miller will not accept any C++ in the project. And that is certainly his right. FWIW, I do not see changing core Pd engine in this port, but only the editor side of things, so C++ and C should still coexist quite happily. In other words C++ would replace only the Tk side of things not the core engine. I also understand that this process will undoubtedly require a huge rewrite of all gui-based externals but sometimes one simply has to take a fews steps back to start leaping forward. If Juce is any better than Tcl/Tk, the rewrite should be much easier than the original write, no ? I am quite confident this is the case. If it's not, then perhaps Juce is not the answer, or perhaps Tcl/Tk doesn't really suck, or perhaps the sucky part is really something else that you are not addressing. You will see. For example, when I rewrote a lot of gui classes, I kept C and I kept Tcl/Tk, but used them in a different way than Pd does, which very radically cut down the amount of code (per gui class) by much more than half. Given the complexity of Gridflow, I think you would love Juce. Have a look over its classes as well as juce demo and I think you will be pleasantly surprised. 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 Sun, 12/5/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com, Hans-Christoph Steiner h...@at.or.at Cc: 'PD List' pd-list@iem.at Date: Sunday, December 5, 2010, 3:33 AM Great suggestion! That might work quite nicely. We only have to make sure for legacy purposes that wherever in the old code this variable is being checked that it can gracefully handle values less than 0. That said, my top priority as of right now is further testing current code as well as continuing to work on my neck piece. Beyond that I would like to make all iem objects resizable via GUI, revamp the to-front and to-back algorithm so that it does not rely upon undo, followed by an infinite undo, and then tooltips, improved color picker, improve upon the tidy algorithm, and then weed through the documentation and externals and only keep those that are well maintained and are not redundant. Your suggestion might fit nicely somewhere inside here as well. And where does merging your changes in with pd-extended 0.43 fit into all this? I would also like to see Qt-ified (or better yet juce-ified) version of the whole thing. This will however have to wait. Long story short it might be a while before I make the next big push. In the meantime, as always, contributions will be most welcome provided they do not break the backwards compatibility. Cheers! Ico Jonathan Wilkes jancs...@yahoo.com wrote: Hi Ivica, Since you've been rooting around in the Pd source, I wanted to bring up an idea about canvas properties and get your opinion on it: If you look at the coords for a particular canvas, the 7th argument currently controls GOP status. 0 = no GOP 1 = GOP 2 = GOP + hide args But what if this argument were thought of as controlling canvas visibility in a more general way: -2 = no menu, no scroll -1 = no menu 0 = normal 1 = GOP 2 = GOP + hide args That way it's not necessary to use an abstraction to hide the menu, plus it can be set the way it should be set-- in the canvas properties menu. -Jonathan ___ 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)
And where does merging your changes in with pd-extended 0.43 fit into all this? Not sure. I've submitted at least half-dozen patches into the sourceforge already and many more via mailing list and only a fraction of them have been looked at, and even less merged. Granted, some of them are somewhat controversial (e.g. revamping the scrolling algorithm), yet with such a low response rate one certainly feels discouraged in contributing further, particularly considering just how time-consuming fragmenting improvements into sub-patches can be. OTOH, I do understand just how hard it can be for one to maintain code when there are a bunch of patches trickling in at all times--it's a full-time job in and of itself, particularly in respect to regressions. Yet, having spent good two weeks chasing exactly such regressions and IMHO improving editor experience to the point where both show-stopping as well as usability bugs have been by and large squashed, I certainly hope they will find their way eventually into the core Pd. The code produced so far has been clean and (apart from fprintf's for debugging purposes that are currently commented out awaiting further potential development) should be rather easy to merge into the main trunk. The real question is whether Hans, or perhaps more importantly Miller will find doing so to be of their interest. All that said, I think I'll continue to maintain a L2Ork variation until either its feature-set becomes synonymous with the core Pd package or there is no more reason to maintain it (and FWIW as of right now there are plenty, so I don't see me stopping the support anytime soon). 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 Mon, 12/6/10, i...@vt.edu i...@vt.edu wrote: From: i...@vt.edu i...@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com Cc: Hans-Christoph Steiner h...@at.or.at, 'PD List' pd-list@iem.at Date: Monday, December 6, 2010, 1:16 AM And where does merging your changes in with pd-extended 0.43 fit into all this? Not sure. I've submitted at least half-dozen patches into the sourceforge already and many more via mailing list and only a fraction of them have been looked at, and even less merged. Granted, some of them are somewhat controversial (e.g. revamping the scrolling algorithm), yet with such a low response rate one certainly feels discouraged in contributing further, The argument as I understand it is that all your patches apply to 0.42-5. So pick the simplest feature or bugfix you've implemented and submit it as a patch for 0.43. If you get feedback and/or it gets merged, end of discouragement. If you don't, then the development process is broken and needs fixing. If I knew how I'd do it myself. -Jonathan particularly considering just how time-consuming fragmenting improvements into sub-patches can be. OTOH, I do understand just how hard it can be for one to maintain code when there are a bunch of patches trickling in at all times--it's a full-time job in and of itself, particularly in respect to regressions. Yet, having spent good two weeks chasing exactly such regressions and IMHO improving editor experience to the point where both show-stopping as well as usability bugs have been by and large squashed, I certainly hope they will find their way eventually into the core Pd. The code produced so far has been clean and (apart from fprintf's for debugging purposes that are currently commented out awaiting further potential development) should be rather easy to merge into the main trunk. The real question is whether Hans, or perhaps more importantly Miller will find doing so to be of their interest. All that said, I think I'll continue to maintain a L2Ork variation until either its feature-set becomes synonymous with the core Pd package or there is no more reason to maintain it (and FWIW as of right now there are plenty, so I don't see me stopping the support anytime soon). 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)
The argument as I understand it is that all your patches apply to 0.42-5. So pick the simplest feature or bugfix you've implemented and submit it as a patch for 0.43. If you get feedback and/or it gets merged, end of discouragement. If you don't, then the development process is broken and needs fixing. If I knew how I'd do it myself. Even if I had the time to do this (meaning learn 0.43 code base), it is not that simple. I actually prefer 0.42.5 over 0.43 for several reasons: 1) 0.42.5 is now rather stable while 0.43 is still evolving (AFAIK) and as such it is IMHO not production ready. In due time this will change but AFAIK 0.43 is not there yet. 2) 0.43 will likely never merge some of the UI L2Ork improvements as they are for the lack of a better word a hack, a temporary fix if you like until something better comes around to replace aging Tcl/Tk. 3) 0.42.5 code-base is IMHO more friendly towards porting the entire thing to a different toolkit as all tcl/tk stuff is encapsulated into one (albeit ugly) big file. As such, I see it as a better springboard for such a transition. FWIW, I did some digging through the Juce platform and it is rather amazing. I will dig a bit more to see how quickly one could port the core Pd. I also understand that this process will undoubtedly require a huge rewrite of all gui-based externals but sometimes one simply has to take a fews steps back to start leaping forward. Just my 1-cents worth... 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 2010-12-05 21:34, Ivica Ico Bukvic wrote: 3) 0.42.5 code-base is IMHO more friendly towards porting the entire thing to a different toolkit as all tcl/tk stuff is encapsulated into one (albeit ugly) big file. As such, I see it as a better springboard for such a transition. That's funny. I thought the whole 0.43 thing was about putting the tcl/tk into one place. In 0.42 the tcl/tk (one of the slowest languages around) is all over the Pd code, not just in pd.tk. Martin ___ 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 Dec 5, 2010, at 10:42 PM, Martin Peach wrote: On 2010-12-05 21:34, Ivica Ico Bukvic wrote: 3) 0.42.5 code-base is IMHO more friendly towards porting the entire thing to a different toolkit as all tcl/tk stuff is encapsulated into one (albeit ugly) big file. As such, I see it as a better springboard for such a transition. That's funny. I thought the whole 0.43 thing was about putting the tcl/tk into one place. In 0.42 the tcl/tk (one of the slowest languages around) is all over the Pd code, not just in pd.tk. That's a longer term goal, but 0.43 was more limited in scope. Basically the whole 'pd-gui' part was rewritten in only Tcl/Tk (no C), and some changes were made on the 'pd' side to streamline those changes. .hc 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
That's funny. I thought the whole 0.43 thing was about putting the tcl/tk into one place. In 0.42 the tcl/tk (one of the slowest languages around) is all over the Pd code, not just in pd.tk. Martin I guess drawing/erase commands are all over pd's code but this is easily identified and replaced with appropriate draw/select/unselect/delete commands, hence personally I don't feel this will be an issue. What will be a much greater issue is porting all the custom externals from other libs to be supported under the new toolkit (whatever that may be). ___ 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)
Hi Ivica, Since you've been rooting around in the Pd source, I wanted to bring up an idea about canvas properties and get your opinion on it: If you look at the coords for a particular canvas, the 7th argument currently controls GOP status. 0 = no GOP 1 = GOP 2 = GOP + hide args But what if this argument were thought of as controlling canvas visibility in a more general way: -2 = no menu, no scroll -1 = no menu 0 = normal 1 = GOP 2 = GOP + hide args That way it's not necessary to use an abstraction to hide the menu, plus it can be set the way it should be set-- in the canvas properties menu. -Jonathan ___ 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)
Great suggestion! That might work quite nicely. We only have to make sure for legacy purposes that wherever in the old code this variable is being checked that it can gracefully handle values less than 0. That said, my top priority as of right now is further testing current code as well as continuing to work on my neck piece. Beyond that I would like to make all iem objects resizable via GUI, revamp the to-front and to-back algorithm so that it does not rely upon undo, followed by an infinite undo, and then tooltips, improved color picker, improve upon the tidy algorithm, and then weed through the documentation and externals and only keep those that are well maintained and are not redundant. Your suggestion might fit nicely somewhere inside here as well. I would also like to see Qt-ified (or better yet juce-ified) version of the whole thing. This will however have to wait. Long story short it might be a while before I make the next big push. In the meantime, as always, contributions will be most welcome provided they do not break the backwards compatibility. Cheers! Ico Jonathan Wilkes jancs...@yahoo.com wrote: Hi Ivica, Since you've been rooting around in the Pd source, I wanted to bring up an idea about canvas properties and get your opinion on it: If you look at the coords for a particular canvas, the 7th argument currently controls GOP status. 0 = no GOP 1 = GOP 2 = GOP + hide args But what if this argument were thought of as controlling canvas visibility in a more general way: -2 = no menu, no scroll -1 = no menu 0 = normal 1 = GOP 2 = GOP + hide args That way it's not necessary to use an abstraction to hide the menu, plus it can be set the way it should be set-- in the canvas properties menu. -Jonathan ___ 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)
Lol, I meant to say next piece (silly android voice recognition)... Ivica Ico Bukvic i...@vt.edu wrote: Great suggestion! That might work quite nicely. We only have to make sure for legacy purposes that wherever in the old code this variable is being checked that it can gracefully handle values less than 0. That said, my top priority as of right now is further testing current code as well as continuing to work on my neck piece. Beyond that I would like to make all iem objects resizable via GUI, revamp the to-front and to-back algorithm so that it does not rely upon undo, followed by an infinite undo, and then tooltips, improved color picker, improve upon the tidy algorithm, and then weed through the documentation and externals and only keep those that are well maintained and are not redundant. Your suggestion might fit nicely somewhere inside here as well. I would also like to see Qt-ified (or better yet juce-ified) version of the whole thing. This will however have to wait. Long story short it might be a while before I make the next big push. In the meantime, as always, contributions will be most welcome provided they do not break the backwards compatibility. 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)
BTW, Hans, is there a reason why pd-extended cannot find moonlib's help files? I tried importing, as well as invoking objects with moonlib/ prefix. How would one go about fixing this other than extending the default.pdsettings file? Gotta love it when your bug-hunt TODO list is finally empty (even if only for a couple of hours :-). Ico THe moonlib help patches work for me using Pd-extended 0.42.5 on Mac OS X 10.5.8. How would one go about troubleshooting this? Is this something that default.pdsettings overwrites or should I hunt for this in some meta-file instead? Please advise. ___ 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 Nov 30, 2010, at 10:42 AM, Ivica Ico Bukvic wrote: BTW, Hans, is there a reason why pd-extended cannot find moonlib's help files? I tried importing, as well as invoking objects with moonlib/ prefix. How would one go about fixing this other than extending the default.pdsettings file? Gotta love it when your bug-hunt TODO list is finally empty (even if only for a couple of hours :-). Ico THe moonlib help patches work for me using Pd-extended 0.42.5 on Mac OS X 10.5.8. How would one go about troubleshooting this? Is this something that default.pdsettings overwrites or should I hunt for this in some meta- file instead? Please advise. You can start by turning on verbose mode and seeing which folder the moonlib objects you're created are actually read from. .hc You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ 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)
You can start by turning on verbose mode and seeing which folder the moonlib objects you're created are actually read from. This is what I get: tried /usr/lib/pd/extra/moonlib/mknob-help.pd and failed tried /home/ico/pd/mknob-help.pd and failed tried /usr/share/pd/mknob-help.pd and failed tried /usr/local/lib/pd/doc/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/postlude/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/cyclone/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/zexy/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/creb/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/cxc/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/iemlib/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/list-abs/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/mapping/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/markex/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/maxlib/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/memento/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/mjlib/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/motex/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/oscx/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/pddp/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/pdogg/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/pixeltango/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/pmpd/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/rradical/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/sigpack/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/smlib/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/toxy/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/unauthorized/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/pan/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/freeverb/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/hcs/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/jmmmp/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/ext13/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/ggee/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/flib/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/ekext/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/flatspace/mknob-help.pd and failed tried /home/ico/pd-externals/mknob-help.pd and failed tried /usr/local/lib/pd-externals/mknob-help.pd and failed tried /usr/lib/pd/extra/mknob-help.pd and failed tried /usr/lib/pd/extra/moonlib/help-mknob.pd and failed tried /home/ico/pd/help-mknob.pd and failed tried /usr/share/pd/help-mknob.pd and failed tried /usr/local/lib/pd/doc/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/postlude/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/cyclone/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/zexy/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/creb/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/cxc/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/iemlib/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/list-abs/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/mapping/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/markex/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/maxlib/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/memento/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/mjlib/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/motex/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/oscx/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/pddp/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/pdogg/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/pixeltango/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/pmpd/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/rradical/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/sigpack/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/smlib/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/toxy/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/unauthorized/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/pan/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/freeverb/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/hcs/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/jmmmp/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/ext13/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/ggee/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/flib/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/ekext/help-mknob.pd and failed tried
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
My guess is that you have another moonlib in your path. Check the verbose dump of loading [mknob] to see where its actually loaded from. .hc On Nov 30, 2010, at 12:35 PM, Ivica Ico Bukvic wrote: You can start by turning on verbose mode and seeing which folder the moonlib objects you're created are actually read from. This is what I get: tried /usr/lib/pd/extra/moonlib/mknob-help.pd and failed tried /home/ico/pd/mknob-help.pd and failed tried /usr/share/pd/mknob-help.pd and failed tried /usr/local/lib/pd/doc/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/postlude/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/cyclone/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/zexy/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/creb/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/cxc/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/iemlib/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/list-abs/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/mapping/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/markex/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/maxlib/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/memento/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/mjlib/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/motex/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/oscx/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/pddp/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/pdogg/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/pixeltango/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/pmpd/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/rradical/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/sigpack/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/smlib/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/toxy/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/unauthorized/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/pan/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/freeverb/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/hcs/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/jmmmp/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/ext13/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/ggee/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/flib/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/ekext/mknob-help.pd and failed tried /usr/lib/pd/doc/5.reference/flatspace/mknob-help.pd and failed tried /home/ico/pd-externals/mknob-help.pd and failed tried /usr/local/lib/pd-externals/mknob-help.pd and failed tried /usr/lib/pd/extra/mknob-help.pd and failed tried /usr/lib/pd/extra/moonlib/help-mknob.pd and failed tried /home/ico/pd/help-mknob.pd and failed tried /usr/share/pd/help-mknob.pd and failed tried /usr/local/lib/pd/doc/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/postlude/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/cyclone/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/zexy/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/creb/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/cxc/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/iemlib/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/list-abs/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/mapping/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/markex/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/maxlib/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/memento/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/mjlib/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/motex/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/oscx/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/pddp/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/pdogg/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/pixeltango/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/pmpd/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/rradical/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/sigpack/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/smlib/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/toxy/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/unauthorized/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/pan/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/freeverb/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/hcs/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/jmmmp/help-mknob.pd and failed tried /usr/lib/pd/doc/5.reference/ext13/help-mknob.pd and failed tried
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
On Tue, 2010-11-30 at 12:55 -0500, Hans-Christoph Steiner wrote: My guess is that you have another moonlib in your path. Check the verbose dump of loading [mknob] to see where its actually loaded from. .hc moonlib is located in /usr/lib/pd/extra/moonlib Please note I am not having a problem opening external but *its help file* which is located in /usr/lib/pd/doc/5.reference/moonlib/ folder and which is dubiously skipped by pd when it searches through that folder. Is pd searching through all 5.reference/ folders or only through some preexisting database of sub-folders? If latter, where is this located? tried /home/ico/moonlib/mknob.l_i386 and failed tried /home/ico/pd-externals/moonlib/mknob.l_i386 and failed tried /usr/local/lib/pd-externals/moonlib/mknob.l_i386 and failed tried /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/moonlib/mknob.l_i386 and failed tried /usr/local/lib/pd/extra/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/postlude/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/doc/5.reference/cyclone/moonlib/mknob.l_i386 and failed tried /home/ico/L2Ork/PD/Abstractions/moonlib/mknob.l_i386 and failed tried /usr/local/lib/pd/extra/abstractions/footils/sssad/moonlib/mknob.l_i386 and failed tried /home/ico/L2Ork/PD/rjlib/moonlib/mknob.l_i386 and failed tried /home/ico/L2Ork/PD/d/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/cyclone/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/zexy/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/creb/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/cxc/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/iemlib/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/list-abs/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/mapping/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/markex/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/maxlib/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/memento/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/mjlib/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/motex/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/oscx/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/pddp/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/pdogg/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/pixeltango/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/pmpd/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/rradical/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/sigpack/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/smlib/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/toxy/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/unauthorized/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/pan/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/freeverb/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/hcs/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/jmmmp/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/ext13/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/ggee/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/flib/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/ekext/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/flatspace/moonlib/mknob.l_i386 and failed tried /home/ico/pd-externals/moonlib/mknob.l_i386 and failed tried /usr/local/lib/pd-externals/moonlib/mknob.l_i386 and failed tried /usr/lib/pd/extra/moonlib/mknob.l_i386 and failed tried /home/ico/moonlib/mknob.pd_linux and failed tried /home/ico/pd-externals/moonlib/mknob.pd_linux and failed tried /usr/local/lib/pd-externals/moonlib/mknob.pd_linux and failed tried /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/moonlib/mknob.pd_linux and failed tried /usr/local/lib/pd/extra/moonlib/mknob.pd_linux and failed tried /usr/lib/pd/extra/postlude/moonlib/mknob.pd_linux and failed tried /usr/lib/pd/doc/5.reference/cyclone/moonlib/mknob.pd_linux and failed tried /home/ico/L2Ork/PD/Abstractions/moonlib/mknob.pd_linux and failed tried /usr/local/lib/pd/extra/abstractions/footils/sssad/moonlib/mknob.pd_linux and failed tried /home/ico/L2Ork/PD/rjlib/moonlib/mknob.pd_linux and failed tried /home/ico/L2Ork/PD/d/moonlib/mknob.pd_linux and failed tried /usr/lib/pd/extra/cyclone/moonlib/mknob.pd_linux and failed tried /usr/lib/pd/extra/zexy/moonlib/mknob.pd_linux and failed tried /usr/lib/pd/extra/creb/moonlib/mknob.pd_linux and failed tried /usr/lib/pd/extra/cxc/moonlib/mknob.pd_linux and failed tried /usr/lib/pd/extra/iemlib/moonlib/mknob.pd_linux and failed tried /usr/lib/pd/extra/list-abs/moonlib/mknob.pd_linux and failed tried /usr/lib/pd/extra/mapping/moonlib/mknob.pd_linux and failed tried /usr/lib/pd/extra/markex/moonlib/mknob.pd_linux and failed tried /usr/lib/pd/extra/maxlib/moonlib/mknob.pd_linux and failed tried /usr/lib/pd/extra/memento/moonlib/mknob.pd_linux and failed tried /usr/lib/pd/extra/mjlib/moonlib/mknob.pd_linux and failed tried
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2010 02:16 AM, Hans-Christoph Steiner wrote: All that said, I like your term better. 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) fgmadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzzay8ACgkQkX2Xpv6ydvT3egCg6+lEssgsu5oKkfMgwdNOVcK8 oRQAn17TAOslWlO5/hPQCeCbkd/DnQJJ =b+uZ -END PGP SIGNATURE- ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
I think 1 and 3 worked fine in osx. Actually I also tried a fourth thing: Destroy the menubar when in 'Run mode'. (Not sure how that would work on osx, but in Gnome it sure makes an obvious distinction between modes!) -Jonathan In L2Ork iteration this functionality is available per-canvas and is toggled via l2ork_toggle_menubar abstraction. This way one can have a mix of guis having one and/or the other. 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 Mon, 11/29/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at Date: Monday, November 29, 2010, 9:11 PM I think 1 and 3 worked fine in osx. Actually I also tried a fourth thing: Destroy the menubar when in 'Run mode'. (Not sure how that would work on osx, but in Gnome it sure makes an obvious distinction between modes!) -Jonathan In L2Ork iteration this functionality is available per-canvas and is toggled via l2ork_toggle_menubar abstraction. This way one can have a mix of guis having one and/or the other. Cheers! Ico Yes, I've been using a msg + [toxy] to do the same thing-- unfortunately you can see the menu getting deleted when you open the patch or make it visible again. -Jonathan ___ 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)
This is that kind of thinking that led me to invent [#many]. I looked at their matrix of toggle-like things and told myself I should make something similar, except it would have a much shorter list of properties, and a possibility to connect plugins (using an extra inlet and outlet) so that any special behaviour can be user-specified. And then I wanted a variable element-class, not just toggle. And thus it was born. Apart from that, many things can be made using [#see]-[#mouse] with various graphics processing in GF/GEM/PDP. [#see] displays a video in a patch, and the video can be tiny, generated, and rendered on demand (it's actually a picture viewer). This is most useful for high-color, pixel-oriented data, or really complicated vector data, perhaps. that's also true, but in this case I was speaking more about small user issues. Pd people (me as well) got used to the clean look of the patches, but sometimes this lack of options also means to waste lots of time when a decent gui has to be made. Clean guis should be the result of the programmer's choices, not of the limitations of the program. I had a small look at [#many]. Do you think it would be better to use C-coded objects instead for this kind of complex gop abstractions? I use lots of abstractions with gop (from my library, specially [m-i] for midi input), and it seems to me that at some point I have so many abstractions, that my patches take longer to load. But I didn't do a real test to prove this. ___ 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 Wed, 24 Nov 2010, Hans-Christoph Steiner wrote: I think there are advantages to having the GUI be a separate process, and it would be worth exploring other ways of havning pd and pd-gui talk. Shared memory is one idea. Plus for things like arrays, the data could be sent as binary thereby skipping the string parsing aspect. Look at how [#see] sends hex codes instead of decimals. Also, chop off the decimals you don't need. If you send ints instead of floats, and use a 12-bit range for stating y-position, every point could fit in 3 hex chars. I say hex instead of base64 because base64 is not built-in in Tcl, therefore it's slower to handle. But the only way to completely bypass all parsing is to use a 2nd socket. I haven't finished making something for that. ___ | Mathieu Bouchard - Aix-en-Provence ___ 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)
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 On Sat, Nov 20, 2010 at 10:20 PM, Ivica Ico Bukvic i...@vt.edu wrote: Dear fellow Pd enthusiasts, I am pleased to report that earlier today L2Ork released latest snapshot of its own variation of pd-extended 0.42.5. While we are working hard on submitting isolated patches upstream (some of which have been already submitted), many more need to be isolated before they can be provided in a useful format. Another roadblock is that we are still stuck on 0.42.5 which makes patch integration so much more difficult into the 0.43 branch. That said, we would love to get some feedback/testers. The tarball is for *linux only* clients (a good number of optimizations have not been tested on other platforms and there are already known issues, particularly in respect to pd.tk file). Some of the notable improvements include much faster editor (instead of redrawing we tag and move objects wherever possible while still allowing for legacy movement of objects not conforming to the pd vanilla gobj_displace format), bunch of usability improvements (e.g. custom color picker with color storing and hex editing), per-canvas toggling of menu and background color (see Abstractions), universal shortcuts, different scrolling algorithm. Likewise, the UI is entirely revamped to better fit the Gnome-ish feel. Jack connectivity algorithm also is automated and compensates for changes in srate, etc. At any rate, there are bunch of other little/big fixes I honestly cannot recall. These improvements are a product of a year of use within the context of a 15-member laptop orchestra taking into an account feedback from students/participants, including also my latest hac-a-thon this past week that involved overhauling redraw to improve editor speed. So, if any of you would be so kind as to give it a stab and provide any feedback, that would be most appreciated. You can get the latest snapshot from http://l2ork.music.vt.edu/main/?page_id=56 The source tarball also includes prebuilt binaries, so assuming you have an intel machine with Ubuntu 9.10, it should just run. (cd pd/bin/ followed by ./pd). Otherwise, you may have to rebuild it (standard pd-extended 0.42.x procedure). Your feedback, particularly bug-reports are most appreciated. Best wishes, Ico ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
On Thu, 25 Nov 2010, IOhannes m zmölnig wrote: - - something i think is only inherited from pd-extended, but whiich makes me shout out loud, is that when i start pd-l2ork it creates a pd-externals folder in my home directory. even if i don't do anything apart from opening! i think this is _very_ rude. Is it less rude if it creates «~/.pd-externals» (hidden) instead ? But then it becomes less visible to OSX users (?) (do they have that folder, again ?) ___ | Mathieu Bouchard - Aix-en-Provence ___ 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 Wed, 24 Nov 2010, João Pais wrote: e.g. I am right now thinking it would be nice to have resizable cnv just by clicking on its bottom-right corner. Ditto for other visual iemgui objects. Another thing I would really like to see soon is ability to box-select patch cords. Then perhaps an undo doubly-linked list would be nice as well (although not sure how hard this would be). basically many of the things possible in max should be implemented in pd. This is that kind of thinking that led me to invent [#many]. I looked at their matrix of toggle-like things and told myself I should make something similar, except it would have a much shorter list of properties, and a possibility to connect plugins (using an extra inlet and outlet) so that any special behaviour can be user-specified. And then I wanted a variable element-class, not just toggle. And thus it was born. Apart from that, many things can be made using [#see]-[#mouse] with various graphics processing in GF/GEM/PDP. [#see] displays a video in a patch, and the video can be tiny, generated, and rendered on demand (it's actually a picture viewer). This is most useful for high-color, pixel-oriented data, or really complicated vector data, perhaps. ___ | Mathieu Bouchard - Aix-en-Provence ___ 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=detailaid=1056914group_id=55736atid=478072 Also see: http://sourceforge.net/tracker/index.php?func=detailaid=2838176group_id=55736atid=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
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
On 11/27/10 10:36 AM, Mathieu Bouchard wrote: On Wed, 24 Nov 2010, Jonathan Wilkes wrote: Well, you could also go the other way and just get rid of the Find menu altogether. It's just the redundancy I'd like to get rid of the redudancy. :) Hi, this is James Martin Martin-James, from the Department of Repetitive Redundancy Department. But seriously, if you come to Canada, be ready to encounter our jars of sauce mayonnaise sauce, chips Doritos chips, and fromage kraft cheese. It's a way of life. Haha! Cafe Starbucks Coffee makes me laugh every time I see it. ___ 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, 11/27/10, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Saturday, November 27, 2010, 4:54 PM On Wed, 24 Nov 2010, Jonathan Wilkes wrote: Another solution: you can also place a checkbutton labeled Edit mode directly on the menubar. Is this compatible with OSX ? I don't know. I actually tried three things: 1) Leaving the 'Edit mode' entry in the 'Edit' menu, setting -indicatoron to false, and toggling the label from 'Edit mode' to 'Run mode' 2) Doing a checkbutton with an indicator right on the menubar 3) Doing a checkbutton with the indicator off right on the menubar and toggling the label as in #1 above. I think 1 and 3 worked fine in osx. Actually I also tried a fourth thing: Destroy the menubar when in 'Run mode'. (Not sure how that would work on osx, but in Gnome it sure makes an obvious distinction between modes!) -Jonathan ___ | Mathieu Bouchard - Aix-en-Provence ___ 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 Nov 25, 2010, at 2:35 AM, Ivica Ico Bukvic wrote: On Wed, 2010-11-24 at 22:46 -0500, Ivica Ico Bukvic wrote: On Thu, 2010-11-25 at 02:53 +0100, András Murányi wrote: moonlib indeed! 2010/11/25 Jonathan Wilkes jancs...@yahoo.com [moonlib/mknob] -Jonathan Thanks, this worked. Now i'm having segfaults on patch load, it seems it's with [moocow/mknob]. Confirmed. Looking into it... All right, I said I would go to sleep but the curiosity got the best of me, so I looked at this one and found a super-simple solution. Namely, it appears mknob uses g_all_guis.h and g_canvas.h, both of which have changed as a result of accelerated drawing of iemgui objects. A simple recompile of mknob (and likely other objects that may rely upon the same framework) apparently fixed the problem. That said, this like other non-standard externals does not utilize either highlight or accelerated motion (and thus falls back nicely on the old way of moving using coords). HTH BTW, Hans, is there a reason why pd-extended cannot find moonlib's help files? I tried importing, as well as invoking objects with moonlib/ prefix. How would one go about fixing this other than extending the default.pdsettings file? Gotta love it when your bug-hunt TODO list is finally empty (even if only for a couple of hours :-). Ico THe moonlib help patches work for me using Pd-extended 0.42.5 on Mac OS X 10.5.8. .hc http://at.or.at/hans/ ___ 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 Nov 25, 2010, at 3:37 PM, András Murányi wrote: 2010/11/25 Ivica Ico Bukvic i...@vt.edu On Wed, 2010-11-24 at 22:46 -0500, Ivica Ico Bukvic wrote: On Thu, 2010-11-25 at 02:53 +0100, András Murányi wrote: moonlib indeed! 2010/11/25 Jonathan Wilkes jancs...@yahoo.com [moonlib/mknob] -Jonathan Thanks, this worked. Now i'm having segfaults on patch load, it seems it's with [moocow/mknob]. Confirmed. Looking into it... All right, I said I would go to sleep but the curiosity got the best of me, so I looked at this one and found a super-simple solution. Namely, it appears mknob uses g_all_guis.h and g_canvas.h, both of which have changed as a result of accelerated drawing of iemgui objects. A simple recompile of mknob (and likely other objects that may rely upon the same framework) apparently fixed the problem. Alrite, my knowledge is just not enough to teach moonlib (which i have put into /extra) where the pd headers are. What shall i modify in its makefile? Andras The header install locations have changed in Pd 0.43, now all Pd headers are installed into /usr/include/pd, so if an external uses anything in addition to m_pd.h, then it'll need to include that location in the include path. .hc [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ 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)
-nosleep means Pd doesn't let go of the CPU, so it means your machine's CPU is more or less owned by Pd. .hc On Nov 25, 2010, at 8:30 PM, Ivica Ico Bukvic wrote: Why would you run it with nosleep? I am also not familiar with this option--what does it do? András Murányi muran...@gmail.com wrote: Namely, it appears mknob uses g_all_guis.h and g_canvas.h, both of which have changed as a result of accelerated drawing of iemgui objects. A simple recompile of mknob (and likely other objects that may rely upon the same framework) apparently fixed the problem. Alrite, my knowledge is just not enough to teach moonlib (which i have put into /extra) where the pd headers are. What shall i modify in its makefile? CFLAGS = -DPD -I../../src -Wall -W -g ...and it works! I have lots of 'consistency check failed: glist_findrtext' when running, plus sometimes 'tcl/tk error: unknown encoding yahoo' on the terminal. It seems somewhat faster than the father, but that could also be that i've compiled it for my CPU with 'march='. Somehow MIDI works on startup while with the father it doesn't (i have to check 'MIDI settings' each time). Sometimes it gets temporarily frozen where the father doesn't, for example upon editing, saving, and then closing a simple subpatch (no GOP, no externals in it), and then it throws out all the output that was delayed during the freeze - this doesn't happen with the father (afaik you need to use -nosleep to make it behave like this?), and throws some 'error: .x123456: no such object's. The GUI is pretty. Andras ___ 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
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
On Nov 25, 2010, at 1:18 PM, Ivica Ico Bukvic wrote: thanks for sharing. a couple of very minor remarks: - - your webpage froze firefox/iceweasel on my eeepc the first time i accessed it; i assume this is due to the animated tagcloud. is there any conceptual reason for maaking a navigation aid eat 100% on 2 cores? I wish I had an answer for you as the cloud is pure javascript and it works just fine on my MSI wind U100 netbook (single core with hyperthreading, so I guess you could call it Intel's fake 2 cores) as well as on my Android phone (where it is somewhat slow but does not impede the rest of the webpage). I would love to hear from the others as well regarding this, because if this problem is more widespread I will look into altering/replacing it with something else. once i managed to download it, i only played a few minutes with it, so.. - - when releasing tarballs you should get rid of the .svn folders; these hold a copy of all files, so you could reduce the size of the unpacked bundle to about 50% Unfortunately in my case it had no difference whatsoever as I've not used svn on this branch in some time. I believe the binaries are what is causing the tarball to be as large as it is. At any rate, I will reupload it without the .svn folder. - - the magnifying glass (i think you all refer to the Patch cord viewer (or cord inspector how i would call it) by this term), is a very nice feature. what i find weird is, that i can only switch to cord viewing when in edit mode; Ctrl-r in Run-mode simple doesn't do anything; i would expect to switch my patch into run mode if needed Well, this is the way original Sarlo's code works, so I haven't given it much thought until now. Now that you brought it up, I feel like the current design makes more sense as the cord monitoring undoubtedly saps some of the CPU and as such one would probably not want to run it in runtime/performance mode anyhow. OTOH if you are looking to monitor what passes through the cords, this in and of itself suggests you are likely troubleshooting something and as such are looking to edit the patch anyhow, so based on these two observations alone I would say the current behavior makes sense. Then again, I may be missing something here in which case I would certainly like to hear opinions from others as well. All that said, I like your term better. 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. - - the inlet highlighting (this looks more like a magnifying glass to me) is a nice idea but it doesn't really help yet. e.g. with objects that have more inlets then available width (e.g. [pix_info]) you still have the same problem as before (though a bit bigger); i also think that the magnification amount is a bit too small, but this might be due to my very small screen size (at first i wouldn't even notice a real difference then to the original connection cursor). it would probably be a good idea to let the user change the amount of magnification) Good idea. I'll add this to the todo (shouldn't be too hard--it really simply boils down to designing the edit menu and providing appropriate hooks). That said, what would be even better is simply adding a tooltip that reflects which inlet/outlet is selected and what it does. This was recently discussed and with the highlighting in place this would boil down to simply adding another two arrays to glist and filling them with per-object descriptors (this last part being the biggest pain as it would have to be added pd-wide). In the interim, it could simply check for null entries and ignoring those that have not been implemented. I think I'll take a stab at this one soon. There is a tooltip patch in the patch tracker from Günter Geiger. Its a good idea, but needs to be implemented differently, without changing the core data structures. I don't remember the details, but I think it shouldn't be hard to do. - - why is the default selection color orange/red? is this a pd- extended thing? for me this is very close to the error-indicating color red (e.g. when an object fails to create) Because I find it hard to discern between blue and black (selected vs. deselected) on such thin lines that constitute most of the gui and which occurs a lot more often than the red invalid objects. That said, I will up the width on the red objects which should solve this problem. Blue is the standard in all OSs I've used. But it wouldn't be hard to make it a preference. - - something i think is only inherited from pd-extended, but whiich makes me shout out loud, is that when i start pd-l2ork it creates a pd-externals folder in my home directory. even if i don't do anything apart from opening! i think this is _very_ rude. This is indeed inherited from pd-extended and I think we need to hear from Hans
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
Hi, Ivica Ico Bukvic wrote: [cut] Regarding selected color, any suggestion if one is to avoid default blue and current orange which is apparently not that good either? Maybe I've lost something, but any particular reason why you want to ger rid of the blue? I think most are used to it now-a-days. The orange is really uncomfortable IMHO. Lorenzo Best wishes, Ico ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
selecting the colour is a good option I think, but it's down to personal preference ;) On Fri, Nov 26, 2010 at 8:24 AM, Lorenzo Sutton lsut...@libero.it wrote: Hi, Ivica Ico Bukvic wrote: [cut] Regarding selected color, any suggestion if one is to avoid default blue and current orange which is apparently not that good either? Maybe I've lost something, but any particular reason why you want to ger rid of the blue? I think most are used to it now-a-days. The orange is really uncomfortable IMHO. Lorenzo Best wishes, Ico ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
AFAIK, with 0.43 this problem will be less serious as colors are easily changed with so-called plug-ins, i.e. tcl one-liners. BTW I like orange :o) Andras On Fri, Nov 26, 2010 at 10:39 AM, ALAN BROOKER alan.brooker2...@gmail.comwrote: selecting the colour is a good option I think, but it's down to personal preference ;) On Fri, Nov 26, 2010 at 8:24 AM, Lorenzo Sutton lsut...@libero.it wrote: Hi, Ivica Ico Bukvic wrote: [cut] Regarding selected color, any suggestion if one is to avoid default blue and current orange which is apparently not that good either? Maybe I've lost something, but any particular reason why you want to ger rid of the blue? I think most are used to it now-a-days. The orange is really uncomfortable IMHO. Lorenzo Best wishes, 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 Fri, 2010-11-26 at 16:59 +0100, András Murányi wrote: AFAIK, with 0.43 this problem will be less serious as colors are easily changed with so-called plug-ins, i.e. tcl one-liners. BTW I like orange :o) Thanks all for your feedback on this one. The problem as it stands right now is that iemgui objects use precompiled select colors in a non-standard format which makes it more difficult to make them customizable. I will look into this down the road but it seems to me as a lower priority task. As it turns out, I've had another productive couple of hours debugging and this time I've fixed one regression as well as two more show-stopping bugs related to GOP (NB: for pd core devs you may want to look into these as they are also present in both pd and pd-extended vanilla). Namely 20101126 snapshot includes: *cutting gop-ed patch while its canvas is open leaves stale gop rectangle *when moving gop-ed object, do not activate unless it is only clicked upon. When clicked upon, the object will shrink into an undefined object. All cord connections will be preserved. This avoids activating it when it is being dragged and thus also avoids a slew of redraw bugs that result from the following: 1) create a gop-ed patch (an abstraction) that has at least one vanilla object visible (e.g. a gatom) 2) select it and change its name to another existing gop-ed patch (other than one that was populating this object so far) 3) open the newly-created gop patcher and try creating a new object. You will get double of everything, eventually resulting in a crash (unless you cut the object and recreate it before closing) *double-entry after editing gop. (ALSO FIXES: *erasing gop's stale non-iemgui objects when editing). To reproduce this problem do the following: 1)create GOP 2)alter GOP's name into invalid or other object -seems like deleting old object does not go well when it uses gop-ed vanilla objects 3)alter it back 4)create object inside GOP *fixed regression in iemgui objects where highlight did not work on gop-ed canvases As usual, you can get it from: l2ork.music.vt.edu/main/?page_id=56 As always, feedback/bug-reports are most appreciated. Best wishes, 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)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2010 07:56 AM, Ivica Ico Bukvic wrote: OK, new snapshot 20101125 is now up with following fixes: thanks for sharing. a couple of very minor remarks: - - your webpage froze firefox/iceweasel on my eeepc the first time i accessed it; i assume this is due to the animated tagcloud. is there any conceptual reason for maaking a navigation aid eat 100% on 2 cores? once i managed to download it, i only played a few minutes with it, so.. - - when releasing tarballs you should get rid of the .svn folders; these hold a copy of all files, so you could reduce the size of the unpacked bundle to about 50% - - the magnifying glass (i think you all refer to the Patch cord viewer (or cord inspector how i would call it) by this term), is a very nice feature. what i find weird is, that i can only switch to cord viewing when in edit mode; Ctrl-r in Run-mode simple doesn't do anything; i would expect to switch my patch into run mode if needed - - the inlet highlighting (this looks more like a magnifying glass to me) is a nice idea but it doesn't really help yet. e.g. with objects that have more inlets then available width (e.g. [pix_info]) you still have the same problem as before (though a bit bigger); i also think that the magnification amount is a bit too small, but this might be due to my very small screen size (at first i wouldn't even notice a real difference then to the original connection cursor). it would probably be a good idea to let the user change the amount of magnification) - - why is the default selection color orange/red? is this a pd-extended thing? for me this is very close to the error-indicating color red (e.g. when an object fails to create) - - something i think is only inherited from pd-extended, but whiich makes me shout out loud, is that when i start pd-l2ork it creates a pd-externals folder in my home directory. even if i don't do anything apart from opening! i think this is _very_ rude. thuns up mfgaser IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzuLYQACgkQkX2Xpv6ydvTUVgCgng6CLahVMI1U4bUUNClV4Pwp PMgAoJbYiV1VNobn01IA4zcf6JOS0ICR =PlV/ -END PGP SIGNATURE- ___ 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)
thanks for sharing. a couple of very minor remarks: - - your webpage froze firefox/iceweasel on my eeepc the first time i accessed it; i assume this is due to the animated tagcloud. is there any conceptual reason for maaking a navigation aid eat 100% on 2 cores? I wish I had an answer for you as the cloud is pure javascript and it works just fine on my MSI wind U100 netbook (single core with hyperthreading, so I guess you could call it Intel's fake 2 cores) as well as on my Android phone (where it is somewhat slow but does not impede the rest of the webpage). I would love to hear from the others as well regarding this, because if this problem is more widespread I will look into altering/replacing it with something else. once i managed to download it, i only played a few minutes with it, so.. - - when releasing tarballs you should get rid of the .svn folders; these hold a copy of all files, so you could reduce the size of the unpacked bundle to about 50% Unfortunately in my case it had no difference whatsoever as I've not used svn on this branch in some time. I believe the binaries are what is causing the tarball to be as large as it is. At any rate, I will reupload it without the .svn folder. - - the magnifying glass (i think you all refer to the Patch cord viewer (or cord inspector how i would call it) by this term), is a very nice feature. what i find weird is, that i can only switch to cord viewing when in edit mode; Ctrl-r in Run-mode simple doesn't do anything; i would expect to switch my patch into run mode if needed Well, this is the way original Sarlo's code works, so I haven't given it much thought until now. Now that you brought it up, I feel like the current design makes more sense as the cord monitoring undoubtedly saps some of the CPU and as such one would probably not want to run it in runtime/performance mode anyhow. OTOH if you are looking to monitor what passes through the cords, this in and of itself suggests you are likely troubleshooting something and as such are looking to edit the patch anyhow, so based on these two observations alone I would say the current behavior makes sense. Then again, I may be missing something here in which case I would certainly like to hear opinions from others as well. All that said, I like your term better. - - the inlet highlighting (this looks more like a magnifying glass to me) is a nice idea but it doesn't really help yet. e.g. with objects that have more inlets then available width (e.g. [pix_info]) you still have the same problem as before (though a bit bigger); i also think that the magnification amount is a bit too small, but this might be due to my very small screen size (at first i wouldn't even notice a real difference then to the original connection cursor). it would probably be a good idea to let the user change the amount of magnification) Good idea. I'll add this to the todo (shouldn't be too hard--it really simply boils down to designing the edit menu and providing appropriate hooks). That said, what would be even better is simply adding a tooltip that reflects which inlet/outlet is selected and what it does. This was recently discussed and with the highlighting in place this would boil down to simply adding another two arrays to glist and filling them with per-object descriptors (this last part being the biggest pain as it would have to be added pd-wide). In the interim, it could simply check for null entries and ignoring those that have not been implemented. I think I'll take a stab at this one soon. - - why is the default selection color orange/red? is this a pd-extended thing? for me this is very close to the error-indicating color red (e.g. when an object fails to create) Because I find it hard to discern between blue and black (selected vs. deselected) on such thin lines that constitute most of the gui and which occurs a lot more often than the red invalid objects. That said, I will up the width on the red objects which should solve this problem. - - something i think is only inherited from pd-extended, but whiich makes me shout out loud, is that when i start pd-l2ork it creates a pd-externals folder in my home directory. even if i don't do anything apart from opening! i think this is _very_ rude. This is indeed inherited from pd-extended and I think we need to hear from Hans on this one as I certainly wish to maintain as much pd-extended compatibility as reasonably possible. Hans? Many thanks for your feedback! Best wishes, 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 Thu, 11/25/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: IOhannes m zmölnig zmoel...@iem.at Cc: pd-list@iem.at Date: Thursday, November 25, 2010, 7:18 PM thanks for sharing. a couple of very minor remarks: - - your webpage froze firefox/iceweasel on my eeepc the first time i accessed it; i assume this is due to the animated tagcloud. is there any conceptual reason for maaking a navigation aid eat 100% on 2 cores? I wish I had an answer for you as the cloud is pure javascript and it works just fine on my MSI wind U100 netbook (single core with hyperthreading, so I guess you could call it Intel's fake 2 cores) as well as on my Android phone (where it is somewhat slow but does not impede the rest of the webpage). I would love to hear from the others as well regarding this, because if this problem is more widespread I will look into altering/replacing it with something else. once i managed to download it, i only played a few minutes with it, so.. - - when releasing tarballs you should get rid of the .svn folders; these hold a copy of all files, so you could reduce the size of the unpacked bundle to about 50% Unfortunately in my case it had no difference whatsoever as I've not used svn on this branch in some time. I believe the binaries are what is causing the tarball to be as large as it is. At any rate, I will reupload it without the .svn folder. - - the magnifying glass (i think you all refer to the Patch cord viewer (or cord inspector how i would call it) by this term), is a very nice feature. what i find weird is, that i can only switch to cord viewing when in edit mode; Ctrl-r in Run-mode simple doesn't do anything; i would expect to switch my patch into run mode if needed Well, this is the way original Sarlo's code works, so I haven't given it much thought until now. Now that you brought it up, I feel like the current design makes more sense as the cord monitoring undoubtedly saps some of the CPU and as such one would probably not want to run it in runtime/performance mode anyhow. OTOH if you are looking to monitor what passes through the cords, this in and of itself suggests you are likely troubleshooting something and as such are looking to edit the patch anyhow, so based on these two observations alone I would say the current behavior makes sense. Then again, I may be missing something here in which case I would certainly like to hear opinions from others as well. All that said, I like your term better. - - the inlet highlighting (this looks more like a magnifying glass to me) is a nice idea but it doesn't really help yet. e.g. with objects that have more inlets then available width (e.g. [pix_info]) you still have the same problem as before (though a bit bigger); i also think that the magnification amount is a bit too small, but this might be due to my very small screen size (at first i wouldn't even notice a real difference then to the original connection cursor). it would probably be a good idea to let the user change the amount of magnification) Good idea. I'll add this to the todo (shouldn't be too hard--it really simply boils down to designing the edit menu and providing appropriate hooks). That said, what would be even better is simply adding a tooltip that reflects which inlet/outlet is selected and what it does. This was recently discussed and with the highlighting in place this would boil down to simply adding another two arrays to glist and filling them with per-object descriptors (this last part being the biggest pain as it would have to be added pd-wide). In the interim, it could simply check for null entries and ignoring those that have not been implemented. 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=detailaid=1056914group_id=55736atid=478072 Also see: http://sourceforge.net/tracker/index.php?func=detailaid=2838176group_id=55736atid=478072 - - why is the default selection color orange/red? is this a pd-extended thing? for me this is very close to the error-indicating color red (e.g. when an object fails to create) Because I find it hard to discern between blue and black (selected vs. deselected) on such thin lines that constitute most of the gui and which occurs a lot more often than the red invalid objects. That said, I will up the width on the red objects which should solve this problem. I find the orange text _very_ difficult to read. - - something i think is only inherited from pd-extended, but whiich makes me shout out loud, is that when i start pd-l2ork it creates a pd-externals folder in my home directory. even if i don't do
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
2010/11/25 Ivica Ico Bukvic i...@vt.edu On Wed, 2010-11-24 at 22:46 -0500, Ivica Ico Bukvic wrote: On Thu, 2010-11-25 at 02:53 +0100, András Murányi wrote: moonlib indeed! 2010/11/25 Jonathan Wilkes jancs...@yahoo.com [moonlib/mknob] -Jonathan Thanks, this worked. Now i'm having segfaults on patch load, it seems it's with [moocow/mknob]. Confirmed. Looking into it... All right, I said I would go to sleep but the curiosity got the best of me, so I looked at this one and found a super-simple solution. Namely, it appears mknob uses g_all_guis.h and g_canvas.h, both of which have changed as a result of accelerated drawing of iemgui objects. A simple recompile of mknob (and likely other objects that may rely upon the same framework) apparently fixed the problem. Alrite, my knowledge is just not enough to teach moonlib (which i have put into /extra) where the pd headers are. What shall i modify in its makefile? Andras ___ 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)
OK, new tarball is up (same file name as it is still technically the same date). Changes include: *changed magic tool name to Cord Inspector as per Iohannes' suggestion *made invalid dotted (red) objects have thicker border and red-ish background to make them more noticeable (also based on Iohannes' feedback) http://l2ork.music.vt.edu/main/?page_id=56 Regarding selected color, any suggestion if one is to avoid default blue and current orange which is apparently not that good either? Best wishes, 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)
Namely, it appears mknob uses g_all_guis.h and g_canvas.h, both of which have changed as a result of accelerated drawing of iemgui objects. A simple recompile of mknob (and likely other objects that may rely upon the same framework) apparently fixed the problem. Alrite, my knowledge is just not enough to teach moonlib (which i have put into /extra) where the pd headers are. What shall i modify in its makefile? CFLAGS = -DPD -I../../src -Wall -W -g ...and it works! I have lots of 'consistency check failed: glist_findrtext' when running, plus sometimes 'tcl/tk error: unknown encoding yahoo' on the terminal. It seems somewhat faster than the father, but that could also be that i've compiled it for my CPU with 'march='. Somehow MIDI works on startup while with the father it doesn't (i have to check 'MIDI settings' each time). Sometimes it gets temporarily frozen where the father doesn't, for example upon editing, saving, and then closing a simple subpatch (no GOP, no externals in it), and then it throws out all the output that was delayed during the freeze - this doesn't happen with the father (afaik you need to use -nosleep to make it behave like this?), and throws some 'error: .x123456: no such object's. The GUI is pretty. Andras ___ 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)
Why would you run it with nosleep? I am also not familiar with this option--what does it do? András Murányi muran...@gmail.com wrote: Namely, it appears mknob uses g_all_guis.h and g_canvas.h, both of which have changed as a result of accelerated drawing of iemgui objects. A simple recompile of mknob (and likely other objects that may rely upon the same framework) apparently fixed the problem. Alrite, my knowledge is just not enough to teach moonlib (which i have put into /extra) where the pd headers are. What shall i modify in its makefile? CFLAGS = -DPD -I../../src -Wall -W -g ...and it works! I have lots of 'consistency check failed: glist_findrtext' when running, plus sometimes 'tcl/tk error: unknown encoding yahoo' on the terminal. It seems somewhat faster than the father, but that could also be that i've compiled it for my CPU with 'march='. Somehow MIDI works on startup while with the father it doesn't (i have to check 'MIDI settings' each time). Sometimes it gets temporarily frozen where the father doesn't, for example upon editing, saving, and then closing a simple subpatch (no GOP, no externals in it), and then it throws out all the output that was delayed during the freeze - this doesn't happen with the father (afaik you need to use -nosleep to make it behave like this?), and throws some 'error: .x123456: no such object's. The GUI is pretty. Andras ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
No, i wouldn't! I just had a vague memory that this behaviour (doing all the delayed calculations at once after a freeze) resembles -nosleep's behaviour (doing all the delayed calculations at once after a system sleep), but i may completely mistaken. Andras 2010/11/26 Ivica Ico Bukvic i...@vt.edu Why would you run it with nosleep? I am also not familiar with this option--what does it do? András Murányi muran...@gmail.com wrote: Namely, it appears mknob uses g_all_guis.h and g_canvas.h, both of which have changed as a result of accelerated drawing of iemgui objects. A simple recompile of mknob (and likely other objects that may rely upon the same framework) apparently fixed the problem. Alrite, my knowledge is just not enough to teach moonlib (which i have put into /extra) where the pd headers are. What shall i modify in its makefile? CFLAGS = -DPD -I../../src -Wall -W -g ...and it works! I have lots of 'consistency check failed: glist_findrtext' when running, plus sometimes 'tcl/tk error: unknown encoding yahoo' on the terminal. It seems somewhat faster than the father, but that could also be that i've compiled it for my CPU with 'march='. Somehow MIDI works on startup while with the father it doesn't (i have to check 'MIDI settings' each time). Sometimes it gets temporarily frozen where the father doesn't, for example upon editing, saving, and then closing a simple subpatch (no GOP, no externals in it), and then it throws out all the output that was delayed during the freeze - this doesn't happen with the father (afaik you need to use -nosleep to make it behave like this?), and throws some 'error: .x123456: no such object's. The GUI is pretty. Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Muranyi Andras ___ 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)
Actually, just discovered 3 more minor but nonetheless buggy behaviors that caused extraneous pdtk_canvas_getscroll calls as well as console errors (thankfully these were not show-stoppers). Now pd with or without debugging should output no errors to the console (at least not using vanilla objects). NB: for the 0.43 devs this has also resulted in a change to the pdtk_canvas_getscroll function requiring another alteration to the new scrolling algorithm patch-bundle I submitted to the Sourceforge a while ago. Re-uploaded version now available. Happy Thanksgiving! 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 Fri, 2010-11-26 at 02:44 +0100, András Murányi wrote: No, i wouldn't! I just had a vague memory that this behaviour (doing all the delayed calculations at once after a freeze) resembles -nosleep's behaviour (doing all the delayed calculations at once after a system sleep), but i may completely mistaken. I see. As it turns out I did discover consistency check errors which have to do with the new way iemgui objects tag their inlets and outlets to make them highlight-compliant. It seems that GOP-ed objects should not call glist_findrtext which is triggering this error as a bug (even though iemgui's new code gracefully falls back to a secondary option). I've now implemented a pre-check so that we never even call findrtext if we are an iemgui object drawn as part of GOP. All this said, I've not encountered any burst-like slowdowns except when moving tons of objects simultaneously which was even more problematic in the old iteration due to the amount of socket traffic. What is really weird is the following: 1) try using any of your complex GOP abstractions and add one to a blank patch and try to move it around 2) in my case movement is rather choppy (understandably so as GOP even in l2ork iteration still relies upon coords calls rather than move-by-tagging) 3) *however*, when one selects and duplicates the same abstraction so that there are now two of them, suddenly performance is (at least on my machine--msi wind u100 with atom 1.6GHz procesor) amazingly smooth which goes against all logic Anyone else experiencing the same and/or have a logical explanation for this? Latest snapshot can be found in the usual place: 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
Hi Ico Ive got it working and have loaded some libraries, Gem, Gridflow, Zexy, pdp - however PD crashes out when I ctrl-1 to put an object on the canvas. I've done a backtrace (thanks Mathieu for the tip previously) with the following results: Starting program: /usr/local/bin/pd -oss -channels 2 my-bug-test.pd [Thread debugging using libthread_db enabled] init : Avifile RELEASE-0.7.48-100119-21:44-../src/configure init : 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 init : 800.00 MHz AMD Phenom(tm) II X2 555 Processor detected [New Thread 0xb47e1b70 (LWP 4084)] Program received signal SIGSEGV, Segmentation fault. 0x0011 in ?? () (gdb) where #0 0x0011 in ?? () #1 0x080a94d5 in gobj_displace_withtag (x=0x8206cb8, dx=value optimised out, dy=0) at g_editor.c:68 #2 canvas_displaceselection (x=0x8206cb8, dx=value optimised out, dy=0) at g_editor.c:1900 #3 0x080a98a5 in canvas_motion (x=0x8206cb8, xpos=232, ypos=76, fmod=2) at g_editor.c:2089 #4 0x080ca4f6 in pd_typedmess (x=0x8206cb8, s=0x8135eb8, argc=3, argv=0xb08c) at m_class.c:792 #5 0x080ca0dc in pd_typedmess (x=0x814ac60, s=0x8135eb8, argc=3, argv=0xb08c) at m_class.c:813 #6 0x080cfbaa in binbuf_eval (x=0x8149688, target=value optimised out, argc=0, argv=0x0) at m_binbuf.c:726 #7 0x080dde5f in socketreceiver_read (x=0x81496a8, fd=6) at s_inter.c:560 #8 0x080dd81a in sys_domicrosleep (microsec=value optimised out, pollem=value optimised out) at s_inter.c:198 #9 0x080de502 in sys_pollgui () at s_inter.c:862 #10 0x080d9321 in m_pollingscheduler () at m_sched.c:490 #11 m_mainloop () at m_sched.c:560 #12 0x080dc8a9 in sys_main (argc=5, argv=0xb4e4) at s_main.c:310 #13 0x080e556b in main (argc=5, argv=0xb4e4) at s_entry.c:32 (gdb) quit A debugging session is active. Inferior 1 [process 4078] will be killed. Quit anyway? (y or n) y socket receive error: Connection reset by peer (104) Thanks for your help with this! It's a great package to work from Cheers On Wed, Nov 24, 2010 at 5:29 AM, Ivica Ico Bukvic i...@vt.edu wrote: Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue). Good to know. I will look into this when I get there. Currently working on accelerating iemgui objects as well as exposing them to sarlo's highlighting magic. Wouldn't it be easier just to toggle the text for that menu option between Edit mode and Run mode? (That's what they're called in the manual.) Sure. There are other options, too, like the one 0.43 and now l2ork version of 0.42 uses by changing option's background which works visually relatively well (albeit at the expense of consistency). This is however not the issue. The issue is finding out that after an hour of debugging the problem is not in you or your code but the toolkit you are using and in 2010 for a toolkit that has been around for more than a decade that is plainly sad. How would you go about doing that? A: Ugly path: Isolate pd-gui hooks and port the entire thing to Qt. B: Better (albeit more time-consuming) path: clean-up code first so that all objects can utilize the same gobj_whatever calls and then do the A: (which at that point won't be nearly as ugly or difficult to maintain). FWIW, my first ever GUI app was RTMix I did back in 2001 and it was (and remains) the ugliest hack ever (basically I tried to learn how to program doing that app). Yet, the fact remains even in 2001 qt was way better than what Tk is today. Another advantage is avoiding socket bottlenecks as the entire thing could be done simply in C. License-wise it should be fine and cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for good measure since that is apparently hot item these days. That said, I need some more time working with Pd code before I can undertake this. Perhaps more importantly, I just need a generous, uninterrupted chunk of time to do this. Best wishes, Ico ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
Hi Just to clarify the message Program received signal SIGSEGV, Segmentation fault. 0x0011 in ?? () is printed on the terminal when ctrl-1 is used Thanks again On Wed, Nov 24, 2010 at 10:11 AM, ALAN BROOKER alan.brooker2...@gmail.comwrote: Hi Ico Ive got it working and have loaded some libraries, Gem, Gridflow, Zexy, pdp - however PD crashes out when I ctrl-1 to put an object on the canvas. I've done a backtrace (thanks Mathieu for the tip previously) with the following results: Starting program: /usr/local/bin/pd -oss -channels 2 my-bug-test.pd [Thread debugging using libthread_db enabled] init : Avifile RELEASE-0.7.48-100119-21:44-../src/configure init : 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 init : 800.00 MHz AMD Phenom(tm) II X2 555 Processor detected [New Thread 0xb47e1b70 (LWP 4084)] Program received signal SIGSEGV, Segmentation fault. 0x0011 in ?? () (gdb) where #0 0x0011 in ?? () #1 0x080a94d5 in gobj_displace_withtag (x=0x8206cb8, dx=value optimised out, dy=0) at g_editor.c:68 #2 canvas_displaceselection (x=0x8206cb8, dx=value optimised out, dy=0) at g_editor.c:1900 #3 0x080a98a5 in canvas_motion (x=0x8206cb8, xpos=232, ypos=76, fmod=2) at g_editor.c:2089 #4 0x080ca4f6 in pd_typedmess (x=0x8206cb8, s=0x8135eb8, argc=3, argv=0xb08c) at m_class.c:792 #5 0x080ca0dc in pd_typedmess (x=0x814ac60, s=0x8135eb8, argc=3, argv=0xb08c) at m_class.c:813 #6 0x080cfbaa in binbuf_eval (x=0x8149688, target=value optimised out, argc=0, argv=0x0) at m_binbuf.c:726 #7 0x080dde5f in socketreceiver_read (x=0x81496a8, fd=6) at s_inter.c:560 #8 0x080dd81a in sys_domicrosleep (microsec=value optimised out, pollem=value optimised out) at s_inter.c:198 #9 0x080de502 in sys_pollgui () at s_inter.c:862 #10 0x080d9321 in m_pollingscheduler () at m_sched.c:490 #11 m_mainloop () at m_sched.c:560 #12 0x080dc8a9 in sys_main (argc=5, argv=0xb4e4) at s_main.c:310 #13 0x080e556b in main (argc=5, argv=0xb4e4) at s_entry.c:32 (gdb) quit A debugging session is active. Inferior 1 [process 4078] will be killed. Quit anyway? (y or n) y socket receive error: Connection reset by peer (104) Thanks for your help with this! It's a great package to work from Cheers On Wed, Nov 24, 2010 at 5:29 AM, Ivica Ico Bukvic i...@vt.edu wrote: Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue). Good to know. I will look into this when I get there. Currently working on accelerating iemgui objects as well as exposing them to sarlo's highlighting magic. Wouldn't it be easier just to toggle the text for that menu option between Edit mode and Run mode? (That's what they're called in the manual.) Sure. There are other options, too, like the one 0.43 and now l2ork version of 0.42 uses by changing option's background which works visually relatively well (albeit at the expense of consistency). This is however not the issue. The issue is finding out that after an hour of debugging the problem is not in you or your code but the toolkit you are using and in 2010 for a toolkit that has been around for more than a decade that is plainly sad. How would you go about doing that? A: Ugly path: Isolate pd-gui hooks and port the entire thing to Qt. B: Better (albeit more time-consuming) path: clean-up code first so that all objects can utilize the same gobj_whatever calls and then do the A: (which at that point won't be nearly as ugly or difficult to maintain). FWIW, my first ever GUI app was RTMix I did back in 2001 and it was (and remains) the ugliest hack ever (basically I tried to learn how to program doing that app). Yet, the fact remains even in 2001 qt was way better than what Tk is today. Another advantage is avoiding socket bottlenecks as the entire thing could be done simply in C. License-wise it should be fine and cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for good measure since that is apparently hot item these days. That said, I need some more time working with Pd code before I can undertake this. Perhaps more importantly, I just need a generous, uninterrupted chunk of time to do this. Best wishes, Ico ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
Okay- I've traced to Gridflow library- I've taken it out and no crashes -any tips how I can have it installed would be appreciated- thanks again for your time on this :) On Wed, Nov 24, 2010 at 12:57 PM, Ivica Ico Bukvic i...@vt.edu wrote: Try loading one lib at a time and doing the same. I don't know for sure but it might be that one or more of them is having issues with the new move algorithm. ALAN BROOKER alan.brooker2...@gmail.com wrote: Hi Just to clarify the message Program received signal SIGSEGV, Segmentation fault. 0x0011 in ?? () is printed on the terminal when ctrl-1 is used Thanks again On Wed, Nov 24, 2010 at 10:11 AM, ALAN BROOKER alan.brooker2...@gmail.comwrote: Hi Ico Ive got it working and have loaded some libraries, Gem, Gridflow, Zexy, pdp - however PD crashes out when I ctrl-1 to put an object on the canvas. I've done a backtrace (thanks Mathieu for the tip previously) with the following results: Starting program: /usr/local/bin/pd -oss -channels 2 my-bug-test.pd [Thread debugging using libthread_db enabled] init : Avifile RELEASE-0.7.48-100119-21:44-../src/configure init : 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 init : 800.00 MHz AMD Phenom(tm) II X2 555 Processor detected [New Thread 0xb47e1b70 (LWP 4084)] Program received signal SIGSEGV, Segmentation fault. 0x0011 in ?? () (gdb) where #0 0x0011 in ?? () #1 0x080a94d5 in gobj_displace_withtag (x=0x8206cb8, dx=value optimised out, dy=0) at g_editor.c:68 #2 canvas_displaceselection (x=0x8206cb8, dx=value optimised out, dy=0) at g_editor.c:1900 #3 0x080a98a5 in canvas_motion (x=0x8206cb8, xpos=232, ypos=76, fmod=2) at g_editor.c:2089 #4 0x080ca4f6 in pd_typedmess (x=0x8206cb8, s=0x8135eb8, argc=3, argv=0xb08c) at m_class.c:792 #5 0x080ca0dc in pd_typedmess (x=0x814ac60, s=0x8135eb8, argc=3, argv=0xb08c) at m_class.c:813 #6 0x080cfbaa in binbuf_eval (x=0x8149688, target=value optimised out, argc=0, argv=0x0) at m_binbuf.c:726 #7 0x080dde5f in socketreceiver_read (x=0x81496a8, fd=6) at s_inter.c:560 #8 0x080dd81a in sys_domicrosleep (microsec=value optimised out, pollem=value optimised out) at s_inter.c:198 #9 0x080de502 in sys_pollgui () at s_inter.c:862 #10 0x080d9321 in m_pollingscheduler () at m_sched.c:490 #11 m_mainloop () at m_sched.c:560 #12 0x080dc8a9 in sys_main (argc=5, argv=0xb4e4) at s_main.c:310 #13 0x080e556b in main (argc=5, argv=0xb4e4) at s_entry.c:32 (gdb) quit A debugging session is active. Inferior 1 [process 4078] will be killed. Quit anyway? (y or n) y socket receive error: Connection reset by peer (104) Thanks for your help with this! It's a great package to work from Cheers On Wed, Nov 24, 2010 at 5:29 AM, Ivica Ico Bukvic i...@vt.edu wrote: Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue). Good to know. I will look into this when I get there. Currently working on accelerating iemgui objects as well as exposing them to sarlo's highlighting magic. Wouldn't it be easier just to toggle the text for that menu option between Edit mode and Run mode? (That's what they're called in the manual.) Sure. There are other options, too, like the one 0.43 and now l2ork version of 0.42 uses by changing option's background which works visually relatively well (albeit at the expense of consistency). This is however not the issue. The issue is finding out that after an hour of debugging the problem is not in you or your code but the toolkit you are using and in 2010 for a toolkit that has been around for more than a decade that is plainly sad. How would you go about doing that? A: Ugly path: Isolate pd-gui hooks and port the entire thing to Qt. B: Better (albeit more time-consuming) path: clean-up code first so that all objects can utilize the same gobj_whatever calls and then do the A: (which at that point won't be nearly as ugly or difficult to maintain). FWIW, my first ever GUI app was RTMix I did back in 2001 and it was (and remains) the ugliest hack ever (basically I tried to learn how to program doing that app). Yet, the fact remains even in 2001 qt was way better than what Tk is today. Another advantage is avoiding socket bottlenecks as the entire thing could be done simply in C. License-wise it should be fine and cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for good measure since
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
Unfortunately not at this point in time as I've not tested my stuff with gridflow at all yet (it is on my TODO). Perhaps Mathieu might have some suggestions? Mathieu, AFAIK in l2ork iteration of pd-extended the only thing that changed fundamentally pd-wide is widgetbehavior got another entry at the end. BTW, this may seem a bit of a silly question but just to be safe, you did try the same gridflow lib with the regular vanilla pd you used prior to l2ork iteration and if so did it work there? Cheers! On Wed, 2010-11-24 at 16:39 +, ALAN BROOKER wrote: Okay- I've traced to Gridflow library- I've taken it out and no crashes -any tips how I can have it installed would be appreciated- thanks again for your time on this :) On Wed, Nov 24, 2010 at 12:57 PM, Ivica Ico Bukvic i...@vt.edu wrote: Try loading one lib at a time and doing the same. I don't know for sure but it might be that one or more of them is having issues with the new move algorithm. ALAN BROOKER alan.brooker2...@gmail.com wrote: Hi Just to clarify the message Program received signal SIGSEGV, Segmentation fault. 0x0011 in ?? () is printed on the terminal when ctrl-1 is used Thanks again On Wed, Nov 24, 2010 at 10:11 AM, ALAN BROOKER alan.brooker2...@gmail.comwrote: Hi Ico Ive got it working and have loaded some libraries, Gem, Gridflow, Zexy, pdp - however PD crashes out when I ctrl-1 to put an object on the canvas. I've done a backtrace (thanks Mathieu for the tip previously) with the following results: Starting program: /usr/local/bin/pd -oss -channels 2 my-bug-test.pd [Thread debugging using libthread_db enabled] init : Avifile RELEASE-0.7.48-100119-21:44-../src/configure init : 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 init : 800.00 MHz AMD Phenom(tm) II X2 555 Processor detected [New Thread 0xb47e1b70 (LWP 4084)] Program received signal SIGSEGV, Segmentation fault. 0x0011 in ?? () (gdb) where #0 0x0011 in ?? () #1 0x080a94d5 in gobj_displace_withtag (x=0x8206cb8, dx=value optimised out, dy=0) at g_editor.c:68 #2 canvas_displaceselection (x=0x8206cb8, dx=value optimised out, dy=0) at g_editor.c:1900 #3 0x080a98a5 in canvas_motion (x=0x8206cb8, xpos=232, ypos=76, fmod=2) at g_editor.c:2089 #4 0x080ca4f6 in pd_typedmess (x=0x8206cb8, s=0x8135eb8, argc=3, argv=0xb08c) at m_class.c:792 #5 0x080ca0dc in pd_typedmess (x=0x814ac60, s=0x8135eb8, argc=3, argv=0xb08c) at m_class.c:813 #6 0x080cfbaa in binbuf_eval (x=0x8149688, target=value optimised out, argc=0, argv=0x0) at m_binbuf.c:726 #7 0x080dde5f in socketreceiver_read (x=0x81496a8, fd=6) at s_inter.c:560 #8 0x080dd81a in sys_domicrosleep (microsec=value optimised out, pollem=value optimised out) at s_inter.c:198 #9 0x080de502 in sys_pollgui () at s_inter.c:862 #10 0x080d9321 in m_pollingscheduler () at m_sched.c:490 #11 m_mainloop () at m_sched.c:560 #12 0x080dc8a9 in sys_main (argc=5, argv=0xb4e4) at s_main.c:310 #13 0x080e556b in main (argc=5, argv=0xb4e4) at s_entry.c:32 (gdb) quit A debugging session is active. Inferior 1 [process 4078] will be killed. Quit anyway? (y or n) y socket receive error: Connection reset by peer (104) Thanks for your help with this! It's a great package to work from Cheers On Wed, Nov 24, 2010 at 5:29 AM, Ivica Ico Bukvic i...@vt.edu wrote: Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue). Good to know. I will look into this when I get there. Currently working on accelerating iemgui objects as well as exposing them to sarlo's highlighting magic.
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
OK, latest snapshot 20101124 has been just made available in the usual place with additional improvements including: *all vanilla and iemgui objects are now accelerated in terms of their redrawing and moving, resulting in a dramatic improvement in UI responsiveness (for the devs, the new model uses tagging of widgets and move command, rather than apparently a much more cpu expensive coords call) *sarlo's magic highlighter now works on all iem objects as well as gop objects *more cosmetic bug fixes http://l2ork.music.vt.edu/main/?page_id=56 As always, feedback is most appreciated! Best wishes, 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 Nov 24, 2010, at 12:29 AM, Ivica Ico Bukvic wrote: Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue). Good to know. I will look into this when I get there. Currently working on accelerating iemgui objects as well as exposing them to sarlo's highlighting magic. I just realize that there are two iemgui libs in a sense: there are the iemgui objects that have been included in Pd-vanilla for 10 years, those are the ones I was referring to. Then there is the new iemgui library in pure-data SVN, I know little about that one. Which one are you referring to? Wouldn't it be easier just to toggle the text for that menu option between Edit mode and Run mode? (That's what they're called in the manual.) Sure. There are other options, too, like the one 0.43 and now l2ork version of 0.42 uses by changing option's background which works visually relatively well (albeit at the expense of consistency). This is however not the issue. The issue is finding out that after an hour of debugging the problem is not in you or your code but the toolkit you are using and in 2010 for a toolkit that has been around for more than a decade that is plainly sad. FYI, 0.43 fixes this issue by changing the 'editmode' message so that 1 means editmode is on, and 0 means editmode is off. Before that, the 'editmode' message toggled edit mode. That's what made it so difficult to make the menu item checkbox work. These are the kinds of things that I have spent many many hours working to fix, so it makes me sad to see you reinventing the wheel. Also, since everything is always running in Pd, I'd much prefer to see it called Edit Mode and Play Mode. How would you go about doing that? A: Ugly path: Isolate pd-gui hooks and port the entire thing to Qt. B: Better (albeit more time-consuming) path: clean-up code first so that all objects can utilize the same gobj_whatever calls and then do the A: (which at that point won't be nearly as ugly or difficult to maintain). FWIW, my first ever GUI app was RTMix I did back in 2001 and it was (and remains) the ugliest hack ever (basically I tried to learn how to program doing that app). Yet, the fact remains even in 2001 qt was way better than what Tk is today. Another advantage is avoiding socket bottlenecks as the entire thing could be done simply in C. License-wise it should be fine and cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for good measure since that is apparently hot item these days. That said, I need some more time working with Pd code before I can undertake this. Perhaps more importantly, I just need a generous, uninterrupted chunk of time to do this. Peter Brinkmann, Peter Kirn, Miller and I all had a meeting recently to discuss the idea of making 'pd' a separate entity. My part is making pd talk to pd-gui using pd messages, then it should be pretty straightforward to making new GUIs in lots of different toolkits. .hc Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ 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 just realize that there are two iemgui libs in a sense: there are the iemgui objects that have been included in Pd-vanilla for 10 years, those are the ones I was referring to. Then there is the new iemgui library in pure-data SVN, I know little about that one. Which one are you referring to? I am referring to the one that has been a part of pd for a long time. This is the one I just updated in the latest release so that moving of its widgets in edit mode is now a part of a single move-by-tag call. I am actually quite pleased how it works now. FYI, 0.43 fixes this issue by changing the 'editmode' message so that 1 means editmode is on, and 0 means editmode is off. Before that, the 'editmode' message toggled edit mode. That's what made it so difficult to make the menu item checkbox work. These are the kinds of things that I have spent many many hours working to fix, so it makes me sad to see you reinventing the wheel. I am not reinventing wheel in this case but simply backporting your solution (unless you are referring to me wasting hours as you did on the Tcl widget bug as the actual reinventing of the wheel). Either way, the checkmark next to the checkbutton widget is simply buggy and does not show up when it should (e.g. when invoking the widget). This is the case even with 0.43 gui rewrite. The only way one can see that the option has been activated on 0.43 (and now on l2ork iteration of 0.42) is by the fact edit mode option in the menu has changed its background color to green (which actually does not look all that bad, even though it is inconsistent with general menu UI guidelines Tcl/Tk is supposedly trying so hard to enforce). Peter Brinkmann, Peter Kirn, Miller and I all had a meeting recently to discuss the idea of making 'pd' a separate entity. My part is making pd talk to pd-gui using pd messages, then it should be pretty straightforward to making new GUIs in lots of different toolkits. As long as those messages are not something that needs to be sent via socket but can be also prototyped into direct function calls within C. Otherwise, the solution simply perpetuates the existing problem of socket and string parser saturation, resulting in very slow performance. Notice that even with l2ork iteration of pd-extended where everything vanilla now uses move-by-tag approach (in other words one call moves all selected widgets except for GOPs which are quite messy thus resulting in one call vs. potentially hundreds if not thousands) and which ostensibly approaches ideal performance via socket, it still gets relatively easily bogged down due to inherent overhead. Best wishes, 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 Wed, Nov 24, 2010 at 6:40 PM, Ivica Ico Bukvic i...@vt.edu wrote: OK, latest snapshot 20101124 has been just made available in the usual place with additional improvements including: *all vanilla and iemgui objects are now accelerated in terms of their redrawing and moving, resulting in a dramatic improvement in UI responsiveness (for the devs, the new model uses tagging of widgets and move command, rather than apparently a much more cpu expensive coords call) *sarlo's magic highlighter now works on all iem objects as well as gop objects *more cosmetic bug fixes http://l2ork.music.vt.edu/main/?page_id=56 As always, feedback is most appreciated! Best wishes, Ico personal thoughts, never mind First i wish to say i had my doubts but now i'm happy to see an iteration of pd-extended in the wild. One may say there is some waste of time with a fork like this and of course there is, but it also proves pd-extended to be 'adult' in a way and adults may have children, and children may seem to reinvent the wheel sometimes but that's all right and that's the way they can find their new, hopefully better ways. And meanwhile, hopefully, many thing will go upstream and it will be a big happy family :o) I'm particularly interested in better GUIs operating a well separated core, and happy to see Hans Miller al are advancing in this direction! /personal thoughts, never mind I'm on AMD64 and has run into this with 'make': cd ../obj; cc -Wl,-export-dynamic -lasound -lrt -ljack -o ../bin/pd d_ctl.o d_array.o d_delay.o d_filter.o d_math.o d_osc.o d_soundfile.o g_canvas.o g_graph.o g_text.o g_rtext.o g_array.o g_template.o g_io.o g_scalar.o g_traversal.o g_guiconnect.o g_readwrite.o g_editor.o g_all_guis.o g_bang.o g_hdial.o g_hslider.o g_mycanvas.o g_numbox.o g_toggle.o g_vdial.o g_vslider.o g_vumeter.o g_magicglass.o m_pd.o m_class.o m_obj.o m_atom.o m_memory.o m_binbuf.o m_conf.o m_glob.o m_sched.o s_main.o s_inter.o s_file.o s_print.o s_loader.o s_path.o s_entry.o s_audio.o s_midi.o d_ugen.o d_arithmetic.o d_dac.o d_misc.o d_fft.o d_global.o d_resample.o x_arithmetic.o x_connective.o x_interface.o x_midi.o x_misc.o x_time.o x_acoustics.o x_net.o x_qlist.o x_gui.o x_list.o import.o s_midi_oss.o s_audio_oss.o s_audio_alsa.o s_audio_alsamm.o s_midi_alsa.o s_audio_jack.o d_fft_mayer.o d_fftroutine.o -ldl -lm -lpthread -lasound collect2: ld terminated with signal 11 [Segmentation fault] /usr/bin/ld: i386 architecture of input file `d_ctl.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_array.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_delay.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_filter.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_math.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_osc.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_canvas.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_graph.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_text.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_rtext.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_array.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_template.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_io.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_scalar.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_traversal.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_guiconnect.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_readwrite.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_editor.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_vdial.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_magicglass.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `m_pd.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `m_obj.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `m_atom.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `m_memory.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `m_conf.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `m_glob.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
The new connect mouse cursor is quite nice, and the inlet highlighting. There is a minor bug with the inlet highlighting, for the blue/gray solid audio inlets, after they get highlighted they inherit the black box of the message inlets. Back to testing! .hc On Wed, 2010-11-24 at 12:40 -0500, Ivica Ico Bukvic wrote: OK, latest snapshot 20101124 has been just made available in the usual place with additional improvements including: *all vanilla and iemgui objects are now accelerated in terms of their redrawing and moving, resulting in a dramatic improvement in UI responsiveness (for the devs, the new model uses tagging of widgets and move command, rather than apparently a much more cpu expensive coords call) *sarlo's magic highlighter now works on all iem objects as well as gop objects *more cosmetic bug fixes http://l2ork.music.vt.edu/main/?page_id=56 As always, feedback is most appreciated! Best wishes, Ico ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
Just started it up to try the up/down ordering feature, I'm on Ubuntu Lucid i386. I found a bug. With the attached patch, do this: 1) delete the [adsf( 2) highlight the upper left corner of the [cnv] canvas 3) hit Ctrl-down For me, the [asdf( message comes back. Also, I can't get the [cnv] to change ordering, only the [hsl]. I'll explore some more. .hc On Wed, 2010-11-24 at 12:40 -0500, Ivica Ico Bukvic wrote: OK, latest snapshot 20101124 has been just made available in the usual place with additional improvements including: *all vanilla and iemgui objects are now accelerated in terms of their redrawing and moving, resulting in a dramatic improvement in UI responsiveness (for the devs, the new model uses tagging of widgets and move command, rather than apparently a much more cpu expensive coords call) *sarlo's magic highlighter now works on all iem objects as well as gop objects *more cosmetic bug fixes http://l2ork.music.vt.edu/main/?page_id=56 As always, feedback is most appreciated! Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 320 259 450 300 10; #X msg 147 96 asdf; #X obj 201 64 cnv 15 100 60 empty empty empty 20 12 0 14 -233017 -66577 0; #X obj 204 88 hsl 128 15 0 127 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 0 1; ___ 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 Wed, 2010-11-24 at 14:06 -0500, Ivica Ico Bukvic wrote: I just realize that there are two iemgui libs in a sense: there are the iemgui objects that have been included in Pd-vanilla for 10 years, those are the ones I was referring to. Then there is the new iemgui library in pure-data SVN, I know little about that one. Which one are you referring to? I am referring to the one that has been a part of pd for a long time. This is the one I just updated in the latest release so that moving of its widgets in edit mode is now a part of a single move-by-tag call. I am actually quite pleased how it works now. That sounds like something that should have been done a while ago. My big worry here is regression bugs. So we'll need to come up with a bunch of tests so we can make sure the faster code doesn't introduce bugs. I think the only place we are going to see big benefits for move code is in redrawing arrays, the drawing is pretty simple in most other GUI objects. FYI, 0.43 fixes this issue by changing the 'editmode' message so that 1 means editmode is on, and 0 means editmode is off. Before that, the 'editmode' message toggled edit mode. That's what made it so difficult to make the menu item checkbox work. These are the kinds of things that I have spent many many hours working to fix, so it makes me sad to see you reinventing the wheel. I am not reinventing wheel in this case but simply backporting your solution (unless you are referring to me wasting hours as you did on the Tcl widget bug as the actual reinventing of the wheel). Either way, the checkmark next to the checkbutton widget is simply buggy and does not show up when it should (e.g. when invoking the widget). This is the case even with 0.43 gui rewrite. The only way one can see that the option has been activated on 0.43 (and now on l2ork iteration of 0.42) is by the fact edit mode option in the menu has changed its background color to green (which actually does not look all that bad, even though it is inconsistent with general menu UI guidelines Tcl/Tk is supposedly trying so hard to enforce). Yeah, I hear you. I think the background color thing works well for GNOME, not sure about anything else tho. Changing the text between Edit Mode and Play Mode is a viable option for all platforms IMHO. Peter Brinkmann, Peter Kirn, Miller and I all had a meeting recently to discuss the idea of making 'pd' a separate entity. My part is making pd talk to pd-gui using pd messages, then it should be pretty straightforward to making new GUIs in lots of different toolkits. As long as those messages are not something that needs to be sent via socket but can be also prototyped into direct function calls within C. Otherwise, the solution simply perpetuates the existing problem of socket and string parser saturation, resulting in very slow performance. Notice that even with l2ork iteration of pd-extended where everything vanilla now uses move-by-tag approach (in other words one call moves all selected widgets except for GOPs which are quite messy thus resulting in one call vs. potentially hundreds if not thousands) and which ostensibly approaches ideal performance via socket, it still gets relatively easily bogged down due to inherent overhead. I think there are advantages to having the GUI be a separate process, and it would be worth exploring other ways of havning pd and pd-gui talk. Shared memory is one idea. Plus for things like arrays, the data could be sent as binary thereby skipping the string parsing aspect. .hc ___ 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)
e.g. I am right now thinking it would be nice to have resizable cnv just by clicking on its bottom-right corner. Ditto for other visual iemgui objects. Another thing I would really like to see soon is ability to box-select patch cords. Then perhaps an undo doubly-linked list would be nice as well (although not sure how hard this would be). basically many of the things possible in max should be implemented in pd. a pd user gets used to take more time to work on the guis (or ends up avoiding them). something nice would be to edit the properties of several objects at the same time. maybe not for send-receive variables, but for the graphic possibilities. ___ 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 Wed, 11/24/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: RE: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: 'Jonathan Wilkes' jancs...@yahoo.com Cc: pd-list@iem.at Date: Wednesday, November 24, 2010, 6:29 AM Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue). Good to know. I will look into this when I get there. Currently working on accelerating iemgui objects as well as exposing them to sarlo's highlighting magic. Also notice that [flatspace/entry] has a nice cursor associated with resizing. Wouldn't it be easier just to toggle the text for that menu option between Edit mode and Run mode? (That's what they're called in the manual.) Sure. There are other options, too, like the one 0.43 and now l2ork version of 0.42 uses by changing option's background which works visually relatively well (albeit at the expense of consistency). This is however not the issue. The issue is finding out that after an hour of debugging the problem is not in you or your code but the toolkit you are using and in 2010 for a toolkit that has been around for more than a decade that is plainly sad. Another solution: you can also place a checkbutton labeled Edit mode directly on the menubar. Also, since we're talking about the menu changes: Since there is a Find menu, I think the Edit menu can be shortened by removing Find, Find again, and Find last error. How would you go about doing that? A: Ugly path: Isolate pd-gui hooks and port the entire thing to Qt. B: Better (albeit more time-consuming) path: clean-up code first so that all objects can utilize the same gobj_whatever calls and then do the A: (which at that point won't be nearly as ugly or difficult to maintain). FWIW, my first ever GUI app was RTMix I did back in 2001 and it was (and remains) the ugliest hack ever (basically I tried to learn how to program doing that app). Yet, the fact remains even in 2001 qt was way better than what Tk is today. Another advantage is avoiding socket bottlenecks as the entire thing could be done simply in C. License-wise it should be fine and cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for good measure since that is apparently hot item these days. That said, I need some more time working with Pd code before I can undertake this. Perhaps more importantly, I just need a generous, uninterrupted chunk of time to do this. Best wishes, 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 Wed, 11/24/10, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: RE: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Ivica Ico Bukvic i...@vt.edu Cc: 'Jonathan Wilkes' jancs...@yahoo.com, pd-list@iem.at Date: Wednesday, November 24, 2010, 11:54 PM On Wed, 2010-11-24 at 14:06 -0500, Ivica Ico Bukvic wrote: I just realize that there are two iemgui libs in a sense: there are the iemgui objects that have been included in Pd-vanilla for 10 years, those are the ones I was referring to. Then there is the new iemgui library in pure-data SVN, I know little about that one. Which one are you referring to? I am referring to the one that has been a part of pd for a long time. This is the one I just updated in the latest release so that moving of its widgets in edit mode is now a part of a single move-by-tag call. I am actually quite pleased how it works now. That sounds like something that should have been done a while ago. My big worry here is regression bugs. So we'll need to come up with a bunch of tests so we can make sure the faster code doesn't introduce bugs. I think the only place we are going to see big benefits for move code is in redrawing arrays, the drawing is pretty simple in most other GUI objects. FYI, 0.43 fixes this issue by changing the 'editmode' message so that 1 means editmode is on, and 0 means editmode is off. Before that, the 'editmode' message toggled edit mode. That's what made it so difficult to make the menu item checkbox work. These are the kinds of things that I have spent many many hours working to fix, so it makes me sad to see you reinventing the wheel. I am not reinventing wheel in this case but simply backporting your solution (unless you are referring to me wasting hours as you did on the Tcl widget bug as the actual reinventing of the wheel). Either way, the checkmark next to the checkbutton widget is simply buggy and does not show up when it should (e.g. when invoking the widget). This is the case even with 0.43 gui rewrite. The only way one can see that the option has been activated on 0.43 (and now on l2ork iteration of 0.42) is by the fact edit mode option in the menu has changed its background color to green (which actually does not look all that bad, even though it is inconsistent with general menu UI guidelines Tcl/Tk is supposedly trying so hard to enforce). Yeah, I hear you. I think the background color thing works well for GNOME, not sure about anything else tho. Changing the text between Edit Mode and Play Mode is a viable option for all platforms IMHO. If you do this please call it Run mode and not Play mode. It's run mode in the manual, as well as a lot of the docs, tutorials, and internal help patches. Peter Brinkmann, Peter Kirn, Miller and I all had a meeting recently to discuss the idea of making 'pd' a separate entity. My part is making pd talk to pd-gui using pd messages, then it should be pretty straightforward to making new GUIs in lots of different toolkits. As long as those messages are not something that needs to be sent via socket but can be also prototyped into direct function calls within C. Otherwise, the solution simply perpetuates the existing problem of socket and string parser saturation, resulting in very slow performance. Notice that even with l2ork iteration of pd-extended where everything vanilla now uses move-by-tag approach (in other words one call moves all selected widgets except for GOPs which are quite messy thus resulting in one call vs. potentially hundreds if not thousands) and which ostensibly approaches ideal performance via socket, it still gets relatively easily bogged down due to inherent overhead. I think there are advantages to having the GUI be a separate process, and it would be worth exploring other ways of havning pd and pd-gui talk. Shared memory is one idea. Plus for things like arrays, the data could be sent as binary thereby skipping the string parsing aspect. .hc ___ 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)
Thanks, this worked. Now i'm having segfaults on patch load, it seems it's with [moocow/mknob]. Andras 2010/11/24 Ivica Ico Bukvic i...@vt.edu When installing onan arch other than i386 please make sure to do: make distclean aclocal autoconf ./configure (with appropriate flags) make Etc. HTH Ico András Murányi muran...@gmail.com wrote: On Wed, Nov 24, 2010 at 6:40 PM, Ivica Ico Bukvic i...@vt.edu wrote: OK, latest snapshot 20101124 has been just made available in the usual place with additional improvements including: *all vanilla and iemgui objects are now accelerated in terms of their redrawing and moving, resulting in a dramatic improvement in UI responsiveness (for the devs, the new model uses tagging of widgets and move command, rather than apparently a much more cpu expensive coords call) *sarlo's magic highlighter now works on all iem objects as well as gop objects *more cosmetic bug fixes http://l2ork.music.vt.edu/main/?page_id=56 As always, feedback is most appreciated! Best wishes, Ico personal thoughts, never mind First i wish to say i had my doubts but now i'm happy to see an iteration of pd-extended in the wild. One may say there is some waste of time with a fork like this and of course there is, but it also proves pd-extended to be 'adult' in a way and adults may have children, and children may seem to reinvent the wheel sometimes but that's all right and that's the way they can find their new, hopefully better ways. And meanwhile, hopefully, many thing will go upstream and it will be a big happy family :o) I'm particularly interested in better GUIs operating a well separated core, and happy to see Hans Miller al are advancing in this direction! /personal thoughts, never mind I'm on AMD64 and has run into this with 'make': cd ../obj; cc -Wl,-export-dynamic -lasound -lrt -ljack -o ../bin/pd d_ctl.o d_array.o d_delay.o d_filter.o d_math.o d_osc.o d_soundfile.o g_canvas.o g_graph.o g_text.o g_rtext.o g_array.o g_template.o g_io.o g_scalar.o g_traversal.o g_guiconnect.o g_readwrite.o g_editor.o g_all_guis.o g_bang.o g_hdial.o g_hslider.o g_mycanvas.o g_numbox.o g_toggle.o g_vdial.o g_vslider.o g_vumeter.o g_magicglass.o m_pd.o m_class.o m_obj.o m_atom.o m_memory.o m_binbuf.o m_conf.o m_glob.o m_sched.o s_main.o s_inter.o s_file.o s_print.o s_loader.o s_path.o s_entry.o s_audio.o s_midi.o d_ugen.o d_arithmetic.o d_dac.o d_misc.o d_fft.o d_global.o d_resample.o x_arithmetic.o x_connective.o x_interface.o x_midi.o x_misc.o x_time.o x_acoustics.o x_net.o x_qlist.o x_gui.o x_list.o import.o s_midi_oss.o s_audio_oss.o s_audio_alsa.o s_audio_alsamm.o s_midi_alsa.o s_audio_jack.o d_fft_mayer.o d_fftroutine.o -ldl -lm -lpthread -lasound collect2: ld terminated with signal 11 [Segmentation fault] /usr/bin/ld: i386 architecture of input file `d_ctl.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_array.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_delay.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_filter.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_math.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_osc.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_canvas.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_graph.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_text.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_rtext.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_array.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_template.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_io.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_scalar.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_traversal.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_guiconnect.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_readwrite.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_editor.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_vdial.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_magicglass.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `m_pd.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
moonlib indeed! 2010/11/25 Jonathan Wilkes jancs...@yahoo.com [moonlib/mknob] -Jonathan Thanks, this worked. Now i'm having segfaults on patch load, it seems it's with [moocow/mknob]. Andras 2010/11/24 Ivica Ico Bukvic i...@vt.edu http://mc/compose?to=...@vt.edu When installing onan arch other than i386 please make sure to do: make distclean aclocal autoconf ./configure (with appropriate flags) make Etc. HTH Ico András Murányi muran...@gmail.comhttp://mc/compose?to=muran...@gmail.com wrote: On Wed, Nov 24, 2010 at 6:40 PM, Ivica Ico Bukvic i...@vt.eduhttp://mc/compose?to=...@vt.edu wrote: OK, latest snapshot 20101124 has been just made available in the usual place with additional improvements including: *all vanilla and iemgui objects are now accelerated in terms of their redrawing and moving, resulting in a dramatic improvement in UI responsiveness (for the devs, the new model uses tagging of widgets and move command, rather than apparently a much more cpu expensive coords call) *sarlo's magic highlighter now works on all iem objects as well as gop objects *more cosmetic bug fixes http://l2ork.music.vt.edu/main/?page_id=56 As always, feedback is most appreciated! Best wishes, Ico personal thoughts, never mind First i wish to say i had my doubts but now i'm happy to see an iteration of pd-extended in the wild. One may say there is some waste of time with a fork like this and of course there is, but it also proves pd-extended to be 'adult' in a way and adults may have children, and children may seem to reinvent the wheel sometimes but that's all right and that's the way they can find their new, hopefully better ways. And meanwhile, hopefully, many thing will go upstream and it will be a big happy family :o) I'm particularly interested in better GUIs operating a well separated core, and happy to see Hans Miller al are advancing in this direction! /personal thoughts, never mind I'm on AMD64 and has run into this with 'make': cd ../obj; cc -Wl,-export-dynamic -lasound -lrt -ljack -o ../bin/pd d_ctl.o d_array.o d_delay.o d_filter.o d_math.o d_osc.o d_soundfile.o g_canvas.o g_graph.o g_text.o g_rtext.o g_array.o g_template.o g_io.o g_scalar.o g_traversal.o g_guiconnect.o g_readwrite.o g_editor.o g_all_guis.o g_bang.o g_hdial.o g_hslider.o g_mycanvas.o g_numbox.o g_toggle.o g_vdial.o g_vslider.o g_vumeter.o g_magicglass.o m_pd.o m_class.o m_obj.o m_atom.o m_memory.o m_binbuf.o m_conf.o m_glob.o m_sched.o s_main.o s_inter.o s_file.o s_print.o s_loader.o s_path.o s_entry.o s_audio.o s_midi.o d_ugen.o d_arithmetic.o d_dac.o d_misc.o d_fft.o d_global.o d_resample.o x_arithmetic.o x_connective.o x_interface.o x_midi.o x_misc.o x_time.o x_acoustics.o x_net.o x_qlist.o x_gui.o x_list.o import.o s_midi_oss.o s_audio_oss.o s_audio_alsa.o s_audio_alsamm.o s_midi_alsa.o s_audio_jack.o d_fft_mayer.o d_fftroutine.o -ldl -lm -lpthread -lasound collect2: ld terminated with signal 11 [Segmentation fault] /usr/bin/ld: i386 architecture of input file `d_ctl.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_array.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_delay.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_filter.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_math.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_osc.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_canvas.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_graph.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_text.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_rtext.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_array.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_template.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_io.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_scalar.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_traversal.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_guiconnect.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_readwrite.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_editor.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `g_vdial.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
On Thu, 2010-11-25 at 02:53 +0100, András Murányi wrote: moonlib indeed! 2010/11/25 Jonathan Wilkes jancs...@yahoo.com [moonlib/mknob] -Jonathan Thanks, this worked. Now i'm having segfaults on patch load, it seems it's with [moocow/mknob]. Confirmed. Looking into it... ___ 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)
Also notice that [flatspace/entry] has a nice cursor associated with resizing. Noted. I will look into this once bug hunt is over. Thanks for the tip! Another solution: you can also place a checkbutton labeled Edit mode directly on the menubar. Yes, except personally I would prefer to keep the pd window as clean as possible. Also, since we're talking about the menu changes: Since there is a Find menu, I think the Edit menu can be shortened by removing Find, Find again, and Find last error. Done. This will be included in the next tarball (even though it goes against Msft/Apple design guidelines. Best wishes, 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 Wed, 2010-11-24 at 17:26 -0500, Hans-Christoph Steiner wrote: The new connect mouse cursor is quite nice, and the inlet highlighting. There is a minor bug with the inlet highlighting, for the blue/gray solid audio inlets, after they get highlighted they inherit the black box of the message inlets. Back to testing! I just fixed this. It will be released in the next tarball. ___ 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 Wed, 2010-11-24 at 17:21 -0500, Hans-Christoph Steiner wrote: Just started it up to try the up/down ordering feature, I'm on Ubuntu Lucid i386. I found a bug. With the attached patch, do this: 1) delete the [adsf( 2) highlight the upper left corner of the [cnv] canvas 3) hit Ctrl-down For me, the [asdf( message comes back. Also, I can't get the [cnv] to change ordering, only the [hsl]. I'll explore some more. Just tested this and cannot reproduce it. This has been definitely fixed in the yesterday's (or perhaps today's) snapshot so please try that one instead as there was a bug Jonathan reported which prompted me to rewrite to front/back part. Best wishes, 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 Thu, 11/25/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: RE: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at Date: Thursday, November 25, 2010, 4:53 AM Also notice that [flatspace/entry] has a nice cursor associated with resizing. Noted. I will look into this once bug hunt is over. Thanks for the tip! Another solution: you can also place a checkbutton labeled Edit mode directly on the menubar. Yes, except personally I would prefer to keep the pd window as clean as possible. Also, since we're talking about the menu changes: Since there is a Find menu, I think the Edit menu can be shortened by removing Find, Find again, and Find last error. Done. This will be included in the next tarball (even though it goes against Msft/Apple design guidelines. Well, you could also go the other way and just get rid of the Find menu altogether. It's just the redundancy I'd like to get rid of the redudancy. :) -Jonathan Best wishes, 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)
If I delete all the [clip] objects in the attached patch, it becomes much faster to select and move the toggle objects. Why is that? I mean, the number of selected objects is the same either way. Do the [clip]s get redrawn every time I move the selection? -Jonathan lots-of-objects.pd Description: Binary data ___ 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 Nov 24, 2010, at 7:37 PM, Jonathan Wilkes wrote: --- On Wed, 11/24/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: RE: [PD] call for testers for L2Ork iteration of pd- extended (based on 0.42.x branch) To: 'Jonathan Wilkes' jancs...@yahoo.com Cc: pd-list@iem.at Date: Wednesday, November 24, 2010, 6:29 AM Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue). Good to know. I will look into this when I get there. Currently working on accelerating iemgui objects as well as exposing them to sarlo's highlighting magic. Also notice that [flatspace/entry] has a nice cursor associated with resizing. Ah yes, I forgot about that cursor in entry. I actually started working on improving the [entry] widget, and that turned into the tkwidgets library. I really should get the tkwidgets stuff into some kind of usable release. .hc Wouldn't it be easier just to toggle the text for that menu option between Edit mode and Run mode? (That's what they're called in the manual.) Sure. There are other options, too, like the one 0.43 and now l2ork version of 0.42 uses by changing option's background which works visually relatively well (albeit at the expense of consistency). This is however not the issue. The issue is finding out that after an hour of debugging the problem is not in you or your code but the toolkit you are using and in 2010 for a toolkit that has been around for more than a decade that is plainly sad. Another solution: you can also place a checkbutton labeled Edit mode directly on the menubar. Also, since we're talking about the menu changes: Since there is a Find menu, I think the Edit menu can be shortened by removing Find, Find again, and Find last error. How would you go about doing that? A: Ugly path: Isolate pd-gui hooks and port the entire thing to Qt. B: Better (albeit more time-consuming) path: clean-up code first so that all objects can utilize the same gobj_whatever calls and then do the A: (which at that point won't be nearly as ugly or difficult to maintain). FWIW, my first ever GUI app was RTMix I did back in 2001 and it was (and remains) the ugliest hack ever (basically I tried to learn how to program doing that app). Yet, the fact remains even in 2001 qt was way better than what Tk is today. Another advantage is avoiding socket bottlenecks as the entire thing could be done simply in C. License-wise it should be fine and cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for good measure since that is apparently hot item these days. That said, I need some more time working with Pd code before I can undertake this. Perhaps more importantly, I just need a generous, uninterrupted chunk of time to do this. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. ___ 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 Nov 24, 2010, at 7:46 PM, Jonathan Wilkes wrote: --- On Wed, 11/24/10, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: RE: [PD] call for testers for L2Ork iteration of pd- extended (based on 0.42.x branch) To: Ivica Ico Bukvic i...@vt.edu Cc: 'Jonathan Wilkes' jancs...@yahoo.com, pd-list@iem.at Date: Wednesday, November 24, 2010, 11:54 PM On Wed, 2010-11-24 at 14:06 -0500, Ivica Ico Bukvic wrote: I just realize that there are two iemgui libs in a sense: there are the iemgui objects that have been included in Pd-vanilla for 10 years, those are the ones I was referring to. Then there is the new iemgui library in pure-data SVN, I know little about that one. Which one are you referring to? I am referring to the one that has been a part of pd for a long time. This is the one I just updated in the latest release so that moving of its widgets in edit mode is now a part of a single move-by-tag call. I am actually quite pleased how it works now. That sounds like something that should have been done a while ago. My big worry here is regression bugs. So we'll need to come up with a bunch of tests so we can make sure the faster code doesn't introduce bugs. I think the only place we are going to see big benefits for move code is in redrawing arrays, the drawing is pretty simple in most other GUI objects. FYI, 0.43 fixes this issue by changing the 'editmode' message so that 1 means editmode is on, and 0 means editmode is off. Before that, the 'editmode' message toggled edit mode. That's what made it so difficult to make the menu item checkbox work. These are the kinds of things that I have spent many many hours working to fix, so it makes me sad to see you reinventing the wheel. I am not reinventing wheel in this case but simply backporting your solution (unless you are referring to me wasting hours as you did on the Tcl widget bug as the actual reinventing of the wheel). Either way, the checkmark next to the checkbutton widget is simply buggy and does not show up when it should (e.g. when invoking the widget). This is the case even with 0.43 gui rewrite. The only way one can see that the option has been activated on 0.43 (and now on l2ork iteration of 0.42) is by the fact edit mode option in the menu has changed its background color to green (which actually does not look all that bad, even though it is inconsistent with general menu UI guidelines Tcl/Tk is supposedly trying so hard to enforce). Yeah, I hear you. I think the background color thing works well for GNOME, not sure about anything else tho. Changing the text between Edit Mode and Play Mode is a viable option for all platforms IMHO. If you do this please call it Run mode and not Play mode. It's run mode in the manual, as well as a lot of the docs, tutorials, and internal help patches. Right, I'm proposing changing it everywhere. run mode implies that things aren't running in edit mode, which is definitely not true. .hc Peter Brinkmann, Peter Kirn, Miller and I all had a meeting recently to discuss the idea of making 'pd' a separate entity. My part is making pd talk to pd-gui using pd messages, then it should be pretty straightforward to making new GUIs in lots of different toolkits. As long as those messages are not something that needs to be sent via socket but can be also prototyped into direct function calls within C. Otherwise, the solution simply perpetuates the existing problem of socket and string parser saturation, resulting in very slow performance. Notice that even with l2ork iteration of pd-extended where everything vanilla now uses move-by-tag approach (in other words one call moves all selected widgets except for GOPs which are quite messy thus resulting in one call vs. potentially hundreds if not thousands) and which ostensibly approaches ideal performance via socket, it still gets relatively easily bogged down due to inherent overhead. I think there are advantages to having the GUI be a separate process, and it would be worth exploring other ways of havning pd and pd-gui talk. Shared memory is one idea. Plus for things like arrays, the data could be sent as binary thereby skipping the string parsing aspect. .hc If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ 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 Thu, 11/25/10, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Thursday, November 25, 2010, 5:39 AM On Nov 24, 2010, at 7:37 PM, Jonathan Wilkes wrote: --- On Wed, 11/24/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: RE: [PD] call for testers for L2Ork iteration of pd- extended (based on 0.42.x branch) To: 'Jonathan Wilkes' jancs...@yahoo.com Cc: pd-list@iem.at Date: Wednesday, November 24, 2010, 6:29 AM Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue). Good to know. I will look into this when I get there. Currently working on accelerating iemgui objects as well as exposing them to sarlo's highlighting magic. Also notice that [flatspace/entry] has a nice cursor associated with resizing. Ah yes, I forgot about that cursor in entry. I actually started working on improving the [entry] widget, and that turned into the tkwidgets library. I really should get the tkwidgets stuff into some kind of usable release. Let me know if you do this. I've got a pd patch that is a fully functioning object-search GUI which is currently using toxy. I posted some screenshots a few weeks ago. I'll switch it over to use tkwidgets if you can get the library to do the following: 1) use tab key to give focus to the next widget in the patch 2) do nonlocal send/receive names like iemguis 3) have a message to set widget focus (so it can have focus on loadbang like Google's text entry, for example) 4) output entry string as a list so that, for example, typing 'float' will output 'list float'. (Actually it could also output it as a symbol-- just as long as it doesn't output an anything.) I think I also had a short list of general bugs posted a few weeks back. -Jonathan .hc Wouldn't it be easier just to toggle the text for that menu option between Edit mode and Run mode? (That's what they're called in the manual.) Sure. There are other options, too, like the one 0.43 and now l2ork version of 0.42 uses by changing option's background which works visually relatively well (albeit at the expense of consistency). This is however not the issue. The issue is finding out that after an hour of debugging the problem is not in you or your code but the toolkit you are using and in 2010 for a toolkit that has been around for more than a decade that is plainly sad. Another solution: you can also place a checkbutton labeled Edit mode directly on the menubar. Also, since we're talking about the menu changes: Since there is a Find menu, I think the Edit menu can be shortened by removing Find, Find again, and Find last error. How would you go about doing that? A: Ugly path: Isolate pd-gui hooks and port the entire thing to Qt. B: Better (albeit more time-consuming) path: clean-up code first so that all objects can utilize the same gobj_whatever calls and then do the A: (which at that point won't be nearly as ugly or difficult to maintain). FWIW, my first ever GUI app was RTMix I did back in 2001 and it was (and remains) the ugliest hack ever (basically I tried to learn how to program doing that app). Yet, the fact remains even in 2001 qt was way better than what Tk is today. Another advantage is avoiding socket bottlenecks as the entire thing could be done simply in C. License-wise it should be fine and cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for good measure since that is apparently hot item these days. That said, I need some more time working with Pd code before I can undertake this. Perhaps more importantly, I just need a generous, uninterrupted chunk of time to do this. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. ___ 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 Thu, 11/25/10, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Thursday, November 25, 2010, 5:40 AM On Nov 24, 2010, at 7:46 PM, Jonathan Wilkes wrote: --- On Wed, 11/24/10, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: RE: [PD] call for testers for L2Ork iteration of pd- extended (based on 0.42.x branch) To: Ivica Ico Bukvic i...@vt.edu Cc: 'Jonathan Wilkes' jancs...@yahoo.com, pd-list@iem.at Date: Wednesday, November 24, 2010, 11:54 PM On Wed, 2010-11-24 at 14:06 -0500, Ivica Ico Bukvic wrote: I just realize that there are two iemgui libs in a sense: there are the iemgui objects that have been included in Pd-vanilla for 10 years, those are the ones I was referring to. Then there is the new iemgui library in pure-data SVN, I know little about that one. Which one are you referring to? I am referring to the one that has been a part of pd for a long time. This is the one I just updated in the latest release so that moving of its widgets in edit mode is now a part of a single move-by-tag call. I am actually quite pleased how it works now. That sounds like something that should have been done a while ago. My big worry here is regression bugs. So we'll need to come up with a bunch of tests so we can make sure the faster code doesn't introduce bugs. I think the only place we are going to see big benefits for move code is in redrawing arrays, the drawing is pretty simple in most other GUI objects. FYI, 0.43 fixes this issue by changing the 'editmode' message so that 1 means editmode is on, and 0 means editmode is off. Before that, the 'editmode' message toggled edit mode. That's what made it so difficult to make the menu item checkbox work. These are the kinds of things that I have spent many many hours working to fix, so it makes me sad to see you reinventing the wheel. I am not reinventing wheel in this case but simply backporting your solution (unless you are referring to me wasting hours as you did on the Tcl widget bug as the actual reinventing of the wheel). Either way, the checkmark next to the checkbutton widget is simply buggy and does not show up when it should (e.g. when invoking the widget). This is the case even with 0.43 gui rewrite. The only way one can see that the option has been activated on 0.43 (and now on l2ork iteration of 0.42) is by the fact edit mode option in the menu has changed its background color to green (which actually does not look all that bad, even though it is inconsistent with general menu UI guidelines Tcl/Tk is supposedly trying so hard to enforce). Yeah, I hear you. I think the background color thing works well for GNOME, not sure about anything else tho. Changing the text between Edit Mode and Play Mode is a viable option for all platforms IMHO. If you do this please call it Run mode and not Play mode. It's run mode in the manual, as well as a lot of the docs, tutorials, and internal help patches. Right, I'm proposing changing it everywhere. run mode implies that things aren't running in edit mode, which is definitely not true. By that logic play mode implies that things aren't playing in edit mode, which is definitely not true either. Either way it takes a few seconds to notice that: [osc~ 420] | [*~ 0.1] |\ [dac~] is 'playing'/'running'/'producing music' regardless of which mode Pd is in (as long as DSP is turned on). Changing all instances of 'run mode' to 'play mode' is a lot of work for very little gain. Not changing anything is no gain, yet no work. (I would vote for the latter but given the context that seems like too much work.) -Jonathan .hc Peter Brinkmann, Peter Kirn, Miller and I all had a meeting recently to discuss the idea of making 'pd' a separate entity. My part is making pd talk to pd-gui using pd messages, then it should be pretty straightforward to making new GUIs in lots of different toolkits. As long as those messages are not something that needs to be sent via socket but can be also prototyped into direct function calls within C. Otherwise, the solution simply perpetuates the existing problem of socket and string parser saturation, resulting in very slow performance. Notice that even with l2ork iteration of pd-extended where everything vanilla now uses move-by-tag approach (in other words one call moves all selected widgets except for GOPs which are quite messy thus resulting in one call vs. potentially hundreds if not thousands)
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
On Wed, 2010-11-24 at 20:30 -0800, Jonathan Wilkes wrote: If I delete all the [clip] objects in the attached patch, it becomes much faster to select and move the toggle objects. Why is that? I mean, the number of selected objects is the same either way. Do the [clip]s get redrawn every time I move the selection? -Jonathan Not sure. It really bogs down on my machine but it is still way faster than the older algorithm. To see just how many messages pass between pd and tcl/tk run: pd -d 1 lots-of-objects.pd Compare old version vs. new and you'll see the difference. The ironic thing is that I also noticed some inconsistencies in expected performance. Namely, when I have one complex GOP, it runs relatively sluggish. Then I add the second one and everything moves *way* faster (GOPs BTW are not accelerated in my code either). It is almost as if at some point threshold on the socket queue elevates its priority above other things (but this is a mere speculation at best as I've no idea how kernel handles these kinds of things, particularly when one is running a rt kernel). Best wishes, 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)
OK, new snapshot 20101125 is now up with following fixes: *removed redundant find menu *inlet and outlet highlighting reset bug (reported by Hans) *magicglass not reporting negative sig~ values *added ~ prefix to signal data magicglass monitoring *magicglass not displaying list *magicglass widget not properly resizing *added magicglass flashing indicator *fixed magicglass flicker http://l2ork.music.vt.edu/main/?page_id=56 Next stop segfault with moonlib/mknob but this will have to wait until tomorrow as my eyelids are getting unbearably heavy... 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 Wed, 2010-11-24 at 22:46 -0500, Ivica Ico Bukvic wrote: On Thu, 2010-11-25 at 02:53 +0100, András Murányi wrote: moonlib indeed! 2010/11/25 Jonathan Wilkes jancs...@yahoo.com [moonlib/mknob] -Jonathan Thanks, this worked. Now i'm having segfaults on patch load, it seems it's with [moocow/mknob]. Confirmed. Looking into it... All right, I said I would go to sleep but the curiosity got the best of me, so I looked at this one and found a super-simple solution. Namely, it appears mknob uses g_all_guis.h and g_canvas.h, both of which have changed as a result of accelerated drawing of iemgui objects. A simple recompile of mknob (and likely other objects that may rely upon the same framework) apparently fixed the problem. That said, this like other non-standard externals does not utilize either highlight or accelerated motion (and thus falls back nicely on the old way of moving using coords). HTH BTW, Hans, is there a reason why pd-extended cannot find moonlib's help files? I tried importing, as well as invoking objects with moonlib/ prefix. How would one go about fixing this other than extending the default.pdsettings file? Gotta love it when your bug-hunt TODO list is finally empty (even if only for a couple of hours :-). 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)
Hi, this sounds great. I might have a chance to try it next week (back to dsl), if I have a break. But some questions in advance: - is there a release program? are the testers to make sure the implementations are working well, or do you still take requests? - what is going to happen to all this work, hopefully be integrated in pd-van/ext? - will someone put the code to work in all systems? (especially windows) - will you/your team continue to make improvements here (there are really lots of things that can be done), or was this a one-off project? - is there a feature list, to know how to test the novelties? - did you look at ? in an informal presentation here one of their developers said that he was inspired by pd, but added lots of details that make the user experience much faster and easier, sometimes just by implementing small details (let the mouse over an outlet to see the values, etc.). Best, João ___ 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)
Hi Ico cd pd/src make distclean aclocal autoconf ./configure (with flags you wish to use, typically --prefix=/usr --enable-jack --enable-alsa) make cp pd.tk ../bin (old stale one crept into the tarball inside the bin directory--I will fix this shortly and reupload the tarball) at that point you can either: cd ../bin ./pd or (if you feel like this version is worthy being installed system-wide) make install pd I have gotten further with compiling but I do get the following error at make install: t_main.c t_main.c:18:16: error: tk.h: No such file or directory t_main.c:38: error: expected ‘)’ before ‘*’ token t_main.c: In function ‘main’: t_main.c:59: warning: implicit declaration of function ‘Tk_Main’ t_main.c:59: error: ‘Tcl_AppInit’ undeclared (first use in this function) t_main.c:59: error: (Each undeclared identifier is reported only once t_main.c:59: error: for each function it appears in.) t_main.c: At top level: t_main.c:86: warning: function declaration isn’t a prototype t_main.c: In function ‘Tcl_AppInit’: t_main.c:86: error: expected declaration specifiers before ‘Tcl_Interp’ t_main.c:85: warning: type of ‘interp’ defaults to ‘int’ t_main.c:88: error: ‘Tk_Window’ undeclared (first use in this function) t_main.c:88: error: expected ‘;’ before ‘mainwindow’ t_main.c:90: warning: implicit declaration of function ‘Tcl_Init’ t_main.c:90: error: ‘TCL_ERROR’ undeclared (first use in this function) t_main.c:93: warning: implicit declaration of function ‘Tk_Init’ t_main.c:99: warning: implicit declaration of function ‘pdgui_startup’ t_main.c:112: error: ‘TCL_OK’ undeclared (first use in this function) make: *** [t_main.o] Error 1 Thanks for any tips-almost got it going On Tue, Nov 23, 2010 at 8:37 AM, João Pais jmmmp...@googlemail.com wrote: Hi, this sounds great. I might have a chance to try it next week (back to dsl), if I have a break. But some questions in advance: - is there a release program? are the testers to make sure the implementations are working well, or do you still take requests? - what is going to happen to all this work, hopefully be integrated in pd-van/ext? - will someone put the code to work in all systems? (especially windows) - will you/your team continue to make improvements here (there are really lots of things that can be done), or was this a one-off project? - is there a feature list, to know how to test the novelties? - did you look at ? in an informal presentation here one of their developers said that he was inspired by pd, but added lots of details that make the user experience much faster and easier, sometimes just by implementing small details (let the mouse over an outlet to see the values, etc.). Best, João ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
It appears your also missing tk dev libraries ALAN BROOKER alan.brooker2...@gmail.com wrote: Hi Ico cd pd/src make distclean aclocal autoconf ./configure (with flags you wish to use, typically --prefix=/usr --enable-jack --enable-alsa) make cp pd.tk ../bin (old stale one crept into the tarball inside the bin directory--I will fix this shortly and reupload the tarball) at that point you can either: cd ../bin ./pd or (if you feel like this version is worthy being installed system-wide) make install pd I have gotten further with compiling but I do get the following error at make install: t_main.c t_main.c:18:16: error: tk.h: No such file or directory t_main.c:38: error: expected ‘)’ before ‘*’ token t_main.c: In function ‘main’: t_main.c:59: warning: implicit declaration of function ‘Tk_Main’ t_main.c:59: error: ‘Tcl_AppInit’ undeclared (first use in this function) t_main.c:59: error: (Each undeclared identifier is reported only once t_main.c:59: error: for each function it appears in.) t_main.c: At top level: t_main.c:86: warning: function declaration isn’t a prototype t_main.c: In function ‘Tcl_AppInit’: t_main.c:86: error: expected declaration specifiers before ‘Tcl_Interp’ t_main.c:85: warning: type of ‘interp’ defaults to ‘int’ t_main.c:88: error: ‘Tk_Window’ undeclared (first use in this function) t_main.c:88: error: expected ‘;’ before ‘mainwindow’ t_main.c:90: warning: implicit declaration of function ‘Tcl_Init’ t_main.c:90: error: ‘TCL_ERROR’ undeclared (first use in this function) t_main.c:93: warning: implicit declaration of function ‘Tk_Init’ t_main.c:99: warning: implicit declaration of function ‘pdgui_startup’ t_main.c:112: error: ‘TCL_OK’ undeclared (first use in this function) make: *** [t_main.o] Error 1 Thanks for any tips-almost got it going On Tue, Nov 23, 2010 at 8:37 AM, João Pais jmmmp...@googlemail.com wrote: Hi, this sounds great. I might have a chance to try it next week (back to dsl), if I have a break. But some questions in advance: - is there a release program? are the testers to make sure the implementations are working well, or do you still take requests? - what is going to happen to all this work, hopefully be integrated in pd-van/ext? - will someone put the code to work in all systems? (especially windows) - will you/your team continue to make improvements here (there are really lots of things that can be done), or was this a one-off project? - is there a feature list, to know how to test the novelties? - did you look at ? in an informal presentation here one of their developers said that he was inspired by pd, but added lots of details that make the user experience much faster and easier, sometimes just by implementing small details (let the mouse over an outlet to see the values, etc.). Best, João ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
- is there a release program? are the testers to make sure the implementations are working well, or do you still take requests? Not only requests but also active contributions are very much welcome. Ideally, patches provided would be both pd vanilla and our pd-compatible, so that theoretically everyone can benefit. - what is going to happen to all this work, hopefully be integrated in pd-van/ext? I've tried sending over dozen patches upstream over the past year (and there are at least another half-dozen I need to submit). While some have made it into vanilla Pd, many of them haven't. I think partially because most of the core devs are plugging away at 0.43 which for me is a no go as of right now as I need something that is as production-ready and bug-free as possible. Other reasons include possibly the fact that some of the patches may be seen as controversial in terms of how they tackle issues. E.g. scrolling algorithm fundamentally changes how canvas spatial context is being calculated and as such it may take some time to adjust to. Tldr; While I hope all patches I've submitted do make it upstream, I have no way of knowing. 0.43 will get there and possibly soon but I don't feel comfortable running it yet. - will someone put the code to work in all systems? (especially windows) That someone would have to be someone else than me as I am swamped as it is and quite frankly other OSs are not (and will likely never be) a priority in L2Ork. That said, I will gladly merge whatever improvements I can get in this respect. We've already put a decent amount of work inside pd.tk to allow better separation of Linux from other Oss in terms of customizations but it has not been consistent throughout, so it is a simple matter of tracking those inconsistencies down and adjusting accordingly. - will you/your team continue to make improvements here (there are really lots of things that can be done), or was this a one-off project? As best as we can. At this point it is mainly me and occasionally I get some student help. - is there a feature list, to know how to test the novelties? I should've done a laundry list of these as I went but somewhere along the road I lost track so honestly I don't know just how many fixes are there. That said, I am quite sure there easily dozens upon dozens of them in this release alone. - did you look at ? in an informal presentation here one of their developers said that he was inspired by pd, but added lots of details that make the user experience much faster and easier, sometimes just by implementing small details (let the mouse over an outlet to see the values, etc.). I saw it briefly and I agree there are a lot of options that could be added. I think the important question which ones should be given greatest priority. e.g. I am right now thinking it would be nice to have resizable cnv just by clicking on its bottom-right corner. Ditto for other visual iemgui objects. Another thing I would really like to see soon is ability to box-select patch cords. Then perhaps an undo doubly-linked list would be nice as well (although not sure how hard this would be). HTH Best wishes, Ico Best, João ___ 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)
Ok, this is looking familiar-- have a look at tidy-test.pd, select each group of objects one at a time and do 'tidy up': 1. Works as it should. 2. Objects are below the y-threshold, so they (understandably) collapse. 3. Works as it should. 4. Objects spaced 30 px apart vertically seem arbitrarily to no longer get tidy. 5. Horizontal row of objects gets tidy (with arbitrarily large space in between any two objects). Works as it should-- columns of objects should behave the same way. Now select all and tidy. Notice that #3 now gives different results. -Jonathan Interesting... It seems to me tidy would work better if it simply checked first if it had objects that are vertically or horizontally closer to its x,y position and then adjust according to them only, rather than keeping a HIST of values it may be able to potentially adjust to. This would of course require change to the algorithm's fundamentals. Another thought would be to have the whole thing keep running with ever-increasing thresholds until something is adjusted or some ridiculous threshold is reached. 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)
Hi Thanks Ico, it's working now- no errors- *Really* sorry to be a pain but can I ask how I can easily point pd to pick up my libraries, Gem etc, other than inputting the folders and binary names one by one from start up paths menu? Thanks again ! Al On Tue, Nov 23, 2010 at 2:58 PM, Ivica Ico Bukvic i...@vt.edu wrote: Ok, this is looking familiar-- have a look at tidy-test.pd, select each group of objects one at a time and do 'tidy up': 1. Works as it should. 2. Objects are below the y-threshold, so they (understandably) collapse. 3. Works as it should. 4. Objects spaced 30 px apart vertically seem arbitrarily to no longer get tidy. 5. Horizontal row of objects gets tidy (with arbitrarily large space in between any two objects). Works as it should-- columns of objects should behave the same way. Now select all and tidy. Notice that #3 now gives different results. -Jonathan Interesting... It seems to me tidy would work better if it simply checked first if it had objects that are vertically or horizontally closer to its x,y position and then adjust according to them only, rather than keeping a HIST of values it may be able to potentially adjust to. This would of course require change to the algorithm's fundamentals. Another thought would be to have the whole thing keep running with ever-increasing thresholds until something is adjusted or some ridiculous threshold is reached. Ico ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
Thanks Ico, it's working now- no errors- Really sorry to be a pain but can I ask how I can easily point pd to pick up my libraries, Gem etc, other than inputting the folders and binary names one by one from start up paths menu? Thanks again ! Al Assuming you've been using pd-extended, easiest is to copy default.pdsettings (the one we have on the L2Ork site) and copy it to your /usr/lib/pd folder. You may want to back your old one up before doing so if you have custom settings in there already. Second easiest is to install pd-extended dpkg for your distro (ideally the one before its executable and path have been moved to /usr/lib/pd-extended, which is I believe 0.42.5 snapshot from a couple months ago) and then reinstall L2Ork's version over it and copy the aforesaid default.pdsettings file. 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)
On Nov 23, 2010, at 3:37 AM, João Pais wrote: Hi, this sounds great. I might have a chance to try it next week (back to dsl), if I have a break. But some questions in advance: - is there a release program? are the testers to make sure the implementations are working well, or do you still take requests? - what is going to happen to all this work, hopefully be integrated in pd-van/ext? - will someone put the code to work in all systems? (especially windows) - will you/your team continue to make improvements here (there are really lots of things that can be done), or was this a one-off project? - is there a feature list, to know how to test the novelties? - did you look at ? in an informal presentation here one of their developers said that he was inspired by pd, but added lots of details that make the user experience much faster and easier, sometimes just by implementing small details (let the mouse over an outlet to see the values, etc.). The patch from Joe Sarlo does the mouse-over outlet values. He called it magicglass. I think the approach should still work, the patch just needs to be applied to recent code. .hc Best, João ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
On Nov 23, 2010, at 9:29 AM, Ivica Ico Bukvic wrote: - is there a release program? are the testers to make sure the implementations are working well, or do you still take requests? Not only requests but also active contributions are very much welcome. Ideally, patches provided would be both pd vanilla and our pd-compatible, so that theoretically everyone can benefit. - what is going to happen to all this work, hopefully be integrated in pd-van/ext? I've tried sending over dozen patches upstream over the past year (and there are at least another half-dozen I need to submit). While some have made it into vanilla Pd, many of them haven't. I think partially because most of the core devs are plugging away at 0.43 which for me is a no go as of right now as I need something that is as production-ready and bug-free as possible. Other reasons include possibly the fact that some of the patches may be seen as controversial in terms of how they tackle issues. E.g. scrolling algorithm fundamentally changes how canvas spatial context is being calculated and as such it may take some time to adjust to. Tldr; While I hope all patches I've submitted do make it upstream, I have no way of knowing. 0.43 will get there and possibly soon but I don't feel comfortable running it yet. We definitely welcome improvements, the problem is that these patches are for 0.42, and the Tcl code in 0.43 has changed immensely. Hopefully you can port them to 0.43, that would be a necessary step for me to include them. - will someone put the code to work in all systems? (especially windows) That someone would have to be someone else than me as I am swamped as it is and quite frankly other OSs are not (and will likely never be) a priority in L2Ork. That said, I will gladly merge whatever improvements I can get in this respect. We've already put a decent amount of work inside pd.tk to allow better separation of Linux from other Oss in terms of customizations but it has not been consistent throughout, so it is a simple matter of tracking those inconsistencies down and adjusting accordingly. - will you/your team continue to make improvements here (there are really lots of things that can be done), or was this a one-off project? As best as we can. At this point it is mainly me and occasionally I get some student help. - is there a feature list, to know how to test the novelties? I should've done a laundry list of these as I went but somewhere along the road I lost track so honestly I don't know just how many fixes are there. That said, I am quite sure there easily dozens upon dozens of them in this release alone. - did you look at ? in an informal presentation here one of their developers said that he was inspired by pd, but added lots of details that make the user experience much faster and easier, sometimes just by implementing small details (let the mouse over an outlet to see the values, etc.). I saw it briefly and I agree there are a lot of options that could be added. I think the important question which ones should be given greatest priority. e.g. I am right now thinking it would be nice to have resizable cnv just by clicking on its bottom-right corner. Ditto for other visual iemgui objects. Another thing I would really like to see soon is ability to box-select patch cords. Then perhaps an undo doubly- linked list would be nice as well (although not sure how hard this would be). Perhaps you'd be interested in my unreleased tkwidgets library, its in SVN. Basically, I am working on creating a framework to make it much easier to make GUI objects. Part of that framework includes things like resizing things with the mouse. I have that much working but its buggy still. Once that gets ironed out, I plan on making Pd versions of all the core Tk widgets, including the Tk canvas. In tkwdigets there is already a [text] object that works quite nicely, save a few bugs. .hc HTH Best wishes, Ico Best, João ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ 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 Nov 23, 2010, at 2:55 PM, Hans-Christoph Steiner wrote: On Nov 23, 2010, at 9:29 AM, Ivica Ico Bukvic wrote: - is there a release program? are the testers to make sure the implementations are working well, or do you still take requests? Not only requests but also active contributions are very much welcome. Ideally, patches provided would be both pd vanilla and our pd-compatible, so that theoretically everyone can benefit. - what is going to happen to all this work, hopefully be integrated in pd-van/ext? I've tried sending over dozen patches upstream over the past year (and there are at least another half-dozen I need to submit). While some have made it into vanilla Pd, many of them haven't. I think partially because most of the core devs are plugging away at 0.43 which for me is a no go as of right now as I need something that is as production-ready and bug-free as possible. Other reasons include possibly the fact that some of the patches may be seen as controversial in terms of how they tackle issues. E.g. scrolling algorithm fundamentally changes how canvas spatial context is being calculated and as such it may take some time to adjust to. Tldr; While I hope all patches I've submitted do make it upstream, I have no way of knowing. 0.43 will get there and possibly soon but I don't feel comfortable running it yet. We definitely welcome improvements, the problem is that these patches are for 0.42, and the Tcl code in 0.43 has changed immensely. Hopefully you can port them to 0.43, that would be a necessary step for me to include them. - will someone put the code to work in all systems? (especially windows) That someone would have to be someone else than me as I am swamped as it is and quite frankly other OSs are not (and will likely never be) a priority in L2Ork. That said, I will gladly merge whatever improvements I can get in this respect. We've already put a decent amount of work inside pd.tk to allow better separation of Linux from other Oss in terms of customizations but it has not been consistent throughout, so it is a simple matter of tracking those inconsistencies down and adjusting accordingly. - will you/your team continue to make improvements here (there are really lots of things that can be done), or was this a one-off project? As best as we can. At this point it is mainly me and occasionally I get some student help. - is there a feature list, to know how to test the novelties? I should've done a laundry list of these as I went but somewhere along the road I lost track so honestly I don't know just how many fixes are there. That said, I am quite sure there easily dozens upon dozens of them in this release alone. - did you look at ? in an informal presentation here one of their developers said that he was inspired by pd, but added lots of details that make the user experience much faster and easier, sometimes just by implementing small details (let the mouse over an outlet to see the values, etc.). I saw it briefly and I agree there are a lot of options that could be added. I think the important question which ones should be given greatest priority. e.g. I am right now thinking it would be nice to have resizable cnv just by clicking on its bottom-right corner. Ditto for other visual iemgui objects. Another thing I would really like to see soon is ability to box-select patch cords. Then perhaps an undo doubly- linked list would be nice as well (although not sure how hard this would be). Perhaps you'd be interested in my unreleased tkwidgets library, its in SVN. Basically, I am working on creating a framework to make it much easier to make GUI objects. Part of that framework includes things like resizing things with the mouse. I have that much working but its buggy still. Once that gets ironed out, I plan on making Pd versions of all the core Tk widgets, including the Tk canvas. In tkwdigets there is already a [text] object that works quite nicely, save a few bugs. I forgot to add, my experience with the iemgui code has told me that they would be very difficult to improve, hence the tkwidgets lib. .hc The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ 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)
Perhaps you'd be interested in my unreleased tkwidgets library, its in SVN. Basically, I am working on creating a framework to make it much easier to make GUI objects. Part of that framework includes things like resizing things with the mouse. I have that much working but its buggy still. Once that gets ironed out, I plan on making Pd versions of all the core Tk widgets, including the Tk canvas. In tkwdigets there is already a [text] object that works quite nicely, save a few bugs. I forgot to add, my experience with the iemgui code has told me that they would be very difficult to improve, hence the tkwidgets lib. Unfortunately, if it is not finished/stable, I am not interested in it as having to deal with Pd bugs in and of themselves is demanding enough on my time. On a flip side Scope~ external already has similar functionality which seems to me quite complete so it may be simply a matter of implementing that one (obviously it would only apply to iemgui objects as vanilla objects have no way of knowing their own size). That said, I did spend most of today implementing Sarlo's feature as well as fixing buggy Tcl/Tk behavior (namely inability to show check marks in the edit menu which is so disheartening it is not even funny--I really think Pd needs to wean itself away from the Tcl/Tk abomination even if that means losing a good chunk of its externals before it can thrive). NB: I left out drop shadows part as it seems quite redundant. I also changed how the rest of the code behaves/looks to make it visually cleaner/more consistent. Apart from that latest update also includes edit menu highlighting (as 0.43 does to bypass Tcl/Tk buggy junk), improved shortucts for some of the calls, bugfix in the window list menu which for some reason omits parent window listing, and other minor cosmetic fixes (e.g. highlighting color changed to orange as I feel it is much easier on my eyes). If interested, check out the latest snapshot at the usual place: 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Wed, 11/24/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Hans-Christoph Steiner h...@at.or.at Cc: pd-list@iem.at, 'João Pais' jmmmp...@googlemail.com Date: Wednesday, November 24, 2010, 12:10 AM Perhaps you'd be interested in my unreleased tkwidgets library, its in SVN. Basically, I am working on creating a framework to make it much easier to make GUI objects. Part of that framework includes things like resizing things with the mouse. I have that much working but its buggy still. Once that gets ironed out, I plan on making Pd versions of all the core Tk widgets, including the Tk canvas. In tkwdigets there is already a [text] object that works quite nicely, save a few bugs. I forgot to add, my experience with the iemgui code has told me that they would be very difficult to improve, hence the tkwidgets lib. Unfortunately, if it is not finished/stable, I am not interested in it as having to deal with Pd bugs in and of themselves is demanding enough on my time. On a flip side Scope~ external already has similar functionality which seems to me quite complete so it may be simply a matter of implementing that one (obviously it would only apply to iemgui objects as vanilla objects have no way of knowing their own size). Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue). -Jonathan That said, I did spend most of today implementing Sarlo's feature as well as fixing buggy Tcl/Tk behavior (namely inability to show check marks in the edit menu which is so disheartening it is not even funny Wouldn't it be easier just to toggle the text for that menu option between Edit mode and Run mode? (That's what they're called in the manual.) --I really think Pd needs to wean itself away from the Tcl/Tk abomination even if that means losing a good chunk of its externals before it can thrive). How would you go about doing that? NB: I left out drop shadows part as it seems quite redundant. I also changed how the rest of the code behaves/looks to make it visually cleaner/more consistent. Apart from that latest update also includes edit menu highlighting (as 0.43 does to bypass Tcl/Tk buggy junk), improved shortucts for some of the calls, bugfix in the window list menu which for some reason omits parent window listing, and other minor cosmetic fixes (e.g. highlighting color changed to orange as I feel it is much easier on my eyes). If interested, check out the latest snapshot at the usual place: 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 ___ 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)
Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue). Good to know. I will look into this when I get there. Currently working on accelerating iemgui objects as well as exposing them to sarlo's highlighting magic. Wouldn't it be easier just to toggle the text for that menu option between Edit mode and Run mode? (That's what they're called in the manual.) Sure. There are other options, too, like the one 0.43 and now l2ork version of 0.42 uses by changing option's background which works visually relatively well (albeit at the expense of consistency). This is however not the issue. The issue is finding out that after an hour of debugging the problem is not in you or your code but the toolkit you are using and in 2010 for a toolkit that has been around for more than a decade that is plainly sad. How would you go about doing that? A: Ugly path: Isolate pd-gui hooks and port the entire thing to Qt. B: Better (albeit more time-consuming) path: clean-up code first so that all objects can utilize the same gobj_whatever calls and then do the A: (which at that point won't be nearly as ugly or difficult to maintain). FWIW, my first ever GUI app was RTMix I did back in 2001 and it was (and remains) the ugliest hack ever (basically I tried to learn how to program doing that app). Yet, the fact remains even in 2001 qt was way better than what Tk is today. Another advantage is avoiding socket bottlenecks as the entire thing could be done simply in C. License-wise it should be fine and cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for good measure since that is apparently hot item these days. That said, I need some more time working with Pd code before I can undertake this. Perhaps more importantly, I just need a generous, uninterrupted chunk of time to do this. Best wishes, 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)
Hi, The binary 'just worked' on ubuntu 10.04. Haven't had much time to do real testing though (opened, connected jack, test audio basically). Could you elaborate a little on the gui improvements? Does this impact (improve) performance with many gui elements (such as sliders, numberboxes etc.)? Thanks, Lorenzo Ivica Ico Bukvic wrote: The front/back option works on as many selected objects as you like. Simply select objects you wish to be moved, right click, and then select the desired action. That said I do agree that it would be probably a good idea to also have a keyboard shortcut and place them in the menu. Jonathan Wilkesjancs...@yahoo.com wrote: One comment about bring to front/send to back: * I think I'd rather see this as Edit menu options that work on all selected objects, rather than per object. This would be more useful for those situations where people are building complex GUIs. (And if necessary it could have a keyboard shortcut.) This would allow the right-click menu to retain its simplicity of having only those three options that are of general use to the user. (I think bring to front/send to back is a wonderful feature but it's definitely way more specialized than getting help, GUI properties, or opening a subpatch). One thing I'm noticing about the new connection icon: if I point the mouse over an outlet and then move the mouse about 20-40 pixels to the right, the connection icon remains even though it won't spawn a wire if I click and drag. -Jonathan --- On Sun, 11/21/10, Ivica Ico Bukvici...@vt.edu wrote: From: Ivica Ico Bukvici...@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Pd-list@iem.at Date: Sunday, November 21, 2010, 4:52 PM Also, forgot to mention in my original email this version AFAIK fixes all graph-on-parent bugs. Just remembered a few more that some of you might find useful: *send to back/bring to front right-click menu for those of you interested in building more complex UIs *auto-update of scrollbars when typing/resizing objects *canvas always tries to fit the entire patch as best as it can (it is not any more 0,0 coord-centric, however, so it will not reopen patches the way they may have looked in the vanilla-version of pd) *text editing has ctrl+home and ctrl+end traversal between space-delimited words *select all is context sensitive (so when editing an object select all will select all its text rather than all objects on the canvas) *select/cut/copy/paste is universal (works seamlessly across text fields and canvas) *commands are ignored in contexts where they have no purpose (e.g. create an object shortcut invoked on the main canvas should have no effect) *improved accuracy of canvas reporting it has been changed Cheers! Best wishes, Ico ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
-Original Message- From: Menno van der Woude [mailto:menn...@gmail.com] Sent: Sunday, November 21, 2010 5:21 PM To: Ivica Ico Bukvic Cc: Pd-list@iem.at Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To solve the problem with the tk library, I had to install package tk-dev. Same for tcl, installed package tcl8.5-dev. After installing these packages I I was able to complete the build process specified in the email (not as is written in the INSTALL text file in the tarball). Now this pd version starts with no problems. Sound works, using Alsa. I did ./configure --enable-jack, but jack is not available in the audio menu. Have not yet had time to look further into functionality. Did notice that using the send to back/bring to front functionality (which is nice!) does reset all the visual controls in a patch. You need yo also install jack-dev to be able to install with jack. Monitor ./configure output to learn what you are missing. ___ 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)
Attached is another example: 1. Select all the [clip] objects. 2. Move them so the [vsl] overlaps them. 3. Right-click the bottom [clip] and choose To front. It works as it should. 4. Now, with all the [clip] objects still selected, right-click on the same bottom [clip] and choose To back. It deselects all the other clips and only moves the bottom [clip] to the back. But shouldn't it instead move all the selected objects behind the [vsl]? You are correct. Just fixed this bug, changed the edit menu ordering and included to front/back options, added key shortcuts, added tidy up shortcut and increased its threshold which IMHO makes it much more usable. HTH ___ 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 Mon, 11/22/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at Date: Monday, November 22, 2010, 9:44 PM Attached is another example: 1. Select all the [clip] objects. 2. Move them so the [vsl] overlaps them. 3. Right-click the bottom [clip] and choose To front. It works as it should. 4. Now, with all the [clip] objects still selected, right-click on the same bottom [clip] and choose To back. It deselects all the other clips and only moves the bottom [clip] to the back. But shouldn't it instead move all the selected objects behind the [vsl]? You are correct. Just fixed this bug, changed the edit menu ordering and included to front/back options, added key shortcuts, added tidy up shortcut and increased its threshold which IMHO makes it much more usable. Regarding tidy up-- are you referring to XTOLERANCE, YTOLERANCE, and NHIST? If so, I posted a message awhile back with what seemed like some decent values, but in some cases it would swap the position of two objects in a row or column. Also, this behavior changed depending on the order in which those objects were created. (I have a feeling this is why those values are set so low.) If you post another tar.gz with your new tidy I'll see if I can reproduce this behavior. -Jonathan HTH ___ 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)
Regarding tidy up-- are you referring to XTOLERANCE, YTOLERANCE, and NHIST? If so, I posted a message awhile back with I set it to 20 20 15 respectively and it seems to do the trick in tests I did so far. what seemed like some decent values, but in some cases it would swap the position of two objects in a row or column. Also, this behavior changed depending on the order in which those objects were created. (I have a feeling this is why those values are set so low.) If you post another tar.gz with your new tidy I'll see if I can reproduce this behavior. Oops, forgot to post this one, haven't I? :-) Same place, same links: http://l2ork.music.vt.edu/main/?page_id=56 HTH Best wishes, 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 Tue, 11/23/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: RE: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: 'Jonathan Wilkes' jancs...@yahoo.com Cc: pd-list@iem.at Date: Tuesday, November 23, 2010, 2:27 AM Regarding tidy up-- are you referring to XTOLERANCE, YTOLERANCE, and NHIST? If so, I posted a message awhile back with I set it to 20 20 15 respectively and it seems to do the trick in tests I did so far. what seemed like some decent values, but in some cases it would swap the position of two objects in a row or column. Also, this behavior changed depending on the order in which those objects were created. (I have a feeling this is why those values are set so low.) If you post another tar.gz with your new tidy I'll see if I can reproduce this behavior. Oops, forgot to post this one, haven't I? :-) Same place, same links: http://l2ork.music.vt.edu/main/?page_id=56 Great, I'll play around with it a bit. -Jonathan HTH Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
