Re: [PD] Pd-extended 0.43 updates: lots of new editing features
On Jul 17, 2011, at 9:30 PM, athos bacchiocchi wrote: 2011/7/5 Hans-Christoph Steiner h...@at.or.at http://autobuild.puredata.info/auto-build/latest/ I recently did a push to fix key bugs to get the Pd-extended 0.43 nightly builds in a useable state. I tried to install it in ubuntu 10.10 maverick (using the corrensponding i386 deb package). No icon appeared in the gnome panel menu, using pd-extended i get the command not found message. I checked the /usr/bin folder, and i found pd, tried to launch it but i got this: priority 6 scheduling enabled. priority 8 scheduling enabled. sh: /usr/bin/pd-watchdog: not found Error in startup script: couldn't read file /usr/tcl//pd-gui.tcl: no such file or directory Unfortunately, the maverick build server went down, so you downloaded an old build. If you look at the date of the build you downloaded, it says 21-Jun-2011. Its not hard to build the package on Ubuntu, you just need to download the code via rsync, install the right packages, then run the script: http://puredata.info/docs/developer/GettingPdSource http://puredata.info/docs/developer/UbuntuMaverick http://puredata.info/docs/developer/AutoBuildProcess .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] Pd-extended 0.43 updates: lots of new editing features
On Jul 17, 2011, at 1:15 PM, Mathieu Bouchard wrote: On Fri, 8 Jul 2011, Jonathan Wilkes wrote: --- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-) Yes, I would hope that making changes to the core of the largest free software project in the history of computing is a wee bit more difficult than making changes to Pd. It's easy to use the Linux project as a reference, to justify that submitting changes to Pd ought to remain hard and that things are just fine as they are now. After all, the Linux project is a well- respected success story, nevermind that it's a project so different from pd in many ways. Just more expressions of millercentrism... nothing to see, move along... Think about why it remains hard. Managing patches is a lot of work, and its not fun, unless the patch happens to fix something that you want fixed. This is almost all work on people's own time. Start a fork, git makes it much easier. Then you can have your own version that includes every patch that you want it to. DesireData was a great effort, pd-devel too. Pd-extended is another example, as well as pd_l2ork. If we all use git forked from Miller's pure-data git it makes keeping in sync vastly easier than before. Git has a steep learning curve. Take 2 days to really study and learn it, and it will save you vast amount of time tracking code and bisecting for patches. Having multiple forks in rough sync all working with git means that more patches get accepted, written, tested, etc. .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
On Fri, 8 Jul 2011, Jonathan Wilkes wrote: --- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-) Yes, I would hope that making changes to the core of the largest free software project in the history of computing is a wee bit more difficult than making changes to Pd. It's easy to use the Linux project as a reference, to justify that submitting changes to Pd ought to remain hard and that things are just fine as they are now. After all, the Linux project is a well-respected success story, nevermind that it's a project so different from pd in many ways. Just more expressions of millercentrism... nothing to see, move along... ___ | 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] Pd-extended 0.43 updates: lots of new editing features
On Mon, 11 Jul 2011, Jonathan Wilkes wrote: All you add on the pd side is a sys_gui call to create the binding, then handle everything else on the tcl side. Does that make sense? It's one easy way of doing it. You could also define a proc so that the contents of the sys_gui call is as short as possible, if that makes any difference. Also doesn't address tooltips for abstractions. Why ? abstractions have accompanying *-help.pd files too... ___ | 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] Pd-extended 0.43 updates: lots of new editing features
On Sat, 16 Jul 2011, Jonathan Wilkes wrote: --- On Sat, 7/16/11, Mathieu Bouchard ma...@artengine.ca wrote: 3. Tell the value last put in an inlet, if it's currently stored (and if the concept makes sense for that particular inlet). If this is desired, then it's probably better to do everything except draw the tooltip window on the c side. Why ? That's plenty. The only thing that sucks harder than being annoyed by tooltips is being annoyed by gigantic tooltips -[gigantic tooltips have lots and lots and lots of text inside them. They were designed by geniuses who think that informative paragraphs of text are important enough to interrupt the main interface view, yet ephemeral enough that a single accidental mouse movement of 2 pixels can cause the whole tooltip to]. Well, «tooltips» don't have to be implemented as bad as you describe, and for example, they don't have to be necessarily tooltips, and they don't have to display information that the user doesn't want to see. Thus there can be features to display that info differently than as tooltips : statusbar, sidebar, or tooltip-like boxes that don't necessarily activate on Enter or don't necessarily deactivate on Leave. Implement whatever is comfortable and useful. What would be a good way to toggle «enable inlet name tooltips», «enable method-list tooltips», etc., as separate settings ? ___ | 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] Pd-extended 0.43 updates: lots of new editing features
On Sat, 9 Jul 2011, Jonathan Wilkes wrote: I read a white paper on total development cost of a linux distro and just remembered linux. I think the distro in the paper was Fedora 9, which was estimated to be almost an order of magnitude more expensive than the Linux kernel. That estimation model probably considers Linux as a part of Fedora, and every other piece of software of Fedora as being part of Fedora. Do you have any link to that paper ? ___ | 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] Pd-extended 0.43 updates: lots of new editing features
--- On Sun, 7/17/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Martin Peach martin.pe...@sympatico.ca, pd-list pd-list@iem.at Date: Sunday, July 17, 2011, 8:22 PM On Sat, 16 Jul 2011, Jonathan Wilkes wrote: --- On Sat, 7/16/11, Mathieu Bouchard ma...@artengine.ca wrote: 3. Tell the value last put in an inlet, if it's currently stored (and if the concept makes sense for that particular inlet). If this is desired, then it's probably better to do everything except draw the tooltip window on the c side. Why ? That's plenty. The only thing that sucks harder than being annoyed by tooltips is being annoyed by gigantic tooltips -[gigantic tooltips have lots and lots and lots of text inside them. They were designed by geniuses who think that informative paragraphs of text are important enough to interrupt the main interface view, yet ephemeral enough that a single accidental mouse movement of 2 pixels can cause the whole tooltip to]. Well, «tooltips» don't have to be implemented as bad as you describe, and for example, they don't have to be necessarily tooltips, and they don't have to display information that the user doesn't want to see. Thus there can be features to display that info differently than as tooltips : statusbar, sidebar, or tooltip-like boxes that don't necessarily activate on Enter or don't necessarily deactivate on Leave. Implement whatever is comfortable and useful. What would be a good way to toggle «enable inlet name tooltips», «enable method-list tooltips», etc., as separate settings ? Probably just a drop-down list in a menu. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
2011/7/5 Hans-Christoph Steiner h...@at.or.at http://autobuild.puredata.**info/auto-build/latest/http://autobuild.puredata.info/auto-build/latest/ I recently did a push to fix key bugs to get the Pd-extended 0.43 nightly builds in a useable state. I tried to install it in ubuntu 10.10 maverick (using the corrensponding i386 deb package). No icon appeared in the gnome panel menu, using pd-extended i get the command not found message. I checked the /usr/bin folder, and i found pd, tried to launch it but i got this: priority 6 scheduling enabled. priority 8 scheduling enabled. sh: /usr/bin/pd-watchdog: not found Error in startup script: couldn't read file /usr/tcl//pd-gui.tcl: no such file or directory bye, athos ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
On Wed, 13 Jul 2011, Jonathan Wilkes wrote: I'm not doing it that way. I'm looking up the xlet info in the help patch in [pd META] when the xlet is created, then putting the relevant text as an argument to the command that gets binded to the xlet tag's Enter and Leave events. Better to just add a few lines of tcl to gather the relevant info from your help docs. I wonder whether there might be any other reasons to have an assist-method in a way that can't be done in any other way. What are the possible use for the tooltips ? 1. Tell the name of the inlet. This is not an info already present in the class, and usually not in the docs either. 2. Tell the list of methods. 3. Tell the value last put in an inlet, if it's currently stored (and if the concept makes sense for that particular inlet). 4. Other. (which uses ?) I think that you are mostly only thinking about #2, and Günter's system was only taking care of #1, and I think that there was a pd-list discussion about something like #3 a long time ago. I don't know what's available in MAX, and I don't think that it necessarily has to be implemented in the same way. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
On Mon, 11 Jul 2011, Jonathan Wilkes wrote: I don't get the idea of having a new method that's supposed to be hidden from the user (but really isn't) for every object that wants tooltips; Forget about how MAX does it and how bad that might be : just define an assistfn field in t_class and the problem you mention will not happen. Did desiredata have tooltips? If so, how were they implemented? Nothing fantastic. Because desiredata was a fork of devel_0_39, it had Günter's tooltips, and I modified them so that they look like other apps' existing tooltips (yellow rectangles with the usual mouse behaviour) and I didn't have time to improve the concept further. I think that dd's tooltips would crash dd but I don't remember whether I fixed it or not. In any case, dd's tooltip code is only relevant because of the yellow rectangle / mouse behaviour thing, and that's because it's standard GUI behaviour, nothing original. And as Günter's, it only did inlet-names, not method-lists nor any other things that could be interesting to have in tooltips. DD's class-browser could list first-inlet methods, but pd's whole internals-design prevents listing all methods in the class-browser. It's easier to do it on a live object. The exception to this is GridFlow's [gf/class_info], which can list all methods of any GF class without instantiating, but that doesn't work on non-GF classes. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
On Mon, 11 Jul 2011, Martin Peach wrote: OK, but the object is responsible for knowing where it is, not Pd. If the string is generated on-the-fly or stored elsewhere the object will have allocated the memory for it. Well, if pd has a default assist-method, externals might need a way to give info to that assist-method so that it can do its own work. That would be in t_class and in t_inlet. In theory, tooltip strings could be stored in something at the class-level instead of the object-level, just like methods called at the object-level refer to a method-table stored at the class-level. That is indeed what happens: a shared library has a section for strings (or data). Unless it is generating them on-the-fly, each instance of the class will refer to the same location in memory for its strings. I mean exactly what I write, something at the class-level, not something at the executable-level. That's because I'm thinking about a default assist-method. If there is no assist method, then Pd would use a default string from its own class, depending on what types were registered to that inlet/outlet at creation time. There are several different purposes for the assist-method. Naming inlets is one. Listing methods of an inlet is another. There are others. We have to decide which such features we want to support, and then we will be able to figure out what we need to add in t_class. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
On Sun, 10 Jul 2011, Jonathan Wilkes wrote: This brings up an issue I've been wondering about since learning a little more about the canvas editor: why does the pd gui send 'motion' messages to pd? Why not, for example, just have a tag for an inlet rectangle and bind Enter and Leave to it? Then you'd only be sending messages from the gui for the events you care about, instead of tons of motion messages that don't trigger anything. Just because almost all the canvas patching operations (create box, edit box, delete box, select box, connect, disconnect, etc) are made completely from server side computations without using any Enter, Leave nor TkCanvas's find overlapping feature. DD used find overlapping. It finds the list of canvas-items that intersects a given rectangle. Then DD had a standard tag system in which mandatory tags allowed DD itself to figure out the origin of a certain item and trace it back to an object. That allowed to delete a chunk of C code, but to remove the need for 'motion' messages, a lot more work is necessary. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
--- On Sat, 7/16/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Martin Peach martin.pe...@sympatico.ca, pd-list pd-list@iem.at Date: Saturday, July 16, 2011, 5:54 PM On Wed, 13 Jul 2011, Jonathan Wilkes wrote: I'm not doing it that way. I'm looking up the xlet info in the help patch in [pd META] when the xlet is created, then putting the relevant text as an argument to the command that gets binded to the xlet tag's Enter and Leave events. Better to just add a few lines of tcl to gather the relevant info from your help docs. I wonder whether there might be any other reasons to have an assist-method in a way that can't be done in any other way. What are the possible use for the tooltips ? 1. Tell the name of the inlet. This is not an info already present in the class, and usually not in the docs either. My tooltips do that. 2. Tell the list of methods. My tooltips do that. 3. Tell the value last put in an inlet, if it's currently stored (and if the concept makes sense for that particular inlet). If this is desired, then it's probably better to do everything except draw the tooltip window on the c side. 4. Other. (which uses ?) That's plenty. The only thing that sucks harder than being annoyed by tooltips is being annoyed by gigantic tooltips -[gigantic tooltips have lots and lots and lots of text inside them. They were designed by geniuses who think that informative paragraphs of text are important enough to interrupt the main interface view, yet ephemeral enough that a single accidental mouse movement of 2 pixels can cause the whole tooltip to]. I think that you are mostly only thinking about #2, and Günter's system was only taking care of #1, and I think that there was a pd-list discussion about something like #3 a long time ago. I don't know what's available in MAX, and I don't think that it necessarily has to be implemented in the same way. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
On Mon, 11 Jul 2011, Jonathan Wilkes wrote: Well in that case, I don't see any need whatsoever for an assist method. Just have pd lookup the methods and display them. If one needs more information than that, the help patch is just two clicks away. That'll be great for learning GridFlow, as all it'll ever say is : anything because GridFlow has its own method-lookup system. That's one example of what an assist-method slot could help with. This is also usually the way that methods are registered in pd bindings for lua, tcl, and probably several more. Another totally different example is what you're supposed to do to hide kludges like the bunch of methods registered under the name ft1 that exist because pd's internals make it easier to that than to have non-first inlets act independently of first-inlets. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
--- On Thu, 7/14/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Martin Peach martin.pe...@sympatico.ca, pd-list pd-list@iem.at Date: Thursday, July 14, 2011, 3:51 AM On Mon, 11 Jul 2011, Jonathan Wilkes wrote: Well in that case, I don't see any need whatsoever for an assist method. Just have pd lookup the methods and display them. If one needs more information than that, the help patch is just two clicks away. That'll be great for learning GridFlow, as all it'll ever say is : anything I'm not doing it that way. I'm looking up the xlet info in the help patch in [pd META] when the xlet is created, then putting the relevant text as an argument to the command that gets binded to the xlet tag's Enter and Leave events. because GridFlow has its own method-lookup system. That's one example of what an assist-method slot could help with. This is also usually the way that methods are registered in pd bindings for lua, tcl, and probably several more. Better to just add a few lines of tcl to gather the relevant info from your help docs. Another totally different example is what you're supposed to do to hide kludges like the bunch of methods registered under the name ft1 that exist because pd's internals make it easier to that than to have non-first inlets act independently of first-inlets. I can't remember whether I put those in the [pd META] stuff-- but I don't think I did. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
On Sun, 10 Jul 2011, Hans-Christoph Steiner wrote: On page 32 of this document: http://peabody.sapp.org/class/dmp2/read/WritingMax_MSPExternals.pdf You can see the 'assist' message. The Max GUI sends the 'assist' message to an objectclass when you hover above an inlet or outlet, It's sent to the object, not to the objectclass. It's similar to the dsp method in that it's a special method-entry registered with A_CANT, but otherwise it's the same : it's registered in the objectclass so that it's callable in the object. It's just not available from Max itself, as A_CANT means that its input is not a Max message. I don't know anything about Max, but Max's addmess looks the same as Pd's class_addmethod, and A_CANT is exactly the same, and so are many other things when I browse around in that manual. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
The 10.4 build should work on 10.5 and 10.6. The 10.6 build is 64- bit, so its different. As for the objects not loading, try removing your preferences so that it loads its default preferences. .hc On Jul 11, 2011, at 2:10 AM, Mike Moser-Booth wrote: I just tried it on 10.5 (there doesn't seem to be a 10.5 specific build, so I tried the 10.4 build; is that expected to work?). I tried loading a few patches/abstractions of mine to see what would happen. There seems to be problems with several, but not all, of the vanilla objects. [loadbang], [wrap~], [expr~], [hslider]/[hsl], [cnv], [clip~], [namecanvas], [delay] and a few others didn't instantiate correctly. Also, the [list] family of objects didn't create if they were given an argument. .mmb 2011/7/11 Hans-Christoph Steiner h...@at.or.at I just tried today's Pd-extended 0.43.1 on chaos.medien.uni- weimar.de and it worked fine for me. Are others not able to get it to work on 10.6? .hc On Jul 7, 2011, at 6:18 PM, Max wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 todays 0.43 os x didn't even launch for me. Am 08.07.2011 um 00:07 schrieb João Pais: I tried today 0.43, and it didn't work properly. the audio was just noisy, and probably out of rate, as changing the value of the intensity in the test patch made a ramp of a few seconds, instead of ~50ms. And, when the ramp was up, instead of a sinus tone only noise came out. As I was trying that while working in a project, I couldn't spend more time with it. this was on xp, normal soundcard (with + without asio on) João http://autobuild.puredata.info/auto-build/latest/ I recently did a push to fix key bugs to get the Pd-extended 0.43 nightly builds in a useable state. Also, there is a new .zip download for Windows, so it should be really easy to try nightly builds on Windows. Just download the .zip, unzip, and double-click pd.exe in the bin folder. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk4WMMsACgkQ3EB7kzgMM6L1MQCffidIG+SpPBBwA0hIz3H4MYMT 2bAAniCwumLJ+80yHP6E8QUP1iKuUpo0 =2hXD -END PGP SIGNATURE- 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 -- Mike Moser-Booth mmoserbo...@gmail.com ¡El pueblo unido jamás será vencido! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
--- On Mon, 7/11/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Hans-Christoph Steiner h...@at.or.at Cc: Jonathan Wilkes jancs...@yahoo.com, pd-list@iem.at Date: Monday, July 11, 2011, 4:30 PM On Sun, 10 Jul 2011, Hans-Christoph Steiner wrote: On page 32 of this document: http://peabody.sapp.org/class/dmp2/read/WritingMax_MSPExternals.pdf You can see the 'assist' message. The Max GUI sends the 'assist' message to an objectclass when you hover above an inlet or outlet, It's sent to the object, not to the objectclass. It's similar to the dsp method in that it's a special method-entry registered with A_CANT, but otherwise it's the same : it's registered in the objectclass so that it's callable in the object. It's just not available from Max itself, as A_CANT means that its input is not a Max message. Does A_CANT actually work? If I do [dsp(---[+~] it crashes pd 0.43, and if I add a foo method to [bang] using A_CANT I can still send [foo(--[bang] and it will still run the method that I added. Also, what if someone is parsing arbitrary sequences of anythings-- say, with [route] or any number of other objects that have an anything method? Now those objectclasses have to choose between truly accepting any selector, or being helpful and having a tooltip. Also problems with anything outlets: for instance, [textfile] (which I've mentioned before) outputs an anything, which could possibly start with whatever symbol you attach to tooltips, thus making that message practically unusable (though unlike say float blah you won't get an error message). Unfortunately there are still lots of anything operators out there in the wild, and probably always will be, so I don't think it's a good idea to reserved a selector for a general feature like this. Here's an idea: * bind xlet rectangles to pdtk_tooltips for Enter and Leave * have a menu checkbutton for Turn on tooltips * if turned on, pdtk_tooltips sends the mouse location as args to canvas_tooltips (and whether we're entering or leaving) * canvas_tooltips checks to see if there's a box under the mouse, and if there is and it has a tooltip string, display the text in a little rectangle on the canvas. * on Leave, delete the tooltip. But I'm not sure where to store the tooltip string... -Jonathan I don't know anything about Max, but Max's addmess looks the same as Pd's class_addmethod, and A_CANT is exactly the same, and so are many other things when I browse around in that manual. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
On 2011-07-11 12:06, Jonathan Wilkes wrote: But I'm not sure where to store the tooltip string... Not sure if that's what you mean, but in max the assist method receives a number corresponding to the inlet or outlet and returns a pointer to the appropriate string, so the string is already stored somewhere in the memory allocated to the object. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
On Mon, 11 Jul 2011, Martin Peach wrote: On 2011-07-11 12:06, Jonathan Wilkes wrote: But I'm not sure where to store the tooltip string... Not sure if that's what you mean, but in max the assist method receives a number corresponding to the inlet or outlet and returns a pointer to the appropriate string, so the string is already stored somewhere in the memory allocated to the object. Not necessarily : the assist-method could be storing the data anywhere, or generating it on-the-fly from whatever. In theory, tooltip strings could be stored in something at the class-level instead of the object-level, just like methods called at the object-level refer to a method-table stored at the class-level. But Pd doesn't allow extending struct t_class by externals, and it doesn't have a tooltip field (except Günter's tooltip diff included a field for storing a symbol containing the text of the left-inlet's text... and only that). GF has its own parallel class-table for storing some meta-info, and C++'s «static members» for the rest. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
(Sorry for the do-over, Hans. I just realized I didn't copy this to the list.) I just tried it on 10.5 (there doesn't seem to be a 10.5 specific build, so I tried the 10.4 build; is that expected to work?). I tried loading a few patches/abstractions of mine to see what would happen. There seems to be problems with several, but not all, of the vanilla objects. [loadbang], [wrap~], [expr~], [hslider]/[hsl], [cnv], [clip~], [namecanvas], [delay] and a few others didn't instantiate correctly. Also, the [list] family of objects didn't create if they were given an argument. .mmb 2011/7/11 Hans-Christoph Steiner h...@at.or.at I just tried today's Pd-extended 0.43.1 on chaos.medien.uni-weimar.de and it worked fine for me. Are others not able to get it to work on 10.6? .hc On Jul 7, 2011, at 6:18 PM, Max wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 todays 0.43 os x didn't even launch for me. Am 08.07.2011 um 00:07 schrieb João Pais: I tried today 0.43, and it didn't work properly. the audio was just noisy, and probably out of rate, as changing the value of the intensity in the test patch made a ramp of a few seconds, instead of ~50ms. And, when the ramp was up, instead of a sinus tone only noise came out. As I was trying that while working in a project, I couldn't spend more time with it. this was on xp, normal soundcard (with + without asio on) João http://autobuild.puredata.**info/auto-build/latest/http://autobuild.puredata.info/auto-build/latest/ I recently did a push to fix key bugs to get the Pd-extended 0.43 nightly builds in a useable state. Also, there is a new .zip download for Windows, so it should be really easy to try nightly builds on Windows. Just download the .zip, unzip, and double-click pd.exe in the bin folder. __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk4WMMsACgkQ3EB7kz**gMM6L1MQCffidIG+**SpPBBwA0hIz3H4MYMT 2bAAniCwumLJ+**80yHP6E8QUP1iKuUpo0 =2hXD -END PGP SIGNATURE- --**--** 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 http://lists.puredata.info/listinfo/pd-list -- Mike Moser-Booth mmoserbo...@gmail.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
--- On Mon, 7/11/11, Martin Peach martin.pe...@sympatico.ca wrote: From: Martin Peach martin.pe...@sympatico.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: pd-list pd-list@iem.at Cc: Jonathan Wilkes jancs...@yahoo.com Date: Monday, July 11, 2011, 6:42 PM On 2011-07-11 12:06, Jonathan Wilkes wrote: But I'm not sure where to store the tooltip string... Not sure if that's what you mean, but in max the assist method receives a number corresponding to the inlet or outlet and returns a pointer to the appropriate string, so the string is already stored somewhere in the memory allocated to the object. Ok, I see. I don't get the idea of having a new method that's supposed to be hidden from the user (but really isn't) for every object that wants tooltips; in some cases it would subtly change the function of the object class, like [bang] and [route]. (Aside from crashing Pd, dsp isn't such a big deal because there isn't much of a need for an object that takes a signal AND parses arbitrary selectors, esp. on the same inlet.) Maybe this wouldn't be a problem if [textfile] output lists, and there was a [routelist] in Pd vanilla... Did desiredata have tooltips? If so, how were they implemented? -Jonathan Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
On 2011-07-11 13:45, Mathieu Bouchard wrote: On Mon, 11 Jul 2011, Martin Peach wrote: On 2011-07-11 12:06, Jonathan Wilkes wrote: But I'm not sure where to store the tooltip string... Not sure if that's what you mean, but in max the assist method receives a number corresponding to the inlet or outlet and returns a pointer to the appropriate string, so the string is already stored somewhere in the memory allocated to the object. Not necessarily : the assist-method could be storing the data anywhere, or generating it on-the-fly from whatever. OK, but the object is responsible for knowing where it is, not Pd. If the string is generated on-the-fly or stored elsewhere the object will have allocated the memory for it. In theory, tooltip strings could be stored in something at the class-level instead of the object-level, just like methods called at the object-level refer to a method-table stored at the class-level. That is indeed what happens: a shared library has a section for strings (or data). Unless it is generating them on-the-fly, each instance of the class will refer to the same location in memory for its strings. But Pd doesn't allow extending struct t_class by externals, and it doesn't have a tooltip field (except Günter's tooltip diff included a field for storing a symbol containing the text of the left-inlet's text... and only that). I don't see a need to extend any structs, Pd just needs to call an object's assist method whenever the mouse is hovering over one of its inlet/outlets, and display the returned string inside a box. If there is no assist method, then Pd would use a default string from its own class, depending on what types were registered to that inlet/outlet at creation time. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
--- On Mon, 7/11/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Martin Peach martin.pe...@sympatico.ca Cc: pd-list pd-list@iem.at Date: Monday, July 11, 2011, 7:45 PM On Mon, 11 Jul 2011, Martin Peach wrote: On 2011-07-11 12:06, Jonathan Wilkes wrote: But I'm not sure where to store the tooltip string... Not sure if that's what you mean, but in max the assist method receives a number corresponding to the inlet or outlet and returns a pointer to the appropriate string, so the string is already stored somewhere in the memory allocated to the object. Not necessarily : the assist-method could be storing the data anywhere, or generating it on-the-fly from whatever. Hm... 1 when creating an xlet for the first time, bind its tag on Enter and Leave to call pdtk_tooltips, and send $canvas, $inletno and $object_name as arguments 2 in tcl, search helppath for $object_name-help.pd, then parse it for $inletno (which I added as a pd META tag for every internal help patch-- plus lots of externals, too) 3 filter the matching line in tcl to display everything after $inletno minus the semicolon. (I.e., text 20 20 INLET_0 float symbol bang; becomes float symbol bang) 4 create that text on a little tooltip rectangle on $canvas; delete it on Leave All you add on the pd side is a sys_gui call to create the binding, then handle everything else on the tcl side. Does that make sense? If so, then once someone gets it working (maybe me), you'd not only have tooltips, but you'd have tooltip content for over 1000 object classes (minus exceptions like list split, and variable/rightmost inlets which I'm not sure how to handle...) Also doesn't address tooltips for abstractions. -Jonathan In theory, tooltip strings could be stored in something at the class-level instead of the object-level, just like methods called at the object-level refer to a method-table stored at the class-level. But Pd doesn't allow extending struct t_class by externals, and it doesn't have a tooltip field (except Günter's tooltip diff included a field for storing a symbol containing the text of the left-inlet's text... and only that). GF has its own parallel class-table for storing some meta-info, and C++'s «static members» for the rest. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
--- On Mon, 7/11/11, Martin Peach martin.pe...@sympatico.ca wrote: From: Martin Peach martin.pe...@sympatico.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Mathieu Bouchard ma...@artengine.ca Cc: pd-list pd-list@iem.at Date: Monday, July 11, 2011, 9:15 PM On 2011-07-11 13:45, Mathieu Bouchard wrote: On Mon, 11 Jul 2011, Martin Peach wrote: On 2011-07-11 12:06, Jonathan Wilkes wrote: But I'm not sure where to store the tooltip string... Not sure if that's what you mean, but in max the assist method receives a number corresponding to the inlet or outlet and returns a pointer to the appropriate string, so the string is already stored somewhere in the memory allocated to the object. Not necessarily : the assist-method could be storing the data anywhere, or generating it on-the-fly from whatever. OK, but the object is responsible for knowing where it is, not Pd. If the string is generated on-the-fly or stored elsewhere the object will have allocated the memory for it. In theory, tooltip strings could be stored in something at the class-level instead of the object-level, just like methods called at the object-level refer to a method-table stored at the class-level. That is indeed what happens: a shared library has a section for strings (or data). Unless it is generating them on-the-fly, each instance of the class will refer to the same location in memory for its strings. But Pd doesn't allow extending struct t_class by externals, and it doesn't have a tooltip field (except Günter's tooltip diff included a field for storing a symbol containing the text of the left-inlet's text... and only that). I don't see a need to extend any structs, Pd just needs to call an object's assist method whenever the mouse is hovering over one of its inlet/outlets, and display the returned string inside a box. If there is no assist method, then Pd would use a default string from its own class, depending on what types were registered to that inlet/outlet at creation time. Well in that case, I don't see any need whatsoever for an assist method. Just have pd lookup the methods and display them. If one needs more information than that, the help patch is just two clicks away. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
On Mon, 11 Jul 2011, Jonathan Wilkes wrote: Does A_CANT actually work? Well, maybe it doesn't... ;) Also, what if someone is parsing arbitrary sequences of anythings-- say, with [route] or any number of other objects that have an anything method? Now those objectclasses have to choose between truly accepting any selector, or being helpful and having a tooltip. That's the problem with loadbang and dsp already, and the fact that those things aren't named __loadbang__ and __dsp__, or better, !@#$%^*()loadbang and ?+[]dsp, to make them unreachable by accident. Alternately, they could be put in a parallel universe (a completely insulated namespace), such as Pd's already existing freefn, widgetbehavior, parentwidgetbehavior, savefn and propertiesfn... or else... I think that GF still uses a pseudo-inlet number -1 for internal use. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
On Fri, 8 Jul 2011, Ignacio Aguirre wrote: wow, sad to read no 64-bit builds of gem on os x yet... think i will still use 0.42.5 with no problems for me :) Can the 32-bit QuickTime API work at all in 64-bit mode ? It could explain some things... I remember that Apple designed some things as if 64-bit would never happen, and then when was the time to support 64-bit mode, they came up with a new QuickTime interface that is very much different and won't run on OSX-10.4. As a result, a different GEM component would have to be written to support the new QuickTime. Correct me if I'm wrong. No, two of them, one for the movie files, one for the cameras. I'm not saying that this is what prevents Gem from building at all... I'm not talking about that kind of problem. But to get a full 64-bit release, much of QuickTime support code has to be rewritten. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
On Sun, 10 Jul 2011, Leandro da Mota Damasceno wrote: I've just installed and tried to run pd-extended 0.43.1 on my mac and i've the following message: You replied in private. Also I'm not usually the best person to answer questions about Gem. You should definitely keep that question on mailing-lists. There's not only pd-list : you could also post on gem-dev. What I say about QuickTime is from my experience in GridFlow's dev meetings. I don't know so much about Gem, but the GridFlow project does encounter several of the same issues, so, that's why I can speak about them. Expected in: dynamic lookup This is a problem in the executable. It needs to be recompiled after a change to a makefile or perhaps to a sourcefile. mach-o, but wrong architecture This, however, is a problem in the config : you are attempting to load plugins that are made for 32-bit mode, in an app that is made for 64-bit mode. All those executables might be fine, but they can't go together. (you can also get the same message from trying to mix Intel and non-Intel parts) can't load library When such a message comes without another error message about the same plugin, it means the file was not found. ___ | 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] Pd-extended 0.43 updates: lots of new editing features
On Jul 9, 2011, at 8:07 PM, Jonathan Wilkes wrote: --- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Saturday, July 9, 2011, 10:38 PM On Jul 9, 2011, at 1:48 AM, Jonathan Wilkes wrote: --- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: [...] The problem with forks is if improvements don't migrate upstream. I think it's both a problem-with and a cause-of. Yup, that makes sense. Then we don't benefit from sharing the fixes. Making things migrate upstream takes time in itself. How does one figure out who has the responsibility to make sure things migrate upstream (for example: [initbang] and [closebang])? Mostly by someone deciding its important enough that they want to work on it themself, and then lots of testing and communication. Ok. So in patch id#2838176, what is Guenter's idea for a clean implementation of tooltips that you were referring to? I didn't find anything on the user or dev list. Hmm, I can't remember what Günter's proposal was, but I do have a vague idea of how to do it cleanly. I think it should be similar to the way its done in Max/MSP. Basically there is a standard function, something like nlet_info(), which returns the tooltip info. Pd would then check whether an object had that function when it loaded the binary, and if so register it in the tooltips. .hc Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-) Yes, I would hope that making changes to the core of the largest free software project in the history of computing is a wee bit more difficult than making changes to Pd. Actually, there are much bigger projects than Linux, things like Debian are quite a bit larger in scale. I read a white paper on total development cost of a linux distro and just remembered linux. I think the distro in the paper was Fedora 9, which was estimated to be almost an order of magnitude more expensive than the Linux kernel. -Jonathan .hc -Jonathan .hc -Jonathan And anything assigned to Miller and reviewed positively by IOhannes I'm going to defer any action on until Miller responds. .hc -Jonathan ___ 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. http://at.or.at/hans/ 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] Pd-extended 0.43 updates: lots of new editing features
On Jul 10, 2011, at 10:57 AM, Mathieu Bouchard wrote: On Fri, 8 Jul 2011, Ignacio Aguirre wrote: wow, sad to read no 64-bit builds of gem on os x yet... think i will still use 0.42.5 with no problems for me :) Can the 32-bit QuickTime API work at all in 64-bit mode ? It could explain some things... I remember that Apple designed some things as if 64-bit would never happen, and then when was the time to support 64-bit mode, they came up with a new QuickTime interface that is very much different and won't run on OSX-10.4. As a result, a different GEM component would have to be written to support the new QuickTime. Correct me if I'm wrong. No, two of them, one for the movie files, one for the cameras. I'm not saying that this is what prevents Gem from building at all... I'm not talking about that kind of problem. But to get a full 64-bit release, much of QuickTime support code has to be rewritten. AFAIK, Quicktime is dead at 32-bit, and there is a totally new API for 64-bit. Check gem-dev for more info, Chris Clepper has posted more about it. But since gmerlin, gstreamer and other backends work on Mac OS X and work in 64-bit, Gem could be build for 64-bit Mac OS X using those. Then that would lose the highly optimized backend stuff in Quicktime. .hc I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
--- On Sun, 7/10/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Sunday, July 10, 2011, 7:25 PM On Jul 9, 2011, at 8:07 PM, Jonathan Wilkes wrote: --- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Saturday, July 9, 2011, 10:38 PM On Jul 9, 2011, at 1:48 AM, Jonathan Wilkes wrote: --- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: [...] The problem with forks is if improvements don't migrate upstream. I think it's both a problem-with and a cause-of. Yup, that makes sense. Then we don't benefit from sharing the fixes. Making things migrate upstream takes time in itself. How does one figure out who has the responsibility to make sure things migrate upstream (for example: [initbang] and [closebang])? Mostly by someone deciding its important enough that they want to work on it themself, and then lots of testing and communication. Ok. So in patch id#2838176, what is Guenter's idea for a clean implementation of tooltips that you were referring to? I didn't find anything on the user or dev list. Hmm, I can't remember what Günter's proposal was, but I do have a vague idea of how to do it cleanly. I think it should be similar to the way its done in Max/MSP. Basically there is a standard function, something like nlet_info(), which returns the tooltip info. Where would one define the standard function? Pd would then check whether an object had that function when it loaded the binary, and if so register it in the tooltips. This brings up an issue I've been wondering about since learning a little more about the canvas editor: why does the pd gui send 'motion' messages to pd? Why not, for example, just have a tag for an inlet rectangle and bind Enter and Leave to it? Then you'd only be sending messages from the gui for the events you care about, instead of tons of motion messages that don't trigger anything. -Jonathan .hc Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-) Yes, I would hope that making changes to the core of the largest free software project in the history of computing is a wee bit more difficult than making changes to Pd. Actually, there are much bigger projects than Linux, things like Debian are quite a bit larger in scale. I read a white paper on total development cost of a linux distro and just remembered linux. I think the distro in the paper was Fedora 9, which was estimated to be almost an order of magnitude more expensive than the Linux kernel. -Jonathan .hc -Jonathan .hc -Jonathan And anything assigned to Miller and reviewed positively by IOhannes I'm going to defer any action on until Miller responds. .hc -Jonathan ___ 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. http://at.or.at/hans/ 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] Pd-extended 0.43 updates: lots of new editing features
Jonathan Wilkes jancs...@yahoo.com wrote: --- On Sun, 7/10/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Sunday, July 10, 2011, 7:25 PM On Jul 9, 2011, at 8:07 PM, Jonathan Wilkes wrote: --- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Saturday, July 9, 2011, 10:38 PM On Jul 9, 2011, at 1:48 AM, Jonathan Wilkes wrote: --- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: [...] The problem with forks is if improvements don't migrate upstream. I think it's both a problem-with and a cause-of. Yup, that makes sense. Then we don't benefit from sharing the fixes. Making things migrate upstream takes time in itself. How does one figure out who has the responsibility to make sure things migrate upstream (for example: [initbang] and [closebang])? Mostly by someone deciding its important enough that they want to work on it themself, and then lots of testing and communication. Ok. So in patch id#2838176, what is Guenter's idea for a clean implementation of tooltips that you were referring to? I didn't find anything on the user or dev list. Hmm, I can't remember what Günter's proposal was, but I do have a vague idea of how to do it cleanly. I think it should be similar to the way its done in Max/MSP. Basically there is a standard function, something like nlet_info(), which returns the tooltip info. Where would one define the standard function? Pd would then check whether an object had that function when it loaded the binary, and if so register it in the tooltips. This brings up an issue I've been wondering about since learning a little more about the canvas editor: why does the pd gui send 'motion' messages to pd? Why not, for example, just have a tag for an inlet rectangle and bind Enter and Leave to it? Then you'd only be sending messages from the gui for the events you care about, instead of tons of motion messages that don't trigger anything. I may be way off the mark here, if I recall correctly I think that info is used for dragging stuff and similar actions. -Jonathan .hc Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-) Yes, I would hope that making changes to the core of the largest free software project in the history of computing is a wee bit more difficult than making changes to Pd. Actually, there are much bigger projects than Linux, things like Debian are quite a bit larger in scale. I read a white paper on total development cost of a linux distro and just remembered linux. I think the distro in the paper was Fedora 9, which was estimated to be almost an order of magnitude more expensive than the Linux kernel. -Jonathan .hc -Jonathan .hc -Jonathan And anything assigned to Miller and reviewed positively by IOhannes I'm going to defer any action on until Miller responds. .hc -Jonathan ___ 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. http://at.or.at/hans/ The arc of history bends towards justice. - Dr. Martin Luther King, Jr. Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
On Jul 10, 2011, at 2:00 PM, Jonathan Wilkes wrote: --- On Sun, 7/10/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Sunday, July 10, 2011, 7:25 PM On Jul 9, 2011, at 8:07 PM, Jonathan Wilkes wrote: --- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Saturday, July 9, 2011, 10:38 PM On Jul 9, 2011, at 1:48 AM, Jonathan Wilkes wrote: --- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: [...] The problem with forks is if improvements don't migrate upstream. I think it's both a problem-with and a cause-of. Yup, that makes sense. Then we don't benefit from sharing the fixes. Making things migrate upstream takes time in itself. How does one figure out who has the responsibility to make sure things migrate upstream (for example: [initbang] and [closebang])? Mostly by someone deciding its important enough that they want to work on it themself, and then lots of testing and communication. Ok. So in patch id#2838176, what is Guenter's idea for a clean implementation of tooltips that you were referring to? I didn't find anything on the user or dev list. Hmm, I can't remember what Günter's proposal was, but I do have a vague idea of how to do it cleanly. I think it should be similar to the way its done in Max/MSP. Basically there is a standard function, something like nlet_info(), which returns the tooltip info. Where would one define the standard function? On page 32 of this document: http://peabody.sapp.org/class/dmp2/read/WritingMax_MSPExternals.pdf You can see the 'assist' message. The Max GUI sends the 'assist' message to an objectclass when you hover above an inlet or outlet, then its up to the objectclass to implement a function which copies the text into a provider buffer. Then the Max GUI displays that text. I guess we might as well just copy the interface of Max/MSP. It seems very Max/Pd-ish, and straightforward. Pd would then check whether an object had that function when it loaded the binary, and if so register it in the tooltips. This brings up an issue I've been wondering about since learning a little more about the canvas editor: why does the pd gui send 'motion' messages to pd? Why not, for example, just have a tag for an inlet rectangle and bind Enter and Leave to it? Then you'd only be sending messages from the gui for the events you care about, instead of tons of motion messages that don't trigger anything. I agree that the GUI should really handle the motion and guts of the interaction, and 'pd' should just handle the logical messages like object selected. The original design of Pd was to have as much of the logic in 'pd' itself, for better or worse. .hc -Jonathan .hc Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-) Yes, I would hope that making changes to the core of the largest free software project in the history of computing is a wee bit more difficult than making changes to Pd. Actually, there are much bigger projects than Linux, things like Debian are quite a bit larger in scale. I read a white paper on total development cost of a linux distro and just remembered linux. I think the distro in the paper was Fedora 9, which was estimated to be almost an order of magnitude more expensive than the Linux kernel. -Jonathan .hc -Jonathan .hc -Jonathan And anything assigned to Miller and reviewed positively by IOhannes I'm going to defer any action on until Miller responds. .hc -Jonathan ___ 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. http://at.or.at/hans/ The arc of history bends towards justice. - Dr. Martin Luther King, Jr. [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
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
--- On Mon, 7/11/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Monday, July 11, 2011, 4:24 AM On Jul 10, 2011, at 2:00 PM, Jonathan Wilkes wrote: [...] Where would one define the standard function? On page 32 of this document: http://peabody.sapp.org/class/dmp2/read/WritingMax_MSPExternals.pdf You can see the 'assist' message. If I'm understanding this correctly, addmess is analogous to class_addmethod (I guess if we made it standard, we could do class_addtooltip or something). But then this would break [list], for example, or any object that currently has an anything method defined. Or am I misunderstanding the model? I mean, what happens in Max if the user happens to send the message assist to an inlet? -Jonathan The Max GUI sends the 'assist' message to an objectclass when you hover above an inlet or outlet, then its up to the objectclass to implement a function which copies the text into a provider buffer. Then the Max GUI displays that text. I guess we might as well just copy the interface of Max/MSP. It seems very Max/Pd-ish, and straightforward. Pd would then check whether an object had that function when it loaded the binary, and if so register it in the tooltips. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
On Jul 11, 2011, at 12:01 AM, Jonathan Wilkes wrote: --- On Mon, 7/11/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Monday, July 11, 2011, 4:24 AM On Jul 10, 2011, at 2:00 PM, Jonathan Wilkes wrote: [...] Where would one define the standard function? On page 32 of this document: http://peabody.sapp.org/class/dmp2/read/WritingMax_MSPExternals.pdf You can see the 'assist' message. If I'm understanding this correctly, addmess is analogous to class_addmethod (I guess if we made it standard, we could do class_addtooltip or something). But then this would break [list], for example, or any object that currently has an anything method defined. Or am I misunderstanding the model? Yes, addmess() is class_addmethod(). No need for a special function, class_addmethod() would do it. I mean, what happens in Max if the user happens to send the message assist to an inlet? Yeah, that would claim the message 'assist' in all objects. I just did a quick survey of all objects in the pure-data SVN. None of them use 'assist'. .hc -Jonathan The Max GUI sends the 'assist' message to an objectclass when you hover above an inlet or outlet, then its up to the objectclass to implement a function which copies the text into a provider buffer. Then the Max GUI displays that text. I guess we might as well just copy the interface of Max/MSP. It seems very Max/Pd-ish, and straightforward. Pd would then check whether an object had that function when it loaded the binary, and if so register it in the tooltips. I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. --Bjarne Stroustrup (creator of C++) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
On Jul 10, 2011, at 11:28 PM, Jonathan Wilkes wrote: --- On Mon, 7/11/11, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com, Hans-Christoph Steiner h...@at.or.at Cc: pd-list@iem.at Date: Monday, July 11, 2011, 2:56 AM Jonathan Wilkes jancs...@yahoo.com wrote: --- On Sun, 7/10/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Sunday, July 10, 2011, 7:25 PM On Jul 9, 2011, at 8:07 PM, Jonathan Wilkes wrote: --- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Saturday, July 9, 2011, 10:38 PM On Jul 9, 2011, at 1:48 AM, Jonathan Wilkes wrote: --- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: [...] The problem with forks is if improvements don't migrate upstream. I think it's both a problem-with and a cause-of. Yup, that makes sense. Then we don't benefit from sharing the fixes. Making things migrate upstream takes time in itself. How does one figure out who has the responsibility to make sure things migrate upstream (for example: [initbang] and [closebang])? Mostly by someone deciding its important enough that they want to work on it themself, and then lots of testing and communication. Ok. So in patch id#2838176, what is Guenter's idea for a clean implementation of tooltips that you were referring to? I didn't find anything on the user or dev list. Hmm, I can't remember what Günter's proposal was, but I do have a vague idea of how to do it cleanly. I think it should be similar to the way its done in Max/MSP. Basically there is a standard function, something like nlet_info(), which returns the tooltip info. Where would one define the standard function? Pd would then check whether an object had that function when it loaded the binary, and if so register it in the tooltips. This brings up an issue I've been wondering about since learning a little more about the canvas editor: why does the pd gui send 'motion' messages to pd? Why not, for example, just have a tag for an inlet rectangle and bind Enter and Leave to it? Then you'd only be sending messages from the gui for the events you care about, instead of tons of motion messages that don't trigger anything. I may be way off the mark here, if I recall correctly I think that info is used for dragging stuff and similar actions. Yes, it is, but I was just thinking that extending a wire from an outlet, which sends a message to pd every mouse motion and walks through the objects in the glist to see if it hit a box, could be simplified if you just handled it on the gui end. Then only send a message if the wire connection is successful, or if there is a disconnection. But I guess you'd still have to send a message every pixel you drag an object in editmode anyway. For connections/cords, you've illustrated it well. Pd only tracks whether they are connected or not, so it doesn't need to know the position, especially during creation. For moving boxes, Pd would mostly not need to know about the location, GUI objects would, but that would be within the GUI object. The one thing I can think of where Pd needs to know the location is with inlets and outlets, since the position could change the program. Changing the connection logic to be entirely in the GUI would be a good place to start on this. I think pd-gui would just need to communicate using the 'connect' message, then the disconnect, and which cord is under the magic glass. .hc -Jonathan .hc Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-) Yes, I would hope that making changes to the core of the largest free software project in the history of computing is a wee bit more difficult than making changes to Pd. Actually, there are much bigger projects than Linux, things like Debian are quite a bit larger in scale. I read a white paper on total development cost of a linux distro and just remembered linux. I think the distro in the paper was Fedora 9, which was estimated to be almost an order of magnitude more expensive than the Linux kernel. -Jonathan .hc -Jonathan .hc -Jonathan And anything assigned to Miller and reviewed positively by IOhannes I'm going to defer any action on until Miller responds. .hc -Jonathan ___ Pd-list@iem.at
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
I just tried today's Pd-extended 0.43.1 on chaos.medien.uni-weimar.de and it worked fine for me. Are others not able to get it to work on 10.6? .hc On Jul 7, 2011, at 6:18 PM, Max wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 todays 0.43 os x didn't even launch for me. Am 08.07.2011 um 00:07 schrieb João Pais: I tried today 0.43, and it didn't work properly. the audio was just noisy, and probably out of rate, as changing the value of the intensity in the test patch made a ramp of a few seconds, instead of ~50ms. And, when the ramp was up, instead of a sinus tone only noise came out. As I was trying that while working in a project, I couldn't spend more time with it. this was on xp, normal soundcard (with + without asio on) João http://autobuild.puredata.info/auto-build/latest/ I recently did a push to fix key bugs to get the Pd-extended 0.43 nightly builds in a useable state. Also, there is a new .zip download for Windows, so it should be really easy to try nightly builds on Windows. Just download the .zip, unzip, and double- click pd.exe in the bin folder. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk4WMMsACgkQ3EB7kzgMM6L1MQCffidIG+SpPBBwA0hIz3H4MYMT 2bAAniCwumLJ+80yHP6E8QUP1iKuUpo0 =2hXD -END PGP SIGNATURE- 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] Pd-extended 0.43 updates: lots of new editing features
On Jul 9, 2011, at 1:48 AM, Jonathan Wilkes wrote: --- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: [...] The problem with forks is if improvements don't migrate upstream. I think it's both a problem-with and a cause-of. Yup, that makes sense. Then we don't benefit from sharing the fixes. Making things migrate upstream takes time in itself. How does one figure out who has the responsibility to make sure things migrate upstream (for example: [initbang] and [closebang])? Mostly by someone deciding its important enough that they want to work on it themself, and then lots of testing and communication. Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-) Yes, I would hope that making changes to the core of the largest free software project in the history of computing is a wee bit more difficult than making changes to Pd. Actually, there are much bigger projects than Linux, things like Debian are quite a bit larger in scale. .hc -Jonathan .hc -Jonathan And anything assigned to Miller and reviewed positively by IOhannes I'm going to defer any action on until Miller responds. .hc -Jonathan ___ 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. http://at.or.at/hans/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
--- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Saturday, July 9, 2011, 10:38 PM On Jul 9, 2011, at 1:48 AM, Jonathan Wilkes wrote: --- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: [...] The problem with forks is if improvements don't migrate upstream. I think it's both a problem-with and a cause-of. Yup, that makes sense. Then we don't benefit from sharing the fixes. Making things migrate upstream takes time in itself. How does one figure out who has the responsibility to make sure things migrate upstream (for example: [initbang] and [closebang])? Mostly by someone deciding its important enough that they want to work on it themself, and then lots of testing and communication. Ok. So in patch id#2838176, what is Guenter's idea for a clean implementation of tooltips that you were referring to? I didn't find anything on the user or dev list. Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-) Yes, I would hope that making changes to the core of the largest free software project in the history of computing is a wee bit more difficult than making changes to Pd. Actually, there are much bigger projects than Linux, things like Debian are quite a bit larger in scale. I read a white paper on total development cost of a linux distro and just remembered linux. I think the distro in the paper was Fedora 9, which was estimated to be almost an order of magnitude more expensive than the Linux kernel. -Jonathan .hc -Jonathan .hc -Jonathan And anything assigned to Miller and reviewed positively by IOhannes I'm going to defer any action on until Miller responds. .hc -Jonathan ___ 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. http://at.or.at/hans/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
On Jul 7, 2011, at 5:14 PM, Jonathan Wilkes wrote: --- On Thu, 7/7/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com, Ivica Ico Bukvic i...@vt.edu Cc: pd-list@iem.at Date: Thursday, July 7, 2011, 9:20 PM On Thu, 07 Jul 2011 10:06 -0700, Jonathan Wilkes jancs...@yahoo.com wrote: --- On Thu, 7/7/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Ivica Ico Bukvic i...@vt.edu Cc: pd-list@iem.at Date: Thursday, July 7, 2011, 5:33 PM On Thu, 07 Jul 2011 16:39 +0200, Ivica Ico Bukvic i...@vt.edu wrote: I ended up refactoring the magic glass and highlighting code quite a bit, I think there might be something worth checking out. As for other bug fixes, it would be great to have them in the patch tracker so we can sort them out. It would take me a massive amount of time to figure out what code changes are for what in pdl2ork since there isn't any version control (that I could find at least) and it seems to be a mix of 0.42 and 0.43 versions. It's based off of 0.42.6 extended tree. As for submitting patches, I've been doing this in the past. Alas, a good number of them never got any attention which is not very encouraging. If you look at the patch tracker, and filter on Closed ones, you'll see which ones get accepted. Most do. It takes a lot of time to review patches, so if they don't cleanly apply and build, then I'm not really likely to pursue it much further. I've tried figuring out patches like that in the past, and it just takes too much time to try to figure out what's wrong, etc. and it doesn't speak well of the patch if it doesn't past the first hurdle. .hc bugfix 3127123 Closed http://sourceforge.net/tracker/?func=detailaid=3127123group_id=55736atid=478072 Accepted with comments. Am I missing something? bugfix 3110267 Open, no comments, no assignees patch 3077431 Open, comments, I emailed the cyclone author to ask if he's ok with Ico's improvements... No word from the upstream author of cyclone, he's not active anymore. The focus of the cyclone library is to be clones of Max/MSP objects. The Max/MSP stuff is proprietary, so we can only guess at how the code is actually written. So to get a clone of a Max object one needs to a) read the Max docs, and b) compare results from using [foo] in Max to using [foo] in Pd. Ico seems to be saying that Max's [coll] isn't causing audio dropouts, and Pd's is, and that his patch fixes this. AFAICT his implementation still adheres to the interface for [coll] listed in the Max docs, so I don't see how this isn't a better clone of Max's [coll] behavior. I'm not in a place to test that stuff, so I'm not likely to handle patches for cyclone. I don't really have a criteria to judge if its correct, unless its a really simple bugfix. But if Mr. Czaja says, Sure, go ahead, you won't have a problem with this patch, right? That is correct. bugfix 3109768 Open, and I added a new comment (Note: the comment I added is fixed in Pd-l2ork) donno, haven't reviewed bugfix 3108513 Open, no comments patch out of date, applies to 0.42 but not 0.43 * bugfix 3106837 Open, comments commented: Looks worth including, but with GOP bugs, I'm currently waiting to see what Miller is going to do with GOP restructuring before tackling this stuff. I still don't really have a grasp of the GOP code, so I don't know what the repercussions of GOP-related patches are. From my experience, one little simple fix causes some weird behavior elsewhere. bugfix 3106799 Open, comments, bug still exists (Note: fixed in Pd-l2ork) bugfix 3102512 Open, comments patch 1670440 Closed, accepted If any of these didn't apply cleanly and didn't build, there's no comment indicating so. I haven't necessarily had time to review everything, nagging and poking me is perfectly appropriate if you think I should review something. Ok, but it's not really a solution, because the time I have to nag and poke is probably about the same amount that you have to review stuff. That's just one option. You could also maintain your own fork/branch and accept these patches yourself. That's another option that seems to be working for Ico. I fix things that affect my work because I see them. I try to do as much as I can otherwise, but like you say, time is limited. The problem with forks is if improvements don't migrate upstream. Then we don't benefit from sharing the fixes. Making things migrate upstream takes time in itself. Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-) .hc -Jonathan And anything assigned to Miller and reviewed positively by IOhannes I'm going to defer any action
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
--- On Sat, 7/9/11, Hans-Christoph Steiner h...@at.or.at wrote: [...] The problem with forks is if improvements don't migrate upstream. I think it's both a problem-with and a cause-of. Then we don't benefit from sharing the fixes. Making things migrate upstream takes time in itself. How does one figure out who has the responsibility to make sure things migrate upstream (for example: [initbang] and [closebang])? Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-) Yes, I would hope that making changes to the core of the largest free software project in the history of computing is a wee bit more difficult than making changes to Pd. -Jonathan .hc -Jonathan And anything assigned to Miller and reviewed positively by IOhannes I'm going to defer any action on until Miller responds. .hc -Jonathan ___ 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] Pd-extended 0.43 updates: lots of new editing features
I ended up refactoring the magic glass and highlighting code quite a bit, I think there might be something worth checking out. As for other bug fixes, it would be great to have them in the patch tracker so we can sort them out. It would take me a massive amount of time to figure out what code changes are for what in pdl2ork since there isn't any version control (that I could find at least) and it seems to be a mix of 0.42 and 0.43 versions. It's based off of 0.42.6 extended tree. As for submitting patches, I've been doing this in the past. Alas, a good number of them never got any attention which is not very encouraging. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
On Thu, 07 Jul 2011 16:39 +0200, Ivica Ico Bukvic i...@vt.edu wrote: I ended up refactoring the magic glass and highlighting code quite a bit, I think there might be something worth checking out. As for other bug fixes, it would be great to have them in the patch tracker so we can sort them out. It would take me a massive amount of time to figure out what code changes are for what in pdl2ork since there isn't any version control (that I could find at least) and it seems to be a mix of 0.42 and 0.43 versions. It's based off of 0.42.6 extended tree. As for submitting patches, I've been doing this in the past. Alas, a good number of them never got any attention which is not very encouraging. If you look at the patch tracker, and filter on Closed ones, you'll see which ones get accepted. Most do. It takes a lot of time to review patches, so if they don't cleanly apply and build, then I'm not really likely to pursue it much further. I've tried figuring out patches like that in the past, and it just takes too much time to try to figure out what's wrong, etc. and it doesn't speak well of the patch if it doesn't past the first hurdle. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
--- On Thu, 7/7/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Ivica Ico Bukvic i...@vt.edu Cc: pd-list@iem.at Date: Thursday, July 7, 2011, 5:33 PM On Thu, 07 Jul 2011 16:39 +0200, Ivica Ico Bukvic i...@vt.edu wrote: I ended up refactoring the magic glass and highlighting code quite a bit, I think there might be something worth checking out. As for other bug fixes, it would be great to have them in the patch tracker so we can sort them out. It would take me a massive amount of time to figure out what code changes are for what in pdl2ork since there isn't any version control (that I could find at least) and it seems to be a mix of 0.42 and 0.43 versions. It's based off of 0.42.6 extended tree. As for submitting patches, I've been doing this in the past. Alas, a good number of them never got any attention which is not very encouraging. If you look at the patch tracker, and filter on Closed ones, you'll see which ones get accepted. Most do. It takes a lot of time to review patches, so if they don't cleanly apply and build, then I'm not really likely to pursue it much further. I've tried figuring out patches like that in the past, and it just takes too much time to try to figure out what's wrong, etc. and it doesn't speak well of the patch if it doesn't past the first hurdle. .hc bugfix 3127123 Closed bugfix 3110267 Open, no comments, no assignees bugfix 3109768 Open, and I added a new comment (Note: the comment I added is fixed in Pd-l2ork) bugfix 3108513 Open, no comments * bugfix 3106837 Open, comments bugfix 3106799 Open, comments, bug still exists (Note: fixed in Pd-l2ork) bugfix 3102512 Open, comments patch 3077431 Open, comments, I emailed the cyclone author to ask if he's ok with Ico's improvements... patch 1670440 Closed, accepted If any of these didn't apply cleanly and didn't build, there's no comment indicating so. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
While this may be so for a number of patches, my personal experience has been somewhat different with responses most of the time having nothing to do with the patch at hand (if I got any in the first place). I imagine if a patch is declined one would expect it being reported as such with an explanation as to what is the reason for such decision, and ideally with a response that actually makes sense so that an appropriate improvement can be made. Similarly, while I fully understand that reviewing patches can be quite time consuming, please do not forget that fixing a bug and creating a report in the patch tracker together with supporting documentation can be doubly so. Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Hans-Christoph Steiner h...@at.or.at wrote: On Thu, 07 Jul 2011 16:39 +0200, Ivica Ico Bukvic i...@vt.edu wrote: I ended up refactoring the magic glass and highlighting code quite a bit, I think there might be something worth checking out. As for other bug fixes, it would be great to have them in the patch tracker so we can sort them out. It would take me a massive amount of time to figure out what code changes are for what in pdl2ork since there isn't any version control (that I could find at least) and it seems to be a mix of 0.42 and 0.43 versions. It's based off of 0.42.6 extended tree. As for submitting patches, I've been doing this in the past. Alas, a good number of them never got any attention which is not very encouraging. If you look at the patch tracker, and filter on Closed ones, you'll see which ones get accepted. Most do. It takes a lot of time to review patches, so if they don't cleanly apply and build, then I'm not really likely to pursue it much further. I've tried figuring out patches like that in the past, and it just takes too much time to try to figure out what's wrong, etc. and it doesn't speak well of the patch if it doesn't past the first hurdle. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
Now that's you have your own fork going, I think the whole process should be a lot easier. Running Pd-extended made the patch process much easier for me. Having an active fork means that you can develop new fixes and features, then test and use them, and go back and fix them. Then once a bug fix and/or feature is really nailed down and well tested, then that's the time to submit it to the patch tracker. Unless its a simple, critical bugfix, I rarely submit patches from Pd-extended before they've been included in a test release and therefore tested by a bunch of people. Yes, submitting good patches definitely takes a lot of time, but it saves everyone time in the long run. I've submitted one quarter of the patches in the tracker, so I think I've got a pretty good idea of how much time it takes to submit patches ;-) .hc On Thu, 07 Jul 2011 20:45 +0200, Ivica Ico Bukvic i...@vt.edu wrote: While this may be so for a number of patches, my personal experience has been somewhat different with responses most of the time having nothing to do with the patch at hand (if I got any in the first place). I imagine if a patch is declined one would expect it being reported as such with an explanation as to what is the reason for such decision, and ideally with a response that actually makes sense so that an appropriate improvement can be made. Similarly, while I fully understand that reviewing patches can be quite time consuming, please do not forget that fixing a bug and creating a report in the patch tracker together with supporting documentation can be doubly so. Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Hans-Christoph Steiner h...@at.or.at wrote: On Thu, 07 Jul 2011 16:39 +0200, Ivica Ico Bukvic i...@vt.edu wrote: I ended up refactoring the magic glass and highlighting code quite a bit, I think there might be something worth checking out. As for other bug fixes, it would be great to have them in the patch tracker so we can sort them out. It would take me a massive amount of time to figure out what code changes are for what in pdl2ork since there isn't any version control (that I could find at least) and it seems to be a mix of 0.42 and 0.43 versions. It's based off of 0.42.6 extended tree. As for submitting patches, I've been doing this in the past. Alas, a good number of them never got any attention which is not very encouraging. If you look at the patch tracker, and filter on Closed ones, you'll see which ones get accepted. Most do. It takes a lot of time to review patches, so if they don't cleanly apply and build, then I'm not really likely to pursue it much further. I've tried figuring out patches like that in the past, and it just takes too much time to try to figure out what's wrong, etc. and it doesn't speak well of the patch if it doesn't past the first hurdle. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
On Thu, 07 Jul 2011 10:06 -0700, Jonathan Wilkes jancs...@yahoo.com wrote: --- On Thu, 7/7/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Ivica Ico Bukvic i...@vt.edu Cc: pd-list@iem.at Date: Thursday, July 7, 2011, 5:33 PM On Thu, 07 Jul 2011 16:39 +0200, Ivica Ico Bukvic i...@vt.edu wrote: I ended up refactoring the magic glass and highlighting code quite a bit, I think there might be something worth checking out. As for other bug fixes, it would be great to have them in the patch tracker so we can sort them out. It would take me a massive amount of time to figure out what code changes are for what in pdl2ork since there isn't any version control (that I could find at least) and it seems to be a mix of 0.42 and 0.43 versions. It's based off of 0.42.6 extended tree. As for submitting patches, I've been doing this in the past. Alas, a good number of them never got any attention which is not very encouraging. If you look at the patch tracker, and filter on Closed ones, you'll see which ones get accepted. Most do. It takes a lot of time to review patches, so if they don't cleanly apply and build, then I'm not really likely to pursue it much further. I've tried figuring out patches like that in the past, and it just takes too much time to try to figure out what's wrong, etc. and it doesn't speak well of the patch if it doesn't past the first hurdle. .hc bugfix 3127123 Closed http://sourceforge.net/tracker/?func=detailaid=3127123group_id=55736atid=478072 Accepted with comments. Am I missing something? bugfix 3110267 Open, no comments, no assignees patch 3077431 Open, comments, I emailed the cyclone author to ask if he's ok with Ico's improvements... No word from the upstream author of cyclone, he's not active anymore. The focus of the cyclone library is to be clones of Max/MSP objects. I'm not in a place to test that stuff, so I'm not likely to handle patches for cyclone. I don't really have a criteria to judge if its correct, unless its a really simple bugfix. bugfix 3109768 Open, and I added a new comment (Note: the comment I added is fixed in Pd-l2ork) donno, haven't reviewed bugfix 3108513 Open, no comments patch out of date, applies to 0.42 but not 0.43 * bugfix 3106837 Open, comments commented: Looks worth including, but with GOP bugs, I'm currently waiting to see what Miller is going to do with GOP restructuring before tackling this stuff. I still don't really have a grasp of the GOP code, so I don't know what the repercussions of GOP-related patches are. From my experience, one little simple fix causes some weird behavior elsewhere. bugfix 3106799 Open, comments, bug still exists (Note: fixed in Pd-l2ork) bugfix 3102512 Open, comments patch 1670440 Closed, accepted If any of these didn't apply cleanly and didn't build, there's no comment indicating so. I haven't necessarily had time to review everything, nagging and poking me is perfectly appropriate if you think I should review something. And anything assigned to Miller and reviewed positively by IOhannes I'm going to defer any action on until Miller responds. .hc -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
--- On Thu, 7/7/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Jonathan Wilkes jancs...@yahoo.com, Ivica Ico Bukvic i...@vt.edu Cc: pd-list@iem.at Date: Thursday, July 7, 2011, 9:20 PM On Thu, 07 Jul 2011 10:06 -0700, Jonathan Wilkes jancs...@yahoo.com wrote: --- On Thu, 7/7/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: Ivica Ico Bukvic i...@vt.edu Cc: pd-list@iem.at Date: Thursday, July 7, 2011, 5:33 PM On Thu, 07 Jul 2011 16:39 +0200, Ivica Ico Bukvic i...@vt.edu wrote: I ended up refactoring the magic glass and highlighting code quite a bit, I think there might be something worth checking out. As for other bug fixes, it would be great to have them in the patch tracker so we can sort them out. It would take me a massive amount of time to figure out what code changes are for what in pdl2ork since there isn't any version control (that I could find at least) and it seems to be a mix of 0.42 and 0.43 versions. It's based off of 0.42.6 extended tree. As for submitting patches, I've been doing this in the past. Alas, a good number of them never got any attention which is not very encouraging. If you look at the patch tracker, and filter on Closed ones, you'll see which ones get accepted. Most do. It takes a lot of time to review patches, so if they don't cleanly apply and build, then I'm not really likely to pursue it much further. I've tried figuring out patches like that in the past, and it just takes too much time to try to figure out what's wrong, etc. and it doesn't speak well of the patch if it doesn't past the first hurdle. .hc bugfix 3127123 Closed http://sourceforge.net/tracker/?func=detailaid=3127123group_id=55736atid=478072 Accepted with comments. Am I missing something? bugfix 3110267 Open, no comments, no assignees patch 3077431 Open, comments, I emailed the cyclone author to ask if he's ok with Ico's improvements... No word from the upstream author of cyclone, he's not active anymore. The focus of the cyclone library is to be clones of Max/MSP objects. The Max/MSP stuff is proprietary, so we can only guess at how the code is actually written. So to get a clone of a Max object one needs to a) read the Max docs, and b) compare results from using [foo] in Max to using [foo] in Pd. Ico seems to be saying that Max's [coll] isn't causing audio dropouts, and Pd's is, and that his patch fixes this. AFAICT his implementation still adheres to the interface for [coll] listed in the Max docs, so I don't see how this isn't a better clone of Max's [coll] behavior. I'm not in a place to test that stuff, so I'm not likely to handle patches for cyclone. I don't really have a criteria to judge if its correct, unless its a really simple bugfix. But if Mr. Czaja says, Sure, go ahead, you won't have a problem with this patch, right? bugfix 3109768 Open, and I added a new comment (Note: the comment I added is fixed in Pd-l2ork) donno, haven't reviewed bugfix 3108513 Open, no comments patch out of date, applies to 0.42 but not 0.43 * bugfix 3106837 Open, comments commented: Looks worth including, but with GOP bugs, I'm currently waiting to see what Miller is going to do with GOP restructuring before tackling this stuff. I still don't really have a grasp of the GOP code, so I don't know what the repercussions of GOP-related patches are. From my experience, one little simple fix causes some weird behavior elsewhere. bugfix 3106799 Open, comments, bug still exists (Note: fixed in Pd-l2ork) bugfix 3102512 Open, comments patch 1670440 Closed, accepted If any of these didn't apply cleanly and didn't build, there's no comment indicating so. I haven't necessarily had time to review everything, nagging and poking me is perfectly appropriate if you think I should review something. Ok, but it's not really a solution, because the time I have to nag and poke is probably about the same amount that you have to review stuff. -Jonathan And anything assigned to Miller and reviewed positively by IOhannes I'm going to defer any action on until Miller responds. .hc -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
I tried today 0.43, and it didn't work properly. the audio was just noisy, and probably out of rate, as changing the value of the intensity in the test patch made a ramp of a few seconds, instead of ~50ms. And, when the ramp was up, instead of a sinus tone only noise came out. As I was trying that while working in a project, I couldn't spend more time with it. this was on xp, normal soundcard (with + without asio on) João http://autobuild.puredata.info/auto-build/latest/ I recently did a push to fix key bugs to get the Pd-extended 0.43 nightly builds in a useable state. Also, there is a new .zip download for Windows, so it should be really easy to try nightly builds on Windows. Just download the .zip, unzip, and double-click pd.exe in the bin folder. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 todays 0.43 os x didn't even launch for me. Am 08.07.2011 um 00:07 schrieb João Pais: I tried today 0.43, and it didn't work properly. the audio was just noisy, and probably out of rate, as changing the value of the intensity in the test patch made a ramp of a few seconds, instead of ~50ms. And, when the ramp was up, instead of a sinus tone only noise came out. As I was trying that while working in a project, I couldn't spend more time with it. this was on xp, normal soundcard (with + without asio on) João http://autobuild.puredata.info/auto-build/latest/ I recently did a push to fix key bugs to get the Pd-extended 0.43 nightly builds in a useable state. Also, there is a new .zip download for Windows, so it should be really easy to try nightly builds on Windows. Just download the .zip, unzip, and double-click pd.exe in the bin folder. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk4WMMsACgkQ3EB7kzgMM6L1MQCffidIG+SpPBBwA0hIz3H4MYMT 2bAAniCwumLJ+80yHP6E8QUP1iKuUpo0 =2hXD -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
commented: Looks worth including, but with GOP bugs, I'm currently waiting to see what Miller is going to do with GOP restructuring before tackling this stuff. I still don't really have a grasp of the GOP code, so I don't know what the repercussions of GOP-related patches are. From my experience, one little simple fix causes some weird behavior elsewhere. I have no idea how Miller approaches reworking things. However, if I were the one doing it, I would prefer reworking a working rather than a buggy code. Wouldn't it make sense to stabilize existing code with patches like these until we know it works as-is and then clean it up and reimplement based on *working* code? AFAIK (as I mentioned before) pd-l2ork's implementation is as close to fully working gop as it gets. Apart from the GOP bug reported recently and for which I provided a fix that will be easy to re-implement, I am unable to reproduce any other buggy behavior I am aware of and that is apparent in pd vanilla/extended. Best wishes, Ico Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
Nice to hear about some progress in these important areas. BTW, did you merge vanilla MagicGlass and nlet highlighting or the one from the pd-l2ork? I ask this because vanilla implementations of both of those have a number of issues, including unnecessary cpu overhead and potential instabilities. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
Yes, magic glass and nlet highlighting came from l2ork, plus a 64-bit patch from Albert Gräf: https://sourceforge.net/tracker/?func=detailatid=478072aid=3312794group_id=55736 .hc On Jul 5, 2011, at 7:26 PM, i...@vt.edu wrote: Nice to hear about some progress in these important areas. BTW, did you merge vanilla MagicGlass and nlet highlighting or the one from the pd-l2ork? I ask this because vanilla implementations of both of those have a number of issues, including unnecessary cpu overhead and potential instabilities. Best wishes, Ico News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
Hans-Christoph Steiner h...@at.or.at wrote: Yes, magic glass and nlet highlighting came from l2ork, plus a 64-bit patch from Albert Gräf: https://sourceforge.net/tracker/?func=detailatid=478072aid=3312794group_id=55736 .hc Cool! You may want to check out the test of the l2ork c code as it has quite a number of other stability fixes and improvements including a definitive double-entry bug fix, better object resizing to accommodate nlets, proper reordering of nlets when moving nlet objects inside patches, a definitive fix for all known gop bugs, just to name a few. Cheers! On Jul 5, 2011, at 7:26 PM, i...@vt.edu wrote: Nice to hear about some progress in these important areas. BTW, did you merge vanilla MagicGlass and nlet highlighting or the one from the pd-l2ork? I ask this because vanilla implementations of both of those have a number of issues, including unnecessary cpu overhead and potential instabilities. Best wishes, Ico News is what people want to keep hidden and everything else is publicity. - Bill Moyers Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
Today I downloaded the version Pd-0.43.1-extended-macosx106-x86_64.dmg and installed it on OSX 10.6.8 I got a couple of errors, i write to the list to see if is mine or software problems ... - At pd opening, the pd main window doesnt appears, I have to make cmd + r to view it. - gem is not loading (I have not pix_video, pix_texture, gemhead, etc etc etc objects) the main window prints at startup: /Applications/Pd-0.43.1-extended-20110705.app/Contents/Resources/Scripts/../extra/Gem/Gem.pd_darwin: dlopen (/Applications/Pd-0.43.1-extended-20110705.app/Contents/Resources/Scripts/../extra/Gem/Gem.pd_darwin, 10): Symbol not found: __Z10initGemWinv Referenced from: /Applications/Pd-0.43.1-extended-20110705.app/Contents/Resources/Scripts/../extra/Gem/Gem.pd_darwin Expected in: dynamic lookup Gem: can not load library hope this can be helpful regards p.s. I take this opportunity to invite you to try SKT, we developed a software to create easily and intuitive multitouch surfaces using the Kinect camera. The data is sent via TUIO to play with the program you want. Download the source code at: http://code.google.com/p/simple-kinect-touch/ -- Ignacio Aguirre L. ludique.cl 2011/7/5 Hans-Christoph Steiner h...@at.or.at http://autobuild.puredata.info/auto-build/latest/ I recently did a push to fix key bugs to get the Pd-extended 0.43 nightly builds in a useable state. Also, there is a new .zip download for Windows, so it should be really easy to try nightly builds on Windows. Just download the .zip, unzip, and double-click pd.exe in the bin folder. new features: - enable/disable Autopatch mode from Edit menu or Ctrl/Cmd-Alt-A - fixed perf mode to not crash - enable/disable Perf Mode from Edit menu or Ctrl/Cmd-Alt-P (perf = performance, it basically makes it harder to mistakenly close windows, like during a performance) - inlet/outlet highlighting - Magic Glass cord inspector - 5 log levels that applies to the complete log history (try changing the log level, you'll see that it shows/hides content dynamically, without forgetting old log messages) - Ctrl/Cmd click on log lines in the Pd window to see which object printed that line (or select line and hit Enter/Return) - 'log' library for different levels of logging - backgrounded, high speed logging in the Pd window (you can have thousands of messages a second going to the Pd window, and still work on your patch). - updated French translation from Alexandre Castonguay - Alt menu shortcuts, i.e. Alt-F for File menu - basic config works on all platforms (i.e. no custom setup needed, libdir, vanilla/list, vanilla, etc. are loaded automatically) Don't forgot to try some of the awesome GUI plugins: http://puredata.info/community/projects/software/by-category/guiplugin https://puredata.info/docs/guiplugins .hc A cellphone to me is just an opportunity to be irritated wherever you are. - Linus Torvalds ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
On Jul 5, 2011, at 9:29 PM, Ivica Ico Bukvic wrote: Hans-Christoph Steiner h...@at.or.at wrote: Yes, magic glass and nlet highlighting came from l2ork, plus a 64-bit patch from Albert Gräf: https://sourceforge.net/tracker/?func=detailatid=478072aid=3312794group_id=55736 .hc Cool! You may want to check out the test of the l2ork c code as it has quite a number of other stability fixes and improvements including a definitive double-entry bug fix, better object resizing to accommodate nlets, proper reordering of nlets when moving nlet objects inside patches, a definitive fix for all known gop bugs, just to name a few. I ended up refactoring the magic glass and highlighting code quite a bit, I think there might be something worth checking out. As for other bug fixes, it would be great to have them in the patch tracker so we can sort them out. It would take me a massive amount of time to figure out what code changes are for what in pdl2ork since there isn't any version control (that I could find at least) and it seems to be a mix of 0.42 and 0.43 versions. .hc Cheers! On Jul 5, 2011, at 7:26 PM, i...@vt.edu wrote: Nice to hear about some progress in these important areas. BTW, did you merge vanilla MagicGlass and nlet highlighting or the one from the pd-l2ork? I ask this because vanilla implementations of both of those have a number of issues, including unnecessary cpu overhead and potential instabilities. Best wishes, Ico News is what people want to keep hidden and everything else is publicity. - Bill Moyers Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 updates: lots of new editing features
On Jul 5, 2011, at 10:15 PM, Ignacio Aguirre wrote: Today I downloaded the version Pd-0.43.1-extended-macosx106-x86_64.dmg and installed it on OSX 10.6.8 I got a couple of errors, i write to the list to see if is mine or software problems ... - At pd opening, the pd main window doesnt appears, I have to make cmd + r to view it. That's an odd one, could you send the contents of the debug log? In the Pd window, change the log level to 'debug', and copy and paste the contents. - gem is not loading (I have not pix_video, pix_texture, gemhead, etc etc etc objects) the main window prints at startup: /Applications/Pd-0.43.1-extended-20110705.app/Contents/Resources/ Scripts/../extra/Gem/Gem.pd_darwin: dlopen (/Applications/Pd-0.43.1-extended-20110705.app/Contents/ Resources/Scripts/../extra/Gem/Gem.pd_darwin, 10): Symbol not found: __Z10initGemWinv Referenced from: /Applications/Pd-0.43.1-extended-20110705.app/Contents/Resources/ Scripts/../extra/Gem/Gem.pd_darwin Expected in: dynamic lookup Gem: can not load library no 64-bit builds of Gem on Mac OS X yet, but it should be possible to get a gstreamer/gmerlin based 64-bit Gem Mac OS X build out without too much work, with IOhannes' new plugin backend. Or even better, someone could write Gem plugins for the Quicktime APIs that Apple did not port to 64-bit. .hc hope this can be helpful regards p.s. I take this opportunity to invite you to try SKT, we developed a software to create easily and intuitive multitouch surfaces using the Kinect camera. The data is sent via TUIO to play with the program you want. Download the source code at: http://code.google.com/p/simple-kinect-touch/ -- Ignacio Aguirre L. ludique.cl 2011/7/5 Hans-Christoph Steiner h...@at.or.at http://autobuild.puredata.info/auto-build/latest/ I recently did a push to fix key bugs to get the Pd-extended 0.43 nightly builds in a useable state. Also, there is a new .zip download for Windows, so it should be really easy to try nightly builds on Windows. Just download the .zip, unzip, and double-click pd.exe in the bin folder. new features: - enable/disable Autopatch mode from Edit menu or Ctrl/Cmd-Alt-A - fixed perf mode to not crash - enable/disable Perf Mode from Edit menu or Ctrl/Cmd-Alt-P (perf = performance, it basically makes it harder to mistakenly close windows, like during a performance) - inlet/outlet highlighting - Magic Glass cord inspector - 5 log levels that applies to the complete log history (try changing the log level, you'll see that it shows/hides content dynamically, without forgetting old log messages) - Ctrl/Cmd click on log lines in the Pd window to see which object printed that line (or select line and hit Enter/Return) - 'log' library for different levels of logging - backgrounded, high speed logging in the Pd window (you can have thousands of messages a second going to the Pd window, and still work on your patch). - updated French translation from Alexandre Castonguay - Alt menu shortcuts, i.e. Alt-F for File menu - basic config works on all platforms (i.e. no custom setup needed, libdir, vanilla/list, vanilla, etc. are loaded automatically) Don't forgot to try some of the awesome GUI plugins: http://puredata.info/community/projects/software/by-category/ guiplugin https://puredata.info/docs/guiplugins .hc 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 If you are not part of the solution, you are part of the problem. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
