Re: [PD] [Bulk] gui toolkits
On 24/12/2014 06:18, Jonathan Wilkes via Pd-list wrote: Hi list, I've been investigating other guis as possible replacements for tcl/tk gui. A few reasons: * tk is slow to redraw * no anti-aliasing except on OSX * poor support for theming * poor support for standard image formats * binary alpha channel * limited control of font properties on canvas * lack of proper canvas zooming * non-standard file save/open dialogs * lack of common gui-toolkit tools like tooltips and rich text * too much bit-rot in third-party libraries to work around all the above Good point. In my opinion, graphical stuff requires a lot of effort (in code/design and, of course, for the portability). I really *LOVE* the pd (well... I prefer pd-extended :) ) graphical philosophy: small bocks, no exploding rainbows of color. Simple and elegant. Can be better? Probably. Especially considering the issues presented by Jonathan. But I think that will be a huge milestone (in terms of effort). Ok... the modular nature of pd can help a lot in order to make smooth transitions. To the technical side, which tk? 1. JUCE: multiplatform 2. FlowCanvas (now Ganv, http://drobilla.net/software/flowcanvas/): technically is not a tk, but a widget for Gtkmm, but its a nice widget for drawing boxes and lines (cit. Drobilla) stuff. Cheers Alessio [CUT] -Jonathan ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- a. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Bulk] gui toolkits
On Dec 24, 2014 11:49 AM, Alessio Degani alessio.deg...@ymail.com wrote: On 24/12/2014 06:18, Jonathan Wilkes via Pd-list wrote: Hi list, I've been investigating other guis as possible replacements for tcl/tk gui. A few reasons: * tk is slow to redraw * no anti-aliasing except on OSX * poor support for theming * poor support for standard image formats * binary alpha channel * limited control of font properties on canvas * lack of proper canvas zooming * non-standard file save/open dialogs * lack of common gui-toolkit tools like tooltips and rich text * too much bit-rot in third-party libraries to work around all the above Good point. In my opinion, graphical stuff requires a lot of effort (in code/design and, of course, for the portability). I really *LOVE* the pd (well... I prefer pd-extended :) ) graphical philosophy: small bocks, no exploding rainbows of color. Simple and elegant. Can be better? Probably. Especially considering the issues presented by Jonathan. But I think that will be a huge milestone (in terms of effort). Ok... the modular nature of pd can help a lot in order to make smooth transitions. Actually, it is not that much of work. Porting to tkpath took me no more than a couple of days. Granted, tkpath is quite similar to tcl/tk but the principle is the same. Alas, tkpath is defunct project. The real leap in the gui will happen once/if/when networked nature of communication between pd and tcl is replaced with threaded design. This will solve a good chunk of determinacy issues and likely introduce new problems, but the gui will be likely way more responsive. To the technical side, which tk? 1. JUCE: multiplatform Licensing is fairly restrictive, though, in comparison to alternatives. Benefits obvious (Max uses it). 2. FlowCanvas (now Ganv, http://drobilla.net/software/flowcanvas/): technically is not a tk, but a widget for Gtkmm, but its a nice widget for drawing boxes and lines (cit. Drobilla) stuff. Cheers Alessio [CUT] -Jonathan ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- a. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gui toolkits
Hi Jonathan, I can't weight in or help, as this is outside of my capabilities. But if anything is needed for grunt work - testing (on all systems), documentation, etc, I can help. Best, Joao___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] touchosc and Pd with GEMWIN - connection crashes
Hi all I am using touchosc to feed acceleremoeter data to a patch in Pd where I control the position of a shape in the Gem window. After I |create( the gemwin the OSC connection stops working. If I restart Pd it still works, does anybody have an idea why this happens? I am running Pd Vanilla + extensions, on Xubuntu 14.04 64Bytes. Thanks -- mickmengucci.bandcamp.com facebook.com/mickmengucci3 facebook.com/Labio.pt http://WWW.MISTURAPURA.NETMISTURAPURA.NET http://WWW.MISTURAPURA.NET pure mixture vibration since 1995 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] future PD-extended development
On 12/23/2014 10:09 PM, Dan Wilcox wrote: How many people currently have access to the SVN? 37 Also, doesn’t upstream prefer Git anyway? who knows. upstream for various externals *not* miller. afaik, most upstreams work directly in the SVN (if they still work on the externals). i for myself, would happily move all of my stuff to git (some of my externals already switched and are synched back to svn every now and then) fgamsr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gui toolkits
On 12/24/2014 01:35 AM, Dan Wilcox wrote: On Dec 24, 2014, at 12:18 AM, pd-list-requ...@lists.iem.at mailto:pd-list-requ...@lists.iem.at wrote: Of course if someone with the knowledge and energy to do this the right way has any suggestions, I'm all ears. I have the inkling that if I could employ a full-time dev to do my bidding then Qt Quick would the right way to go-- it's in Debian, is cross-platform, well-documented, and it certainly has enough features for Pd's canvas editing. Actually 2 things come to mind: * Cairo http://cairographics.org for rendering and something else like QT or a layer below tk for the chrome. We use cairo for pdf rendering in OpenFrameworks, among a few other things. Last time I looked I didn't see any maintained bridges between tk and Qt. tkpath uses Cairo to actually draw the vector graphics, but... you're still using tk which turns out to be the bottleneck. (And tkpath is abandon-ware, unfortunately.) * Juce http://www.juce.com: It’s aimed at audio, cross platform, and Max has used it since Max 5. I used it at one place I worked and it can do quite alot actually. Cross-platform is good. Unfortunately, it isn't a big benefit that Max uses it because Max doesn't provide any documentation or code for us to follow in a potential port. I think Qt has a larger userbase and more docs so I prefer it, but I know Juce has a lot of fans. But I don't know how to retrofit a c program like Pd with Qt, nor how to replace Pd's current string-based communication with whatever one is supposed to use to do that. I guess you don’t really retrofit the existing Pd, but rebuild it. Chris and I have done this with DroidParty PdParty to some small degree using libpd. Sending messages and samples to and from the dsp engine is working. If that could be expanded to the requisite GUI calls, then bringing patch editing could be next. libpd currently has “sendFloat”, “sendSymbol” etc, off the top of my head we could add something like “createCanvas” which returns a canvas pointer, etc. In the case of libpd, you don’t communicate with the dsp engine over a socket but by function calls. Obviously you could use a socket and pass data along from a separate GUI which then calls the functions. I’m just musing here that it’d be nice to abstract the dsp graph, canvas, etc within libpd. That would at least make it possible to support patch creation and editing in PdParty, etc without rolling something myself. If did have to, I’d rather do it in a generic way inside libpd so Chris could use it DroidParty or I could add it to ofxPd, etc. Well, let's take Qt. matju actually added some code to Pd-l2ork to start a Qt gui in a separate thread. He did it by adding to Pd's extant makefile and source. It successfully runs and creates a Qt window with some menus. But any time I try to add a Qt lib I get a segfault. All of Qt's docs assume either that I'm using QtCreator or that I have c++ business logic, so I'm a bit stuck. Presumably I'd want to create a project in QtCreator for the GUI. libpd has hooks for C++ so I suppose I can import that into the project somehow. But then I also need to have a separate thread for libpd than the GUI, and a new mechanism similar to sys_vgui or vmess to move data back and forth between GUI thread and Pd core thread. However, this is where it gets tricky. There are cases where Pd needs to use the getrect function or other coordinate data in the course of calculating a depth-first object chain, a block, or possibly both ([cnv] get_pos, [inlet], data structures, some externals). There are also cases where the user programmatically change coordinate data for such objects, including iemguis with delta and pos. If GUI manipulation happens only in the GUI thread (i.e., we completely separate Pd into GUI thread and audio/message thread), a patch currently using [cnv] get_pos method for a crude control surface will break. This is because the coordinate data is only being updated on the GUI side, and not reported back to the core. (Even if the core updates the GUI with programmatic coordinate changes.) If, on the other hand, the core is changed so that it queries the GUI to get coordinate data (for example), you either must block until the GUI returns-- which is bad-- or query ansynchrously which breaks determinism-- which is worse. Finally, if you continually send the relevant GUI event data to the Pd core (mouse motion, clicks, keyboard events), then you're back to what tcl/tk currently does. I know Desiredata essentially made a copy of the patch structure on the tcl/tk side and then attempted to keep both the client (GUI) and server (Pd core) synchronized. That seems to me to be rather complicated and prone to error. So what do you see as a workable solution to Qt + libpd with this in mind? The only path I see is to incrementally move from tcl/tk to the other toolkit, and then when
Re: [PD] Pd-list Digest, Vol 117, Issue 86
The current state is that it’s not dead, but moribund unless someone wants to take it over. You may not have noticed, but we’ve been discussing ways to provide the extended externals for use with PD vanilla, etc Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/ On Dec 24, 2014, at 1:38 PM, pd-list-requ...@lists.iem.at wrote: From: João Pais jmmmp...@googlemail.com mailto:jmmmp...@googlemail.com To: PD-List pd-l...@iem.at mailto:pd-l...@iem.at Date: December 24, 2014 at 8:00:15 AM EST Subject: [PD] Updating Pd-Extended Hello list, I wanted to ask, what is the current state of the pd-extended distribution? Pd-vanilla has had some regular updates recently (some of them with interesting developments), but the latest pd-ext version is still from almost 2 years ago. Best, jmmmp ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
