> Did you try the current GUI rewrite? > > http://puredata.info/dev/PdGuiRewrite > > .hc
Hi Hans, Please allow me to chime in here for the sake of clarifying a few things about this project. First of all, allow me to state that I honestly appreciate all the efforts being made in respect to the GUI rewrite. Yet, after messing with Tcl/Tk implementation over the past 9+ months, including SVN checkouts of the GUI-rewrite branch, I personally find Tcl/Tk solution inadequate for L2Ork's needs as we do depend in large part on GUI feedback and Tcl/Tk has so far proven quite inefficient, or more precisely CPU-hungry. For instance, having 5 tables displayed concurrently and updating their information every n samples (not that you would want to have this as part of the gui, but hopefully this will drive the point home, since similar setup using Max/JUCE yields literally no CPU overhead), or having a large-font-sized number box updating rapidly--even at lower update rates, this effectively requires a huge chunk of CPU on a typical Atom-based netbook. Hence, I personally feel going after JUCE or Qt still allows Pd to be as platform-agnostic as Pd currently is (with the exception that these are AFAIK using GPL as opposed to BSD license), while also providing significant performance improvement. Max has certainly made a great use of JUCE and I still have fond memories of working with Qt while learning to program my first GUI applications. I do understand that a good part of the community may not appreciate yet another attempt at GUI rewrite as much than contributing our time and energy to the existing GUI-rewrite projects. From this perspective I think you, Hans, and those helping you on the GUI-rewrite project are doing a great service to the community. Yet, IMHO I feel that Tcl/Tk is a dead-end for L2Ork's needs in the long run and I would really like to see Pd wrapped in a new and more contemporary toolkit even if that means losing real-time scripting advantages of Tcl/Tk (which is something we can always work around later, if necessary). I also suspect that this new implementation may in part or entirely break backwards compatibility in order to allow for GUI to be as customizable as possible, meaning that patches may contain considerably more information about each object in order to allow for additional information to be stored. Yet, even this hurdle could be overcome by providing ability to open older patches and saving them in newer format. Despite a rather fundamentally different approach to GUI, I am sincerely hoping that we could somehow maintain this implementation in sync with the main branch, but am also aware that this may be impossible at first until our branch stabilizes. In addition, I am very much aware that such a sync may also require agreement from the community's perspective to allow alterations to the way Pd's code is structured which is something I by no means am expecting, but rather am kindly asking for everyone to consider in order for the community at large to be able to eventually benefit from our contribution. Right now we have two students who are being assigned to work on this for a good chunk of a semester with a possibility of throwing more students at the task down the road. I think having community support would be a tremendous benefit to our project and efforts and we would certainly welcome anyone who wishes to join/contribute to our efforts. At any rate, just my 0.000001-cents worth... Best wishes, Ico _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
