Re: [PD-dev] [PD] Which one is the correct repository to submit patches for externals code? (Was: oggread~ not working on pd-extended or libpd on windows.)
That SVN is the right place, so in the sourceforge bug tracker. .hc On Apr 5, 2014, at 9:05 AM, Rafael Vega wrote: I found and fixed a bug in oggread~ that is windows specific. The fix is a one liner in oggread~.c (details in previous thread). I thought the central place for externals code was the SVN community repoat [1] but the comments below confuse me. Can someone please confirm which one is the correct place to submit a patch? Thanks! :) [1] http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/ On Fri, Apr 4, 2014 at 10:48 PM, Simon Wise simonzw...@gmail.com wrote: On 05/04/14 14:21, Martin Peach wrote: I think it's here: http://sourceforge.net/p/pure-data/patches/ that seems to be for pd rather than externals??? maybe a patch to debian package pd-pdogg, which could then get upstream, since for some (especially older) externals this may be the most actively maintained repo? I don't know about [oggread~] in particular though ... but is this problem/patch only a windows one? Simon ___ pd-l...@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Rafael Vega email.r...@gmail.com ___ pd-l...@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Compiling pd on OS X
The easy place to start is pd itself, probably, because its a small package. But the Mac build process might be non-public. The would process for building Pd-extended on Mac OS X is documented and scripted, but its a lot more complicated too. It relies on lots of external libs. They are all in Fink, so my guess they are mostly or maybe all in MacPorts. .hc On 03/09/2014 11:07 PM, Ryan Schmidt wrote: Hello, I’m a manager of the MacPorts package management system, trying to add pd to our collection of software. I’ve tried to do this several times over the past few years, never leading to success. Now I’m finally asking for help. First, it’s unclear where to get pd. I had previously recorded the project’s homepage as: http://pd.iem.at/ The download link there takes me to an FTP server: ftp://ftp.iem.at/pub/pd/ There, the latest available is pd-0.43-0.src.tar.gz. Following the building instructions for running autogen.sh, configure, make and make install (and first applying patches to several files to remove the undesired references to /sw), it succeeds, however trying to run the pd executable results in an error message that “5400” was not found. Not intuitive. There’s also a pre-compiled OS X application available for download, but it’s unclear how I might build that myself. Next, I found a different homepage for the project: http://puredata.info/ This refers me to SourceForge to download: https://sourceforge.net/projects/pure-data/files/pure-data/ where the latest version is pd-0.45-4.src.tar.gz. This version does not build. First, configure complains about missing SDKs: configure: error: Couldn't find 10.5, 10.6, or 10.7 SDK configure: error: ./configure failed for portaudio I am using Xcode 5, which only includes the 10.8 and 10.9 SDKs. This error occurs even if I use the configure argument --disable-portaudio. I already have portaudio 19.20140130 installed; if it’s required, I’d rather use that than have pd build a different version, but I don’t know how to inform pd of that. Overcoming this error by using the configure argument --disable-mac-universal, make fails with: src/hostapi/coreaudio/pa_mac_core.c:140:12: error: 'AudioDeviceGetPropertyInfo' is deprecated: first deprecated in OS X 10.6 [-Werror,-Wdeprecated-declarations] error = AudioDeviceGetPropertyInfo( hostApiDevice, ^ Overcoming this by removing -Werror from portaudio/configure.in, make fails with: Undefined symbols for architecture x86_64: _find_default_device, referenced from: _pm_init in libportmidi.a(pmmac.o) (maybe you meant: _pm_find_default_device) ld: symbol(s) not found for architecture x86_64 I see this was previously reported to this mailing list in August of last year, with no resolution: http://lists.puredata.info/pipermail/pd-dev/2013-08/019598.html So with all these problems I’m now once again at the point of being frustrated with this software and giving up. Can anybody explain to me how to build a usable pd on OS X? How was the available OS X app built? I just want to get pd finally included in MacPorts so I can get on with what I’m really trying to do, which is to add another software package that requires pd. Thanks. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Question about multi-arch Mac OS X - is 32-Bit still around?
At this point, the thing to do is probably raise money to pay someone to do it. .hc On Jan 12, 2014, at 1:42 PM, me.grimm wrote: admittedly this is an issue of Gem, but little can be done about it. except getting a working 64-bit version of Gem. I have it compiled on 64-bit w/ gmerlin for pix_film but native filmQTKIT would be better. there has been some work done on this for Max and oFX that might be useful code to port to Gem since last time i looked at this a couple years ago: see https://github.com/brianchasalow/jit.BC.QTKit http://www.openframeworks.cc/documentation/video/ofQTKitPlayer.html unfortunately I am not skilled or organized enough to implement myself but I would be happy to help!!! I would love to get my students using 64-bit pd builds on their macs (all 50 of them this semester have macs) m On Sun, Jan 12, 2014 at 12:33 PM, IOhannes m zmölnig zmoel...@iem.at wrote: On 2014-01-11 01:08, Thomas Mayer wrote: So: Is 32-Bit on Mac OS X still around? due to QuickTime issues, Gem on OSX is still 32bit only. this means that whoever wants to run Gem on OSX, will need to use a 32bit version of Pd and not being able to run a 64bit-only purest json. admittedly this is an issue of Gem, but little can be done about it. gfmdsar IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- m.e.grimm | m.f.a | ed.m. megr...@gmail.com _ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [pure-data:bugs] #1115 typo in translation template for +start-here.pd
--- ** [bugs:#1115] typo in translation template for +start-here.pd** **Status:** open **Created:** Fri Oct 04, 2013 01:19 PM UTC by Hans-Christoph Steiner **Last Updated:** Fri Oct 04, 2013 01:19 PM UTC **Owner:** nobody start-here.pd translation template has a typo in the English string. outle instead of outlet https://www.transifex.com/projects/p/puredata/viewstrings/#en/start-here/9210005 Before this can be corrected, all of the completed translations should be downloaded and included in the pure-data svn. This is to avoid the loss of the translations, since they key will change. The patch translations should be changed to use XLIFF format maybe to handle this better. --- Sent from sourceforge.net because pd-...@lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-extended exectuable - packaging for Debian
On 08/12/2013 08:59 PM, zmoel...@iem.at wrote: Quoting Kaj Ailomaa zeque...@mousike.me: I solve it by using a postinst script to rename the two files that shouldn't. this is most likely the wrong approach. postinst is running on the target system, so instead of renaming the file *once* during the build process, you will rename it thousands of times (on each installation). this also means that you double your chance of creating package collision and circumvent any security measures of the package manager (e.g. apt keeps track of the installed files - but it defers that information from the list of files in the .deb rather than checking which files have been installed after running postinst) Ideally, the pd-extended build system would name the executable properly, but it currently does the wrong thing. For the packaging, I think the best thing to do right now is to use a debian/install file to install the file as usr/bin/pd-extended. I think the line in debian/install would look like this: usr/bin/pd usr/bin/pd-extended As for basing the pd-extended package off of the 'puredata' package, I think that is not a good idea. The pd-extended package will generate a single package called pd-extended. The puredata package generates lots of sub packages which don't make sense for Pd-extended. Also, Pd-extended's build system (./configure, etc.) is not the same as pd-vanilla's. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
On 06/18/2013 10:35 PM, Jonathan Wilkes wrote: From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Miller Puckette m...@ucsd.edu; pd-dev@iem.at pd-dev@iem.at Sent: Tuesday, June 18, 2013 8:55 PM Subject: Re: [PD-dev] remove tk scaling On 06/18/2013 06:21 PM, Jonathan Wilkes wrote: From: Miller Puckette m...@ucsd.edu To: Hans-Christoph Steiner h...@at.or.at Cc: pd-dev@iem.at Sent: Tuesday, June 18, 2013 2:12 PM Subject: Re: [PD-dev] remove tk scaling [...] (the relevant doc is in the font manual age for TK; If size is a negative number, its absolute value is interpreted as a size in pixels. That's exactly what Pd does-- I should have said in my previous message I tested patches with 0.44-3 on Debian Wheezy, OSX, and Windows XP. All the iemgui and object fonts must be negative because they are pixel exact whether you use [tk scaling 0.2] or [tk scaling 8]. Furthermore, if someone codes a gui external that doesn't use pixel sizes for fonts to appear on the canvas _and_ they want pixel-exactness, it's a bug, no? -Jonathan The situation is a big mess, no argument here. No, it's not. As I said, patches are currently pixel-exact across platforms, and they remain that way regardless of the value supplied to [tk scaling]. But you're not going to fix it by messing with [tk scaling], you'll just fix one issue, and others will pop up. Can you give an example of one of those issues? So far you have a single comment about pixel-exactness which is at the very least no longer relevant. (While there is a bug related to the default tk scaling value, it's in a different domain and has evidently been solved with a one-liner, without introducing the font problems I mentioned.) -Jonathan What do you gain by removing in? I think we really need to stop wasting time on little details like this, and instead work towards real fixes. Does anyone object to the idea of truly separating the GUI from the core? I haven't heard them. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
On 06/18/2013 10:35 PM, Jonathan Wilkes wrote: From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Miller Puckette m...@ucsd.edu; pd-dev@iem.at pd-dev@iem.at Sent: Tuesday, June 18, 2013 8:55 PM Subject: Re: [PD-dev] remove tk scaling On 06/18/2013 06:21 PM, Jonathan Wilkes wrote: From: Miller Puckette m...@ucsd.edu To: Hans-Christoph Steiner h...@at.or.at Cc: pd-dev@iem.at Sent: Tuesday, June 18, 2013 2:12 PM Subject: Re: [PD-dev] remove tk scaling [...] (the relevant doc is in the font manual age for TK; If size is a negative number, its absolute value is interpreted as a size in pixels. That's exactly what Pd does-- I should have said in my previous message I tested patches with 0.44-3 on Debian Wheezy, OSX, and Windows XP. All the iemgui and object fonts must be negative because they are pixel exact whether you use [tk scaling 0.2] or [tk scaling 8]. Furthermore, if someone codes a gui external that doesn't use pixel sizes for fonts to appear on the canvas _and_ they want pixel-exactness, it's a bug, no? -Jonathan The situation is a big mess, no argument here. No, it's not. As I said, patches are currently pixel-exact across platforms, and they remain that way regardless of the value supplied to [tk scaling]. But you're not going to fix it by messing with [tk scaling], you'll just fix one issue, and others will pop up. Can you give an example of one of those issues? So far you have a single comment about pixel-exactness which is at the very least no longer relevant. (While there is a bug related to the default tk scaling value, it's in a different domain and has evidently been solved with a one-liner, without introducing the font problems I mentioned.) -Jonathan What do you gain by removing in? I think we really need to stop wasting time on little details like this, and instead work towards real fixes. Does anyone object to the idea of truly separating the GUI from the core? I haven't heard them. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
On 06/19/2013 04:38 PM, Miller Puckette wrote: [discussion of tk scaling deleted...] What do you gain by removing in? I think we really need to stop wasting time on little details like this, and instead work towards real fixes. Does anyone object to the idea of truly separating the GUI from the core? I haven't heard them. .hc I already gained something... I can read the Pd console output now :) You can also just change the console font size with the font panel for temporary changes, or set the console font size if you want it permanent. If that's not in Pd-vanilla, feel free to take it from Pd-extended. tk scaling is not the way to set font sizes. Setting the font size is the way to do that. Anyhow, if by separating the GUI from the core you mean re-writing the Pd patch editor in Tcl/TK, I think that would create enormous headaches. i enjoyed some of those with Max/FTS (in which the GUI layer was responsible for editing) and Pd's separation of duties is partly a reaction from that experience. But now there's even a stronger reason - since the GUI is now written in a scripting language it is likely to be very hard to get it to the level of robustness and performance needed in an editor. But perhaps you mean something else, such as putting an abstract layer between Pd 'proper' and the Tcl/TK code. That might be feasible although I think it would still be quite a pain. OTOH I recently talked with Peter Brinkmann about the idea of making an API for 'graphics updates' (changing float and table values) so that non-GUI-users could have an easier time seeing patch state. This seems a manageable first step... cheers Miller There are many python based GUIs that perform orders of magnitude better than Pd when it comes to screen drawing performance. Max/FTS was 20+ years ago, scripting languages have come a long way since then. The current situation guarantees crappy performance because it forces things to be implemented in a way that avoids graphics optimizations. In Pd's current architecture, things need to be handled incrementily and over a network socket. In any decent graphics programming environment, updates can be handled en masse. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] OSX tcl/tk version
On 06/18/2013 10:55 PM, Jonathan Wilkes wrote: From: Hans-Christoph Steiner h...@at.or.at To: pd-dev@iem.at Sent: Tuesday, June 18, 2013 1:58 PM Subject: Re: [PD-dev] OSX tcl/tk version Pd-extended on Mac OS X uses a built-in Tcl/Tk that's included inside the app. That is a 32-bit Carbon version, not Cocoa nor 64-bit. Pd's Tcl code has some issues running on Tk/Cocoa, it would be awesome if someone could try to fix them. I beleive they are in the bug tracker. I tried searching the bug tracker for cocoa, apple, osx, macos, carbon... didn't find what you're referring to. If you can steer me in the right direction I'd be happy to take a look. (I'm already looking at why Pd gives duplicated menu entries for Preferences so I might as well...) Hmm, can't find them either. Memory fails me... If you want to try with a stock Pd-extended 0.43.4, just remove the Tcl.framework and Tk.framework from inside of the app wrapper, and it should use the one included in /System/Library/Frameworks or /Library/Frameworks. Thanks. Btw-- does anyone know a way to screw around with the contents of an OSX *.app that _doesn't_ require giving root password every time I make a change? It's quite telling that the user can run an app dl'd from the net, but the idea that a user would ever change what an app does to suit their needs is so remote that you have to call the administrator in to sign off on it. Copy the app to your desktop, then your user should own all the files. .hc -Jonathan .hc On 06/10/2013 03:00 PM, Jonathan Wilkes wrote: Can't figure this one out: Version: Pd 0.43.4extended OS: Mac OSX Version 10.7.5 1) Querying the tcl version with the tcl prompt: pdtk_post [info patchlevel]\n 8.5.11 2) Query OSX's wish version in a terminal: % info patchlevel 8.5.9 3) building a ttk::notebook through Pd's tcl prompt: toplevel .t pack [ttk::notebook .t.n] .t.n add [ttk::frame .t.n.f1] -text hello .t.n add [ttk::frame .t.n.f2] -text world You get the old carbon notebook that doesn't look native 4) building a ttk::notebook through OSX terminal wish prompt: (same as above) You get a Tab View as shown in Apple's HIG: https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Controls/Controls.html#//apple_ref/doc/uid/TP3359-TPXREF227 Obviously I want the native Tab View, but Pd won't give it to me. Version 8.5.9 and greater are supposed to hook into Cocoa for drawing native widgets. I assume 8.5.11 is greater than 8.5.9, so why is Pd displaying old-style Carbon widgets, and how do I change that behavior? -Jonathan ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
In general, removing bits of code willy-nilly is a bad idea. In this case, it took a ton of testing to get the right set of tweaks working across all platforms smoothly with the same pixel sizes on all platforms. Given that you only tested on GNU/Linux, its a really bad idea to propose changes based only on one platform unless you are planning to drop support for all other platforms. So follow what the comment there says: This guarantees that patches will be pixel-exact on every platform. If we had a pure Tcl/Tk GUI, then we could actually use tk scaling, and allow the user to adjust the tk scaling number, thereby having a zoomable interface. That will require removing all GUI logic from the pd core and putting it only in the GUI. .hc On 06/12/2013 07:54 PM, Miller Puckette wrote: Hi Jonathan et a - I've never understood the reason tk_scaling is touched in the TK code and unless someone else objects I'll try taking it out of the vanilla source. thanks Miller On Tue, Jun 11, 2013 at 06:11:57PM -0700, Jonathan Wilkes wrote: Hi list, From tcl/pd-gui: # we are not using Tk scaling, so fix it to 1 on all platforms. This # guarantees that patches will be pixel-exact on every platform tk scaling 1 From #tcl on freenode: jancsika hello. does tk scaling affect canvas items? ijchain emiliano jancsika: no From my own experiments on Debian: * setting the tk scaling to 1, 0.2, 3, or 200 does not alter a canvas text item, either for positive (pointsize) font sizes or negative (pixelsize) font sizes * with version 8.5.11, setting tk scaling to 1, 0.2, 3, or 200 _will_ change the actual number of pixels a canvas requests from its parent _if_ you pack it without any option flags. (e.g., scaling at 0.2 will request a tiny rectangle and scaling at 200 will be bigger than the visible screen area, at least on my laptop). However, Pd packs its canvas items to fill the cavity provided by the toplevel parent (which always has its geometry set explicitly), so no matter what tk scaling value you set the canvas will be exactly the right size. You can check this by setting tk scaling to any value at all. The tk widgets will of course look different (that's what tk scaling affects, after all), but just click ctrl-n for a new patch and it will look exactly right. Also try: [label foo( | [vsl] ... and you will find that even iemguis have _exactly_ the same font size no matter what you provided for tk scaling. Effect of [tk scaling 1] command: causes tiny fonts in various widgets on Windows, which then requires a dev to fire up Pd on a Windows machine and screw around with the options database until they find the correct string to set the menufont Side effect: if you want to embed tk widgets in a patch, not having tk scaling frozen at 1 may end up making those widgets have different sizes on different platforms. But even with [tk scaling 1] you cannot guarantee pixel-exactness in this case, because tk uses native widgets from the OS, and different OSes will request different padding, font-sizes, images, etc. for those widgets. So-- is there any reason not to remove tk scaling 1? Thanks, Jonathan ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] Makefile error in library template v1.0.14
On 06/15/2013 04:27 AM, IOhannes m zmölnig wrote: (moving this over to pd-dev) On 06/15/13 09:21, Joel Matthys wrote: Hi Hans. The Makefile fails for Android on Linux 64 bit. I tracked it down to line 149: $(NDK_BASE)/toolchains/$(NDK_ABI)*-$(NDK_COMPILER_VERSION)/prebuilt/$(NDK_UNAME)-x86) should be: $(NDK_BASE)/toolchains/$(NDK_ABI)*-$(NDK_COMPILER_VERSION)/prebuilt/$(NDK_UNAME)-x86*) will this work if multiple toolchains are installed at the same time? (multiarch). fg,asdr IOhannes I think I fixed this here: https://sourceforge.net/p/pure-data/svn/17152/ Please try it and let me know if it doesn't work for you. .hc signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] OSX tcl/tk version
Pd-extended on Mac OS X uses a built-in Tcl/Tk that's included inside the app. That is a 32-bit Carbon version, not Cocoa nor 64-bit. Pd's Tcl code has some issues running on Tk/Cocoa, it would be awesome if someone could try to fix them. I beleive they are in the bug tracker. If you want to try with a stock Pd-extended 0.43.4, just remove the Tcl.framework and Tk.framework from inside of the app wrapper, and it should use the one included in /System/Library/Frameworks or /Library/Frameworks. .hc On 06/10/2013 03:00 PM, Jonathan Wilkes wrote: Can't figure this one out: Version: Pd 0.43.4extended OS: Mac OSX Version 10.7.5 1) Querying the tcl version with the tcl prompt: pdtk_post [info patchlevel]\n 8.5.11 2) Query OSX's wish version in a terminal: % info patchlevel 8.5.9 3) building a ttk::notebook through Pd's tcl prompt: toplevel .t pack [ttk::notebook .t.n] .t.n add [ttk::frame .t.n.f1] -text hello .t.n add [ttk::frame .t.n.f2] -text world You get the old carbon notebook that doesn't look native 4) building a ttk::notebook through OSX terminal wish prompt: (same as above) You get a Tab View as shown in Apple's HIG: https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Controls/Controls.html#//apple_ref/doc/uid/TP3359-TPXREF227 Obviously I want the native Tab View, but Pd won't give it to me. Version 8.5.9 and greater are supposed to hook into Cocoa for drawing native widgets. I assume 8.5.11 is greater than 8.5.9, so why is Pd displaying old-style Carbon widgets, and how do I change that behavior? -Jonathan ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
On 06/18/2013 06:21 PM, Jonathan Wilkes wrote: From: Miller Puckette m...@ucsd.edu To: Hans-Christoph Steiner h...@at.or.at Cc: pd-dev@iem.at Sent: Tuesday, June 18, 2013 2:12 PM Subject: Re: [PD-dev] remove tk scaling What I've never understood is this: why wouldn't it suffice to 'unscale' just the fonts Pd uses explicitly? One can get an unscaled font by asking for a size like -12 - then we wouldn't have to bash tk_scalaing globally (thereby ruining font sizes in open dialogs and whatnot that Pd doesn't depend on anyhow.) (the relevant doc is in the font manual age for TK; If size is a negative number, its absolute value is interpreted as a size in pixels. That's exactly what Pd does-- I should have said in my previous message I tested patches with 0.44-3 on Debian Wheezy, OSX, and Windows XP. All the iemgui and object fonts must be negative because they are pixel exact whether you use [tk scaling 0.2] or [tk scaling 8]. Furthermore, if someone codes a gui external that doesn't use pixel sizes for fonts to appear on the canvas _and_ they want pixel-exactness, it's a bug, no? -Jonathan The situation is a big mess, no argument here. But you're not going to fix it by messing with [tk scaling], you'll just fix one issue, and others will pop up. I just see no reason to mess with that stuff until there is real change to the core, and the gui is completely separate from the core. Then we can actually do useful things, like a zoomable patch GUI. Indeed, you're free to do whatever in vanilla, but in Pd-extended, I'll not include any such changes. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] vanilla and extended on OSX
If you build against Pd-extended, there might be some incompatibilities with vanilla. But if you build against vanilla, it should work fine in both. .hc On 05/17/2013 05:04 AM, Orm Finnendahl wrote: Hi devs, I run into a very strange problem with a binary external compiled for osx. It seems the binary works fine on pd-extended 0.44-3 but not on vanilla 0.44-3 (that has been tested on OSX 10.7 and up on different machines). The external's same binary has been running without any problems on extended and vanbilla since OSX 10.4. The external uses statically linked gnu-libraries and considering the errors in the pd window it seems the problem has something to do with them. Does anybody know the differences between vanilla and extended on OSX? I realized that extended seems to use X11 while vanilla doesn't need it, then I read something about full utf-8 support (this could have some effect as the external dynamically creates and reads in patches) and maybe there are different compiler settings. Maybe that gets me somewhere... -- Orm ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] What the Pd GUI would look like with the ttk:combobox widget
Looks a lot better :) About the font issue on Windows, there is a special Tk font for any menu called '::menufont'. If you use that, it should solve the tiny menu fonts on Windows. While you're at it, want to try running the whole Pd GUI with ttk? .hc On 05/21/2013 04:01 PM, Fred Jan Kraan wrote: Hi List, Recently I created an Audio Settings dialog with the modern ttk:combobox replacing the menu popup construct. It is not perfect yet, but nice to look at: http://fjkraan.home.xs4all.nl/digaud/puredata/combobox/index.html Fred Jan Kraan ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Mac Os now requiring Apple signatures on all SW !?
I wouldn't stop anyone from putting Pd into the Apple App Store, but I'm not going to contribute to the effort. It is indeed this ridiculous path that Apple is taking with Mac OS X that has made me abandon Mac OS X. I now use Linux Mint 95% of the time. .hc On 05/17/2013 08:11 PM, Rich E wrote: I think putting a 'validated' pd in the app store is a great idea, for both pd-vanilla and pd-extended. Just alot of work. I believe, but am not certain, that dlopen will continue to work as long as you play the 'app sandbox' game: if a user wants to load binaries from a different location in a sandboxed app, they need to give permission. Here are the juicy details: http://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW5 of importance in there is 'Securty-Scoped Bookmarks'. Note this isn't just Mac, you have to jump through the same hoops for WinRT, which hasn't really caught on yet, but its a sign that the trend nowadays is for a rediculously high level of securty, by default. On Fri, May 10, 2013 at 7:21 PM, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Miller Puckette m...@ucsd.edu To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev@iem.at pd-dev@iem.at Sent: Friday, May 10, 2013 7:12 PM Subject: Re: [PD-dev] Mac Os now requiring Apple signatures on all SW !? T hat sounds sensible... sounds like I can probably do nothing for now (but I'm worried they're going to progressively lock things down harder in the future... this isn't going in a good direction!) Well, if they decide to remove the easy workaround that would be a big enough change that we'll likely hear news from FSF and others. -Jonathan M Again, that adds credibility to a system that adds little more than a pain for users, and it distracts everyone other than bureaucrats. Most users just want to download and run your software. If a school sysadmin wants to misunderstand security and force instructors to go through the hoops, then the school or, at worst, the instructor should pay you to jump through the hoops and get a signing key. The end user shouldn't even be aware of any of this, other than maybe seeing a link to the _trivial_ workaround katja mentioned next to the version you currently have available. -Jonathan ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd-ext Submitting new relase
On 05/19/2013 06:26 AM, IOhannes zmölnig wrote: On 05/17/2013 09:02 PM, João Pais wrote: I think I did it, https://puredata.info/downloads/jmmmp-1/releases/0.2 for some reason I can't add new stuff to http://puredata.info/downloads/jmmmp, so when I tried to make a new project, it created the folder jmmmp-1. any objections if i change that back to /jmmmp/ before the link spreads? Please do! If anyone can't edit, please post and we'll fix it. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd-ext Submitting new relase
Adding your library to the Pd-extended branch should be the last step of your release cycle. The first step is to post a beta build to the downloads page for you library, and announce the changes there. You can easily make the tarball for the release by running make dist. In order for the official Debian package to be updated, you need to post your final, release tarball up on your downloads page: http://puredata.info/downloads/jmmmp http://puredata.info/docs/AddingYourProjectToDownloads Once you are happy with a stable release of jmmmp, then its ready to include in the Pd-extended release branch. This is probably the most up-to-date instructions for the final step of adding your library to the Pd-extended 0.44 branch. http://puredata.info/docs/developer/GettingIntoPdextended/ .hc On 05/13/2013 01:42 AM, João Pais wrote: Hello, I wanted to submit a new release of the jmmmp library. I've uploaded the files to svn, but I guess I need to say somewhere which files are to be included in the next release. Is the link at http://puredata.info/docs/developer/MergingHowto still up to date? If not, is the correct link at http://puredata.info/docs/developer ? Best, jmmmp ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd-ext Submitting new relase
I have little time to work on it in the near future, so I say its going to be a while. Unless someone else steps up and makes the release. I'd like to try to do more frequent releases as well. As for putting out a new pmpd, if you just post the new version, any user can just drop it into the user-installed folder (~/pd-externals, ~/Library/Pd, etc) and Pd-extended will use that version over the built-in one. .hc On 05/15/2013 11:53 AM, Nicolas Montgermont wrote: Hello hans, Do you have more or less an idea of the time limit for the libraries to be included in pd-ext 0.44? I'd like to take care of the inclusion of pmpd in the next release. thanks, n Le 15/05/13 16:37, Hans-Christoph Steiner a écrit : Once you are happy with a stable release of jmmmp, then its ready to include in the Pd-extended release branch. This is probably the most up-to-date instructions for the final step of adding your library to the Pd-extended 0.44 branch. http://puredata.info/docs/developer/GettingIntoPdextended/ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Getting path of external
I think you want c_externdir, i.e.
rest_class-c_externdir-s_name,
That's the directory that the external was loaded from. You'll need to
#include m_imp.h. See externals/hcs/cursor.c for an example.
.hc
On 04/17/2013 03:58 PM, Thomas Mayer wrote:
Hi,
for PuREST JSON on Windows, I need a way to verify SSL signatures,
because currently this is not working. One way to accomplish that, is
setting the path to the certificate file. As I want to package the file
with the zip, I would like to store it in the same directory as the dll
for the externals.
I have two externals [rest] and [oauth] that share all the code for
libcurl, threading etc. (via a struct), so in the function where I need
to set the path to the certificate file, I need to get the path of the
dll to set the certificate store correctly.
Both classes are created by functions like:
rest_class = class_new(gensym(rest), (t_newmethod)rest_new,
(t_method)rest_free, sizeof(t_rest), 0,
A_GIMME, 0);
and
t_rest *x = (t_rest *)pd_new(rest_class);
Now, I need a way to get the value rest from this *x, for this:
static void *ctw_exec_req(void *thread_args) {
struct _ctw *common = thread_args;
/* more declarations */
#ifdef _WIN32
/* Workaround for loading certificates on Windows */
char path[2048];
/* This will output the path to pd.exe */
GetModuleFileName(NULL, path, 2048);
post(dll path: %s, path);
/* This will output the path to rest.dll, how do I get rest
from *thread_args */
GetModuleFileName(GetModuleHandle(rest), path, 2048);
post(dll path: %s, path);
#endif
/* all the rest to execute request via curl */
}
Thanks in advance,
Thomas
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs)
On 03/28/2013 09:28 PM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev@iem.at pd-dev@iem.at Sent: Thursday, March 28, 2013 4:50 PM Subject: Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs) On 03/28/2013 01:46 PM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-dev@iem.at Cc: Sent: Thursday, March 28, 2013 4:26 PM Subject: Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs) [...] How about we start with adding only the required mechanism so that people can make all sorts of plugin management plugins. Then revisit the rest later once we have a good idea of how it should be done. Making the plugin loader ignore a folder called DISABLED/ would make it possible to do what you describe in a regular plugin. .hc Do you want to require plugins to live in one specific startup directory that has user permissions to read/write/exec? If so, then I think the startup/disabled directory idea is adequate. On the other hand, if you want Pd to search the standard paths for plugins then the startup/disabled idea is incompatible with that, no? Permission problems abide, plus when you want to re-enable a plugin how does Pd know which directory it previously lived in? As I see it now, DISABLED/ would be ignored in all search paths. And when a plugin is disabled, it would be moved into the local DISABLED/ folder. That method will fail when the user running Pd doesn't have permission to move those files. -Jonathan That is true. That would only really affect multi-user setups where a sysadmin was installing plugins. Maybe Andras' idea for using a list that is stored in the GUI preferences makes the most sense here. If the plugin list is present, then it loads that, if not, it uses the search path method. Or there is IOhannes' method with the autostart plugin. It has the advantage of being controlable via the file system, i.e. if the autostart plugin is removed, then its disabled. This list method would need to be disabled via the preferences. One way to handle that would be that the plugin-plugin would have to handle the writing of the list to the preferences each time Pd runs, and Pd would load the list if it was present, then delete it from the preferences. Hmm, that might be hacky... .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Patches-3609350 ] prevent recursive loading of gui-plugins
On 03/28/2013 07:17 AM, András Murányi wrote: On Thu, Mar 28, 2013 at 12:42 PM, SourceForge.net nore...@sourceforge.netwrote: Patches item #3609350, was opened at 2013-03-28 04:42 Message generated for change (Tracker Item Submitted) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=3609350group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: prevent recursive loading of gui-plugins Initial Comment: if a gui-plugin loads other plugin, we might easily encounter a recursion (where the plugin tries to load itself). while the current gui-plugin loader mechanism tries to prevent re-loading of the same plugin (based on the filename of the plugin), it doesn't catch recursive loading. the attached patch fixes this, by adding the to-be-loaded plugin to the ::loaded_plugins list, then tries to load it and removes it from the list if the loading fails (rather than adding the plugin to the list after the loading succeeded) Some minor comments from the perspective of the current plugins-plugin which you may or may not want to consider: - the plugin creates a ::plugins_loaded list which is almost the same as ::loaded_plugins with the difference that -plugin.tcl is stripped and, more importantly, brackets in the name are stripped too because they can cause weird things when handling the strings in tcl. - for the sake of tidiness, the plugin introduces a ::plugins namespace where all the functions go. - what about splitting the whole plugin stuff out into a new pd_plugins.tcl so that we don't have to worry too much about bloating pd-gui.tcl? FYI: current plugins-plugin is cca. 200 lines, of which obligatory protocol is 20 lines, switching mechanism is 40 lines, meta extraction is 60 lines and building the dialog box is 70 lines - thought this may assist the decision about what to maintain inside pd and what to leave in a plugin. My 2 cents are that the moving-the-file way of managing is ugly and a list of enabled plugins shall be maintained in the preferences. Pd-gui could load everything (or nothing) by default, letting a plugin modify the list. So it would at the end take only a few extra lines in core pd gui. Users currently install plugins by putting them in a folder. Plugins are managed via whatever preferred file management the user likes. Plugin managers can easily do the same. Then users who are used to doing it via a file browser will still be able to do that whether or not they are using a plugin manager. And installing and managing plugins both happen by moving files around. There needs to be a consistent experience here, so the management process should not be different than the installation process. I don't see any real advantage to adding complexity to installing plugins when dropping it into a folder is enough. What particular problems are there with using the DISABLED/ folder? .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs)
On 03/28/2013 01:46 PM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-dev@iem.at Cc: Sent: Thursday, March 28, 2013 4:26 PM Subject: Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs) [...] How about we start with adding only the required mechanism so that people can make all sorts of plugin management plugins. Then revisit the rest later once we have a good idea of how it should be done. Making the plugin loader ignore a folder called DISABLED/ would make it possible to do what you describe in a regular plugin. .hc Do you want to require plugins to live in one specific startup directory that has user permissions to read/write/exec? If so, then I think the startup/disabled directory idea is adequate. On the other hand, if you want Pd to search the standard paths for plugins then the startup/disabled idea is incompatible with that, no? Permission problems abide, plus when you want to re-enable a plugin how does Pd know which directory it previously lived in? As I see it now, DISABLED/ would be ignored in all search paths. And when a plugin is disabled, it would be moved into the local DISABLED/ folder. So disabling a plugin in ~/pd-externals would place it into ~/pd-externals/DISABLED. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs)
On 03/26/2013 07:52 AM, András Murányi wrote: On Tue, Mar 26, 2013 at 1:34 AM, Hans-Christoph Steiner h...@at.or.atwrote: On 03/03/2013 08:46 AM, András Murányi wrote: On Sat, Feb 23, 2013 at 2:45 AM, Hans-Christoph Steiner h...@at.or.at wrote: Sounds like -noplugins would be a good idea, but it does not exist. None of those flags will disable plugins in the user folders (~/pd-externals). You shouldn't need a Recent Files plugin any more with 0.43.4, its included on all platforms. But maybe its not as good as the plugin version? The plugin overwrites the original ::pd_menus::update_recentfiles_on_menu so I guess it's aiming to do something better. About the -noplugins option: yes it would be nice, and btw, I've just realised that the planned evolution of plugins-plugin to use pd::guiprefs instead of /disabled folders cannot be done in a plugin form but needs the mechanism to go into pd-gui.tcl This sounds like a good case to overhaul the plugin loading code a bit. What do you think? András I'm happy to review patch submissions for this, the plugins handling certainly can be improved. What do you have in mind? .hc basically, implementing a -noplugins option, and wiring plugins preferences to pd::guiprefs I think that a -noplugins flag is a no brainer, that should be included. I'm still on the fence about adding the ability to disable plugins via the interface. The model so far for installing and disabling externals, plugins, etc. is putting them in the user-installed folder or moving them out of that folder. Its very simple and easy to maintain. I have no objections for adding the possibility to allow plugin management in a plugin, but I'm not sure about including it by default. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SVNCommitAccess
Hey Matthias, I'll be quite happy to see your contributions! Welcome! The waiting period has definitely passed with no objections, so I tried to add you. Sourceforge told me User does not exist.. .hc On 03/13/2013 08:49 AM, Matthias Kronlachner wrote: hi pd-dev list, my name is matthias kronlachner, master student of electrical engineering-audio engineering at iem graz (austria), but currently living in vilnius, lithuania. i am teaching computer music (with support of pd) at the music and theatre academy vilnius (lmta), writing my master thesis and working on various projects. i would like to apply for svn commit access. since about 5 years i'm using pd to generate audio and video for performances and installations. i was lucky to learn a lot from the staff of iem (IOhannes, ritsch, musil), especially about pd. my interests are in performing electronic music, spatial audio, human machine interfaces, computer vision, streaming audio and video, algorithmic composition... some of my projects can be found on my website: http://www.matthiaskronlachner.com i developed several pd and gem externals, especially for the kinect sensor. currently my pd externals reside at github: https://github.com/kronihias i'd like to contribute to the repo with my pd externals and fix issues with existing ones, if investigated. i just ported a dbap (directional based amplitude panning) external from max to pd, and i guess it would be good to have that at the main repository. my sourceforge name: mkronlachner hope to be able to contribute further to this great project. kind regards, matthias ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/27/2013 01:27 PM, IOhannes m zmoelnig wrote: On 2013-03-27 21:12, Hans-Christoph Steiner wrote: I think that a -noplugins flag is a no brainer, that should be included. I'm still on the fence about adding the ability to disable plugins via the interface. The model so far for installing and disabling externals, plugins, etc. is putting them in the user-installed folder or moving them out of that folder. Its very simple and easy to maintain. definitely not. i find myself cursing everytime i want to use/not use a given gui-plugin. moving files around is _not_ a way to configure your system. at least i know of no system that is configured like that; not that there *are* some system settings that work like that (`find /etc -type d -name *.d) but those are not for user-preferences that might change today *and* tomorrow. also, there might be a reason why Pd-extended switched from loading all libraries by default to a scheme, where the user has to explicitely enable a given feature. taking your gui-plugins argument to PdX, we could have simply told the users to just move all the objects/externals they don't want to use to a save place (and turn off the couldn't find errors) I have no objections for adding the possibility to allow plugin management in a plugin, but I'm not sure about including it by default. it's simply not possible to unload a given plugin with a plugin that is loaded afterwards. (at least not until all the gui-plugins implement an unloading mechanism). if we have the opportunity to get a built-in gui-plugins management instead of the last-files i'm all for it (as the latter can be easily implemented as a plugin, unlike the former) The plugin-management plugin can just move the plugin files itself to disable them, so we could just make the system plugin loader ignore a folder called DISABLED/ inside each path. Then people can make plugin-management plugins using that mechanism, and customize the rest however they see fit. This would also be easy to understand for people who are just moving files around manually. .hc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRU1lyAAoJEJ8P5Yc3S76BJxMP/iPnbWYHCcCwTCpWk8q/99UA Uk0gUQJB4IJGnRNCCsSLRqRjapbLaM91foPd0dmiJXLsxBMnqwXn1VjlrBIP3IR6 QqAsXtyBjdluz9+eBa9/dvn9juZqrqdlcD8I8TuJO+K1HMPeKNoQK3mQ3hmN+4yZ QPO8SwuQYZcOTPyxZgF/ETF0FJ9XkFkmbyQoPwFow/A/rjUbx7mmX5TVPP9P18cE Tav/D/3ghm1cHgNqYNMPxxdSaxxJ0FSg2Xz08xyaGVozksL3ynqWDBkDIxrTOs3Z E0FckoaeAcx1a2wd6blHfQSD7U3It99rSP9dth4yxM+T9/YzsOxaKZ/0YtqxEcUW TNK2AdF6xUl7ULVTTog6DLjQ2MvFHezD6dM92BhawfAasdBkcJCC9HGl0CiNL8n6 YeI6bmtg1eCNx3qQ0lOpBPL78MUxnnp7mM0nLbh+Purr2hHedswHHUOrczcw7YZd eDd8R2MkRCo5CGLbIec0/t0Nc4zUIfPXVZHt4sFhFwRBga0dYUcbqHC2Amfpbs+b HS0IqHTJxTn2uc81is5leH/dEv1ZMwz+2UrRu3Jk2f9i0NQCC+q4/i5nXPoE8zg3 RGnNoe6aZWqtWEeReBj8WVKI2haK9xyS9B3LMHi84osnWFw8V1CLZd/v8tnOLZVJ eQJS/pN0eJ6uYohaJ+Kj =wRBw -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs)
On 03/03/2013 10:05 AM, yvan volochine wrote: On 03/03/13 12:29, yvan volochine wrote: ps: [OT] I notice that recentfile support was broken on linux by 356fa6abd89d9 will submit a patch later to fix that.. done: https://sourceforge.net/tracker/?func=detailaid=3606687group_id=55736atid=478072 cheers, y Sorry about that, I broke that. Thanks for fixing it! .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs)
On 03/03/2013 08:46 AM, András Murányi wrote: On Sat, Feb 23, 2013 at 2:45 AM, Hans-Christoph Steiner h...@at.or.atwrote: Sounds like -noplugins would be a good idea, but it does not exist. None of those flags will disable plugins in the user folders (~/pd-externals). You shouldn't need a Recent Files plugin any more with 0.43.4, its included on all platforms. But maybe its not as good as the plugin version? The plugin overwrites the original ::pd_menus::update_recentfiles_on_menu so I guess it's aiming to do something better. About the -noplugins option: yes it would be nice, and btw, I've just realised that the planned evolution of plugins-plugin to use pd::guiprefs instead of /disabled folders cannot be done in a plugin form but needs the mechanism to go into pd-gui.tcl This sounds like a good case to overhaul the plugin loading code a bit. What do you think? András I'm happy to review patch submissions for this, the plugins handling certainly can be improved. What do you have in mind? .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] meta data for Miller's Pd tutorials
Hey Jonathan, Miller, Sofy Yuditskaya, Joshua Clayton, Joe Deken and I had a meeting to work on our Pd Starter Kit project. As part of that, we want to build upon all your meta data and search plugin work. We thought it made sense to be able to tag tutorials with meta so that the search plugin can dynamically generate browsable lists of tutorials as well as provide a way to just search tutorials, for example. I'm happy to leave the exact meta data format to you since you've got the best idea of how it should be, and I can contribute coding to the search plugin. This would be one more step to eliminating the old Help Browser. Miller and I were also talking about adding meta data to his included tutorials. He thought the best way to submit that to him would be if you start with the current tutorial files in 2.control.examples, 3.audio.examples, and 4.data.structures that are in git, then add the meta data to them, then just send those files to miller in one big package. Is that workable for you? It would also be a good time to fix any spelling or grammar errors that you come across, but it would not be a good time to do more substantial changes. That's something for you to work out with Miller directly. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] building toxy
On Mar 1, 2013, at 2:39 AM, IOhannes m zmölnig wrote: On 02/28/2013 23:25, András Murányi wrote: Hi list, I've recently built miXed/toxy for pd-l2ork successfully but now I've run into errors with pd-extended. The errors concern tot. I've noticed that they are not the same version (see the diff below), however copying the l2ork one over the extended one doesn't solve the problem but triggers different errors. Could there be an easy way out? btw, [tot] is incompatible with Pd=0.43 (be it PdX or Pd-vanilla). tot does low-level interaction with Pd's old-style GUI, which simply doesn't work any more with the new GUI. fgmadsr IOhannes Also, I think that the iemguts libs and [sys_gui] gives you basically everything that tot does. And tclpd is easier than [widget] for making GUI objects in Tcl. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] building toxy
You defintely want .x%lx and not .x%x. .x%lx is needed for working 64-bit support. .hc On 02/28/2013 05:25 PM, András Murányi wrote: Hi list, I've recently built miXed/toxy for pd-l2ork successfully but now I've run into errors with pd-extended. The errors concern tot. I've noticed that they are not the same version (see the diff below), however copying the l2ork one over the extended one doesn't solve the problem but triggers different errors. Could there be an easy way out? 160c160 sprintf(buf, .x%lx.c, (int)cv); --- sprintf(buf, .x%x.c, (int)cv); 402c402 sprintf(buf, .x%lx, (int)cv); --- sprintf(buf, .x%x, (int)cv); 429c429 sprintf(buf, .x%lx, (int)cv); --- sprintf(buf, .x%x, (int)cv); 464c464 sprintf(buf, .x%lx, (int)cv); --- sprintf(buf, .x%x, (int)cv); 595c595 sprintf(buf, .x%lx.c, (int)glist); --- sprintf(buf, .x%x.c, (int)glist); Thanks for any tips! PS I'm on amd64 András ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] I have 3 broken installs [was: Re: double precision Pd: .patch files, tests and benchmarks]
Sounds like -noplugins would be a good idea, but it does not exist. None of those flags will disable plugins in the user folders (~/pd-externals). You shouldn't need a Recent Files plugin any more with 0.43.4, its included on all platforms. But maybe its not as good as the plugin version? .hc On 02/22/2013 06:26 PM, András Murányi wrote: Ah! Today I've accidentally managed to reproduce my Signaling watchdog... problem and narrow the problem to Recent Files plugin 0.1. It works with version 0.2, so good-bye to a one-year annoyance. ( https://sourceforge.net/tracker/index.php?func=detailaid=3473145group_id=55736atid=478070 ) Just one question: the problem didn't go away with -noaudio -nostdpath -noprefs -nostartup. Shouldn't these flags prevent loading startup plugins as well? András On Thu, Oct 6, 2011 at 9:01 PM, András Murányi muran...@gmail.com wrote: 2011/10/6 Hans-Christoph Steiner h...@at.or.at On Oct 6, 2011, at 12:19 PM, András Murányi wrote: Do you have access to an ARM machine? If not, I could probably get one online with ssh access, if that's useful. I've mailed Joe White with the question if he can patch the code for libpd and check performance on ARM. He has done some extremely popular RjDj apps and needed to optimize for them as well. Think it would be good anyway to keep in touch with libpd users and app programmers about this topic, even though we're in an early stage with it. Yes definitely, we should let everyone who wants to be get involved. I am just saying with need a development platform to start with. Once that's nailed down, we can deal with more issues, like porting to libpd, dealing with externals that could be either 32-bit or 64-bit, etc. I setup a nightly build on the macosx106-x86_64 and called it pd-double. Andras and r33p, if you are listening, could you run this build on your 64-bit boxes also? All you need to do is: ~pd/auto-build cp -a pd-extended pd-double Listening now. I did: $ cd ~pd/auto-build $ sudo cp -a pd-extended pd-double What's next? Shall I try patching or rather pull IOhannes's sources? If you have the run-automated-builder script in a cron job, that is all you have to do. .hc Ah, so tomorrow a single and double precision build will automatically be made? Cool. Also, as I was busy with my life (buying a flat) these days, and I couldn't follow the list as precisely as I wished, could you advise me what's the current best way to roll my own double precision pd? Because I would like to benchmark a fully optimised one. That would great to have those numbers. [...] Aaargh. I've arrived to the point where I have almost no functional pd on my box (with the exception of l2ork). vanilla says: bash: /usr/bin/pd: No such file or directory (i remember this is a known issue... for 64bit? can it be fixed by any chance?) extended (latest autobuild), and the fresh-built double keep on saying watchdog: signaling pd... What did I mess up? Will complete removals/reinstalls help? You can always 'apt-get install puredata' , you can even get 'puredata' 0.43.0 for Ubuntu/Lucid from my PPA: https://launchpad.net/~**eighthave/+archive/pure-datahttps://launchpad.net/%7Eeighthave/+archive/pure-data Then you can get the pd-extended 0.42.5 release. As for nightlies and other test builds, you can use dpkg -x to extract them anywhere, and them in place. .hc OK, I've installed pd from your PPA, and the same story: watchdog signaling pd... My question is, what's this curse on my box? Or how can I make a tabula rasa so that a new install runs alrite? (Deleting .pdsettings doesn't solve this) Thanks for the patience Andras ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] building zexy on Windows outside of pd-extended
As far as I can tell, zexy is unbuildable on Windows unless you have the complete Pd source and you have built that source. This is because you need to use the autotools system, and it only knows about that kind of setup. The Pd-extended binary package includes everything needed to build zexy (headers, pd.dll). export PATH=/usr/local/bin:/bin:/usr/bin:$PATH autoreconf --install --force --verbose ./configure --disable-library --prefix= --libdir=$WORKSPACE/DESTDIR --with-pd=$PROGRAMFILES/pd CPPFLAGS=-I$PROGRAMFILES/pd/include/pd EXTRA_LTFLAGS=-L$PROGRAMFILES/pd/bin LDFLAGS=-L$PROGRAMFILES/pd/bin make And it always dies on linking: make[2]: Entering directory `/c/pd-jenkins-build/workspace/zexy/label/windowsxp-i386/src' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -IC:\Programme/pd -IC:\Programme/pd/include/pd -g -O2 -mms-bitfields -MT 0x260x260x7e.lo -MD -MP -MF .deps/0x260x260x7e.Tpo -c -o 0x260x260x7e.lo 0x260x260x7e.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -IC:\\Programme/pd -IC:\\Programme/pd/include/pd -g -O2 -mms-bitfields -MT 0x260x260x7e.lo -MD -MP -MF .deps/0x260x260x7e.Tpo -c 0x260x260x7e.c -DDLL_EXPORT -DPIC -o .libs/0x260x260x7e.o mv -f .deps/0x260x260x7e.Tpo .deps/0x260x260x7e.Plo /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -mms-bitfields -module -avoid-version -shared -shrext .dll -no-undefined -LC:\Programme/pd/bin -Xlinker -l:pd.dll -LC:\Programme/pd/bin -LC:\Programme/pd/bin -o 0x260x260x7e.la -rpath c:\pd-jenkins-build\workspace\zexy\label\windowsxp-i386/DESTDIR/zexy 0x260x260x7e.lo -lregex -lm -lgdi32 -luser32 -lkernel32 -lcoldname -lcrtdll libtool: link: gcc -shared .libs/0x260x260x7e.o -LC:\Programme/pd/bin -lregex -lgdi32 -luser32 -lkernel32 -lcoldname -lcrtdll -O2 -mms-bitfields -Wl,-l:pd.dll -o .libs/0x260x260x7e.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/0x260x260x7e.dll.a c:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../../mingw32/bin/ld.exe: cannot find pd.dll collect2.exe: error: ld returned 1 exit status make[2]: *** [0x260x260x7e.la] Error 1 make[2]: Leaving directory `/c/pd-jenkins-build/workspace/zexy/label/windowsxp-i386/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/pd-jenkins-build/workspace/zexy/label/windowsxp-i386' make: *** [all] Error 2 Build step 'Execute shell' marked build as failure .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] building zexy on Windows outside of pd-extended
On 02/18/2013 04:03 PM, IOhannes m zmölnig wrote: On 02/18/2013 21:07, Hans-Christoph Steiner wrote: As far as I can tell, zexy is unbuildable on Windows unless you have the complete Pd source and you have built that source. zexy has been built on windows since 1999, without having the need to build Pd yourself. that was long before i started to use autotools, and there are still a number of build systems included in zexy that are exclusively useable on w32. c:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../../mingw32/bin/ld.exe: cannot find pd.dll collect2.exe: error: ld returned 1 exit status but i'll have a look at this. Its obviously possible since its built as part of Pd-extended every night. It seems I committed some stuff in externals/Makefile that works some magic that I cannot reproduce on the MinGW terminal. You can see a history of my attempts here: https://macosx105-i386.pdlab.puredata.info/job/zexy/ .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] popup changes
Hey IOhannes, I don't know if you know about the 'flatgui' library, which includes a maintained version of entry. You're welcome to maintain the version in externals/bbogart/entry if you want, but its redundant. .hc On 02/06/2013 06:00 AM, pd-cvs-requ...@iem.at wrote: Send Pd-cvs mailing list submissions to pd-...@iem.at To subscribe or unsubscribe via the World Wide Web, visit http://lists.puredata.info/listinfo/pd-cvs or, via email, send a message with subject or body 'help' to pd-cvs-requ...@iem.at You can reach the person managing the list at pd-cvs-ow...@iem.at When replying, please edit your Subject line so it is more specific than Re: Contents of Pd-cvs digest... Today's Topics: 1. SF.net SVN: pure-data:[17025] trunk/externals/bbogart/popup/popup.c (zmoel...@users.sourceforge.net) 2. SF.net SVN: pure-data:[17026] trunk/externals/bbogart/popup/popup.c (zmoel...@users.sourceforge.net) 3. autobuild: pd-extended macosx105-i386 2013-02-06 03.15.20 (Pd Build User) -- Message: 1 Date: Tue, 05 Feb 2013 14:06:32 + From: zmoel...@users.sourceforge.net Subject: [PD-cvs] SF.net SVN: pure-data:[17025] trunk/externals/bbogart/popup/popup.c To: pd-...@iem.at Message-ID: e1u2jao-0006yw...@sfp-svn-4.v30.ch3.sourceforge.com Content-Type: text/plain; charset=UTF-8 Revision: 17025 http://pure-data.svn.sourceforge.net/pure-data/?rev=17025view=rev Author: zmoelnig Date: 2013-02-05 14:06:29 + (Tue, 05 Feb 2013) Log Message: --- compat with Pd=0.43 after the GUI rewrite, pd-gui uses 'pdsend' to send messages back to Pd, rather than 'pd' (as with Pd=0.42) LATER: check about PdX Modified Paths: -- trunk/externals/bbogart/popup/popup.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. -- Message: 2 Date: Tue, 05 Feb 2013 14:25:08 + From: zmoel...@users.sourceforge.net Subject: [PD-cvs] SF.net SVN: pure-data:[17026] trunk/externals/bbogart/popup/popup.c To: pd-...@iem.at Message-ID: e1u2jso-0007u9...@sfp-svn-4.v30.ch3.sourceforge.com Content-Type: text/plain; charset=UTF-8 Revision: 17026 http://pure-data.svn.sourceforge.net/pure-data/?rev=17026view=rev Author: zmoelnig Date: 2013-02-05 14:25:05 + (Tue, 05 Feb 2013) Log Message: --- enable sys_getversion for Pd=0.42 sys_getversion() was introduced with 0.42.0 Modified Paths: -- trunk/externals/bbogart/popup/popup.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. -- Message: 3 Date: Wed, 6 Feb 2013 04:14:06 -0500 (EST) From: p...@macosx105-i386.pdlab.puredata.info (Pd Build User) Subject: [PD-cvs] autobuild: pd-extended macosx105-i386 2013-02-06 03.15.20 To: pd-...@iem.at Message-ID: 20130206091406.cfaea4f67...@macosx105-i386.pdlab.puredata.info last 20 errors rsync error: syntax or usage error (code 1) at /SourceCache/rsync/rsync-35.2/rsync/main.c(1166) [receiver=2.6.9] last 15 lines --bwlimit=KBPS limit I/O bandwidth; KBytes per second --write-batch=FILE write a batched update to FILE --only-write-batch=FILE like --write-batch but w/o updating destination --read-batch=FILE read a batched update from FILE --protocol=NUM force an older protocol version to be used -E, --extended-attributes copy extended attributes -4, --ipv4 prefer IPv4 -6, --ipv6 prefer IPv6 --version print version number (-h) --help show this help (-h works with no other options) Use rsync --daemon --help to see the daemon-mode command-line options. Please see the rsync(1) and rsyncd.conf(5) man pages for full documentation. See http://rsync.samba.org/ for updates, bug reports, and answers rsync error: syntax or usage error (code 1) at /SourceCache/rsync/rsync-35.2/rsync/main.c(1166) [receiver=2.6.9] the full logfile - if it has been succesfully uploaded - can be viewed at: http://autobuild.puredata.info/auto-build/2013-02-06/logs/2013-02-06_03.15.20_darwin_macosx105-i386_pd-extended.txt -- ___ Pd-cvs mailing list pd-...@iem.at http://lists.puredata.info/listinfo/pd-cvs End of Pd-cvs Digest, Vol 96, Issue 6 * ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] macosx105-powerpc is back online
The PowerPC mac build machine is back online, thanks to Greg Pond. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] no more 'patch_series' branch for pd-extended.git
I've decided to stop using the 'patch_series' branch in the pd-extended.git and switch to a straightforward 'master' branch as the place where everything happens. The 'patch_series' branch worked well when Pd-extended was a set of patches against Pd-vanilla, but that is less and less the case. For example, there is no 'extra' objects in Pd-extended, instead that is treated as the 'extra' library which is in pure-data SVN. Its just a straight copy of the pd-vanilla extra objects with a build system like the library template. As Jonathan continues to work on his versions of the doc/2.control.examples, doc/3.audio.examples, etc. those will be removed from pd-extended.git and Pd-extended will use Jonathan's versions. Once I get a workable system for making a complete 'vanilla' library, then that stuff will be removed from pd-extended.git So in summary, it means that Pd-extended will track the core of Pd-vanilla within git, but the objects, extra, doc, etc. will be spun out to be tracked separately. I think that'll greatly smooth out the development process. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] small regression regarding window placement
This is sorted out in Pd-extended, if you want to compare. I'm not sure what the exact changes are. I think there is platform-specific logic to bump the window down if its in the menu bar. .hc On 02/01/2013 02:05 PM, Miller Puckette wrote: Drat.. On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window. but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a new canvas, not when you restored a saved one. Something else must be going wrong. M On Fri, Feb 01, 2013 at 08:00:47PM +0100, Roman Haefeli wrote: Hi Miller The git-commit 3b876c63b3682701b569f30e144fea4b6bee9f84 does the following change: -#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50 which causes my Pd not to show windows on the top of the screen anymore. The reason is that on my system $::windowframey is actually 44 and when saving a patch placed on the top left of the screen, next time I open the patch it is placed 6px below top (0 44 from the pd file gets overwritten by 0 50). I don't actually understand the reason for changing GLIST_DEFCANVASYLOC, but would it cause any harm to reverse it? Roman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] small regression regarding window placement
I say remove that bit entirely and let the GUI handle figuring out where the window should go. Pd should just relay the unadulterated values from the Pd patch. Only the GUI can figure this out, especially considering all of the variations of window managers and platforms. These days Tk will handle a lot of this stuff for you. .hc On 02/01/2013 03:50 PM, Miller Puckette wrote: Found it... firther down in g_canvas.c: if (yloc GLIST_DEFCANVASYLOC) yloc = GLIST_DEFCANVASYLOC; if (xloc 0) xloc = 0; I'm not sure what the correct foolproofing should be (or indeed if it's a good idea to have foolproofing there at all). But anyhow removing those lines will make it possible for patches to restore themselves wherever they were saved from. cheers Miller On Fri, Feb 01, 2013 at 09:10:23PM +0100, Roman Haefeli wrote: On Fre, 2013-02-01 at 11:05 -0800, Miller Puckette wrote: On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window. I should have given more context: #ifdef __APPLE__ #define GLIST_DEFCANVASYLOC 22 #else -#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50 #endif So it seems that particular change does not affect Mac OS X. Thus I assume that reverting it wouldn't change the behavior on Macs either. but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a new canvas, not when you restored a saved one. Something else must be going wrong. Sorry for not being of any help here. Roman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] More canvas position woes
For more on this topic, check out the comments in pdtk_canvas.tcl and this link: http://wiki.tcl.tk/11502 Tk X11 returns the size of the window without the framing, and the framing varies widely depending on the WM. For your plugin, you'll want to override pdtk_canvas_place_window using 'rename' and write one that works for your WM. .hc On 02/01/2013 05:34 PM, Roman Haefeli wrote: Hi all The assumed window border sizes are hard-coded in tcl/pd-gui.tcl: set ::windowframex 3 set ::windowframey 53 However, those values might not be correct on some systems. On my system (with fluxbox as a window manager) those values actually are 0 and 44. This leads to moving canvas: Whenever I save a patch, close and open it again, it shifts 9px up and 3px to the left. This shift even happens on each 'vis 0, vis 1' cycle sent to [s pd-canvasname]. This is actually not a Pd question: Is there a way to know the actual windowframe sizes in tcl/tk? Detecting the actual sizes would be the only real solution to this problem, I suppose. Alternatively, is there a way to write a GUI plugin to put my adjustments into, so that I don't have to modify tcl/pd-gui.tcl after every Pd update? I - naively - tried to simply put this: set ::windowframex 0 set ::windowframey 44 into ~/pd-externals/correct_windowframe-plugin.tcl. It seems to work so far, if I load patches from the file-open menu. When loading a patch from the command line, the wrong values still are used for the main patch. For all sub-sequent canvases (a.k.a subpatches of the main patch, abstractions of the main patch or sub-sequently opened patches), the correct values from the plugin are taken. Another issue is the wrapping of the menu in narrow canvases. When I work in a patch that shows the menu in two lines, the offset increases by another 28px. This means that on each save/reload cycle (or 'vis 0, vis 1' cycle, for that matter) the canvas shifts up by 28px. Of course, it's not a really urgent problem, but still slightly annoying. Roman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdlab licid-amd64 (was Re: autobuild: fribidi support)
On 01/31/2013 10:05 AM, András Murányi wrote: On Mon, Jan 28, 2013 at 11:19 PM, Hans-Christoph Steiner h...@at.or.atwrote: On 01/27/2013 01:31 PM, András Murányi wrote: On Sun, Jan 27, 2013 at 2:19 AM, Hans-Christoph Steiner h...@at.or.at wrote: On 01/23/2013 03:38 PM, András Murányi wrote: On Wed, Jan 23, 2013 at 12:56 AM, Hans-Christoph Steiner h...@at.or.at wrote: On 01/22/2013 05:34 PM, András Murányi wrote: [...] BTW, rsync fails here with Host key verification failed. Actually, I forgot to say, if you want to run it as a jenkins build slave, that would definitely still be useful. .hc Jenkins is behaving bad here (doesn't seem to start up at boot, then it doesn't connect to the master when started) but i'll try to discipline it. As for the autobuild script, I've done svn up, yet it fails with the following *before it still tries to rsync*. Shall we try to fix it or shall I dump it? I think we don't need the auto-build if the jenkins builds work. we can produce working Lucid packages in Launchpad. .hc Ok, I'll shut the autobuild down here but I'm afraid I'll need some help with Jenkins. It comes out that it does connect successfully, however there is an error all the time: https://macosx105-i386.pdlab.puredata.info/computer/muranyia.dyndns.org/ Any ideas what is this? András I was just setting up the Windows XP build machine as a Jenkins slave and ran into the same issue. Its because your Java install doesn't trust the CAcert.org certificate used by the jenkins master. You need to import the cacert certificate into the Java keystore, then it'll validate OK and should work. Here's how: sudo keytool -keystore /usr/lib/jvm/default-java/jre/lib/security/cacerts -storepass changeit -import -trustcacerts -v -alias cacertclass1 -file /usr/share/ca-certificates/cacert.org/cacert.org.crt Or if I messed up the paths, there is more info here: http://wiki.cacert.org/FAQ/ImportRootCert#Java .hc Thanks for the tip! I have no /usr/lib/jvm/default-java but I have all these under /usr/lib/jvm: ia32-java-6-sun/ .java-1.6.0-openjdk.jinfo ia32-java-6-sun-1.6.0.26/ java-6-openjdk/ .ia32-java-6-sun.jinfo java-6-sun/ java-1.5.0-gcj-4.4/java-6-sun-1.6.0.26/ java-1.6.0-openjdk/.java-6-sun.jinfo Trying to add the key to java-6-sun or java-6-openjdk results in: Certificate already exists in system-wide CA keystore under alias cacert_org_pem Do you still want to add it to your own keystore? [no]: Shall I choose [yes] or shall I try every other java keystore, or is there a way to find out which one is used by Jenkins? Sorry if I'm dumber than normally, I got a fever! András You could also try to download the root.crt and class3.crt from cacert.organd install those. I don't really know the answer to the particular issue. .hc DLed the certs and installed them, however the problem persists. :( András I had good luck running the jenkins slave from the command line (not as root!) to get more debugging info: /usr/bin/java -jar /usr/share/jenkins/slave.jar -jnlpUrl \ https://macosx105-i386.pdlab.puredata.info/computer/muranyia.dyndns.org/ .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdlab licid-amd64 (was Re: autobuild: fribidi support)
On 01/31/2013 03:34 PM, András Murányi wrote: On Thu, Jan 31, 2013 at 7:02 PM, Hans-Christoph Steiner h...@at.or.atwrote: On 01/31/2013 10:05 AM, András Murányi wrote: On Mon, Jan 28, 2013 at 11:19 PM, Hans-Christoph Steiner h...@at.or.at wrote: On 01/27/2013 01:31 PM, András Murányi wrote: On Sun, Jan 27, 2013 at 2:19 AM, Hans-Christoph Steiner h...@at.or.at wrote: On 01/23/2013 03:38 PM, András Murányi wrote: On Wed, Jan 23, 2013 at 12:56 AM, Hans-Christoph Steiner h...@at.or.at wrote: On 01/22/2013 05:34 PM, András Murányi wrote: [...] BTW, rsync fails here with Host key verification failed. Actually, I forgot to say, if you want to run it as a jenkins build slave, that would definitely still be useful. .hc Jenkins is behaving bad here (doesn't seem to start up at boot, then it doesn't connect to the master when started) but i'll try to discipline it. As for the autobuild script, I've done svn up, yet it fails with the following *before it still tries to rsync*. Shall we try to fix it or shall I dump it? I think we don't need the auto-build if the jenkins builds work. we can produce working Lucid packages in Launchpad. .hc Ok, I'll shut the autobuild down here but I'm afraid I'll need some help with Jenkins. It comes out that it does connect successfully, however there is an error all the time: https://macosx105-i386.pdlab.puredata.info/computer/muranyia.dyndns.org/ Any ideas what is this? András I was just setting up the Windows XP build machine as a Jenkins slave and ran into the same issue. Its because your Java install doesn't trust the CAcert.org certificate used by the jenkins master. You need to import the cacert certificate into the Java keystore, then it'll validate OK and should work. Here's how: sudo keytool -keystore /usr/lib/jvm/default-java/jre/lib/security/cacerts -storepass changeit -import -trustcacerts -v -alias cacertclass1 -file /usr/share/ca-certificates/cacert.org/cacert.org.crt Or if I messed up the paths, there is more info here: http://wiki.cacert.org/FAQ/ImportRootCert#Java .hc Thanks for the tip! I have no /usr/lib/jvm/default-java but I have all these under /usr/lib/jvm: ia32-java-6-sun/ .java-1.6.0-openjdk.jinfo ia32-java-6-sun-1.6.0.26/ java-6-openjdk/ .ia32-java-6-sun.jinfo java-6-sun/ java-1.5.0-gcj-4.4/java-6-sun-1.6.0.26/ java-1.6.0-openjdk/.java-6-sun.jinfo Trying to add the key to java-6-sun or java-6-openjdk results in: Certificate already exists in system-wide CA keystore under alias cacert_org_pem Do you still want to add it to your own keystore? [no]: Shall I choose [yes] or shall I try every other java keystore, or is there a way to find out which one is used by Jenkins? Sorry if I'm dumber than normally, I got a fever! András You could also try to download the root.crt and class3.crt from cacert.organd install those. I don't really know the answer to the particular issue. .hc DLed the certs and installed them, however the problem persists. :( András I had good luck running the jenkins slave from the command line (not as root!) to get more debugging info: /usr/bin/java -jar /usr/share/jenkins/slave.jar -jnlpUrl \ https://macosx105-i386.pdlab.puredata.info/computer/muranyia.dyndns.org/ .hc Aah, cool! Jenkins says: JNLP file https://macosx105-i386.pdlab.puredata.info/computer/muranyia.dyndns.org/has invalid arguments: [-headless] Most likely a configuration error in the master two arguments required, but got [] András Strange, I don't see anything here about that: https://macosx105-i386.pdlab.puredata.info/computer/muranyia.dyndns.org/configure Perhaps delete that node in jenkins and try again from scratch? .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] new IP address for macosx105-i386.pdlab.puredata.info
The IP address has changed for macosx105-i386.pdlab.puredata.info its now: 184.75.101.123 I thought that internet connection had a static ip, but I guess its static-ish. It changes every year or so. .hc signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pi page on Pd developer WIKI?
Yes, it would be great to document all this Rpi activity on the puredata.info wiki! I think the /docs/ section is the appropriate place. The /dev/ section is more like a collection 'todo' lists like pd/src/notes.txt, as well as design ideas, sketches for implementations, etc. More like documentation for things that need doing rather than documentation of things that work now. Since there is so much activity around it, I think we should start an RPi section of the /docs, like /docs/raspberrypi where people can create many different pages. .hc On 01/28/2013 12:38 AM, Miller Puckette wrote: To Pd dev - I'm leading a seminar of graduate students who are trying out various things on the Pi (audio; USB; GPIO; etc) - would it be appropriate for us to start a age on the Pd Dev wiki (http://puredata.info/dev) to collect experiences? I'd be happy to try to get that going unless there's some reason it should go somewhere else. cheers Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pi page on Pd developer WIKI?
I set up a 'wiki folder' for this, so people can freely create wiki pages under this section for all sorts of things related to Pd-on-RPi. I could see people putting up their own pages to document their own setups, a intro getting started page, etc. Whatever really. http://puredata.info/docs/raspberry-pi/ .hc On 01/28/2013 02:30 PM, Andy Farnell wrote: Tis a great idea! On Sun, Jan 27, 2013 at 09:38:53PM -0800, Miller Puckette wrote: To Pd dev - I'm leading a seminar of graduate students who are trying out various things on the Pi (audio; USB; GPIO; etc) - would it be appropriate for us to start a age on the Pd Dev wiki (http://puredata.info/dev) to collect experiences? I'd be happy to try to get that going unless there's some reason it should go somewhere else. cheers Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdlab licid-amd64 (was Re: autobuild: fribidi support)
On 01/27/2013 01:31 PM, András Murányi wrote: On Sun, Jan 27, 2013 at 2:19 AM, Hans-Christoph Steiner h...@at.or.atwrote: On 01/23/2013 03:38 PM, András Murányi wrote: On Wed, Jan 23, 2013 at 12:56 AM, Hans-Christoph Steiner h...@at.or.at wrote: On 01/22/2013 05:34 PM, András Murányi wrote: [...] BTW, rsync fails here with Host key verification failed. Actually, I forgot to say, if you want to run it as a jenkins build slave, that would definitely still be useful. .hc Jenkins is behaving bad here (doesn't seem to start up at boot, then it doesn't connect to the master when started) but i'll try to discipline it. As for the autobuild script, I've done svn up, yet it fails with the following *before it still tries to rsync*. Shall we try to fix it or shall I dump it? I think we don't need the auto-build if the jenkins builds work. we can produce working Lucid packages in Launchpad. .hc Ok, I'll shut the autobuild down here but I'm afraid I'll need some help with Jenkins. It comes out that it does connect successfully, however there is an error all the time: https://macosx105-i386.pdlab.puredata.info/computer/muranyia.dyndns.org/ Any ideas what is this? András I was just setting up the Windows XP build machine as a Jenkins slave and ran into the same issue. Its because your Java install doesn't trust the CAcert.org certificate used by the jenkins master. You need to import the cacert certificate into the Java keystore, then it'll validate OK and should work. Here's how: sudo keytool -keystore /usr/lib/jvm/default-java/jre/lib/security/cacerts -storepass changeit -import -trustcacerts -v -alias cacertclass1 -file /usr/share/ca-certificates/cacert.org/cacert.org.crt Or if I messed up the paths, there is more info here: http://wiki.cacert.org/FAQ/ImportRootCert#Java .hc Thanks for the tip! I have no /usr/lib/jvm/default-java but I have all these under /usr/lib/jvm: ia32-java-6-sun/ .java-1.6.0-openjdk.jinfo ia32-java-6-sun-1.6.0.26/ java-6-openjdk/ .ia32-java-6-sun.jinfo java-6-sun/ java-1.5.0-gcj-4.4/java-6-sun-1.6.0.26/ java-1.6.0-openjdk/.java-6-sun.jinfo Trying to add the key to java-6-sun or java-6-openjdk results in: Certificate already exists in system-wide CA keystore under alias cacert_org_pem Do you still want to add it to your own keystore? [no]: Shall I choose [yes] or shall I try every other java keystore, or is there a way to find out which one is used by Jenkins? Sorry if I'm dumber than normally, I got a fever! András You could also try to download the root.crt and class3.crt from cacert.org and install those. I don't really know the answer to the particular issue. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdlab licid-amd64 (was Re: autobuild: fribidi support)
On 01/27/2013 01:31 PM, András Murányi wrote: On Sun, Jan 27, 2013 at 2:19 AM, Hans-Christoph Steiner h...@at.or.atwrote: On 01/23/2013 03:38 PM, András Murányi wrote: On Wed, Jan 23, 2013 at 12:56 AM, Hans-Christoph Steiner h...@at.or.at wrote: On 01/22/2013 05:34 PM, András Murányi wrote: [...] BTW, rsync fails here with Host key verification failed. Actually, I forgot to say, if you want to run it as a jenkins build slave, that would definitely still be useful. .hc Jenkins is behaving bad here (doesn't seem to start up at boot, then it doesn't connect to the master when started) but i'll try to discipline it. As for the autobuild script, I've done svn up, yet it fails with the following *before it still tries to rsync*. Shall we try to fix it or shall I dump it? I think we don't need the auto-build if the jenkins builds work. we can produce working Lucid packages in Launchpad. .hc Ok, I'll shut the autobuild down here but I'm afraid I'll need some help with Jenkins. It comes out that it does connect successfully, however there is an error all the time: https://macosx105-i386.pdlab.puredata.info/computer/muranyia.dyndns.org/ Any ideas what is this? András I was just setting up the Windows XP build machine as a Jenkins slave and ran into the same issue. Its because your Java install doesn't trust the CAcert.org certificate used by the jenkins master. You need to import the cacert certificate into the Java keystore, then it'll validate OK and should work. Here's how: sudo keytool -keystore /usr/lib/jvm/default-java/jre/lib/security/cacerts -storepass changeit -import -trustcacerts -v -alias cacertclass1 -file /usr/share/ca-certificates/cacert.org/cacert.org.crt Or if I messed up the paths, there is more info here: http://wiki.cacert.org/FAQ/ImportRootCert#Java .hc Thanks for the tip! I have no /usr/lib/jvm/default-java but I have all these under /usr/lib/jvm: ia32-java-6-sun/ .java-1.6.0-openjdk.jinfo ia32-java-6-sun-1.6.0.26/ java-6-openjdk/ .ia32-java-6-sun.jinfo java-6-sun/ java-1.5.0-gcj-4.4/java-6-sun-1.6.0.26/ java-1.6.0-openjdk/.java-6-sun.jinfo Trying to add the key to java-6-sun or java-6-openjdk results in: Certificate already exists in system-wide CA keystore under alias cacert_org_pem Do you still want to add it to your own keystore? [no]: Shall I choose [yes] or shall I try every other java keystore, or is there a way to find out which one is used by Jenkins? Sorry if I'm dumber than normally, I got a fever! András Wow, looks like you have every java installed. Do 'ls -l /etc/alternatives/java' to see which one you're actually using. You could also try downloading the individual files and using that command to add them: https://www.cacert.org/certs/root.crt Fingerprint SHA1: 13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33 sudo keytool -keystore /usr/lib/jvm/default-java/jre/lib/security/cacerts \ -storepass changeit -import -trustcacerts -v -alias cacertclass1 -file root.crt https://www.cacert.org/certs/class3.crt Fingerprint SHA1: AD:7C:3F:64:FC:44:39:FE:F4:E9:0B:E8:F4:7C:6C:FA:8A:AD:FD:CE sudo keytool -keystore /usr/lib/jvm/default-java/jre/lib/security/cacerts \ -storepass changeit -import -trustcacerts -v -alias cacertclass3 -file class3.crt .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdlab licid-amd64 (was Re: autobuild: fribidi support)
On 01/23/2013 03:38 PM, András Murányi wrote: On Wed, Jan 23, 2013 at 12:56 AM, Hans-Christoph Steiner h...@at.or.atwrote: On 01/22/2013 05:34 PM, András Murányi wrote: [...] BTW, rsync fails here with Host key verification failed. Actually, I forgot to say, if you want to run it as a jenkins build slave, that would definitely still be useful. .hc Jenkins is behaving bad here (doesn't seem to start up at boot, then it doesn't connect to the master when started) but i'll try to discipline it. As for the autobuild script, I've done svn up, yet it fails with the following *before it still tries to rsync*. Shall we try to fix it or shall I dump it? I think we don't need the auto-build if the jenkins builds work. we can produce working Lucid packages in Launchpad. .hc Ok, I'll shut the autobuild down here but I'm afraid I'll need some help with Jenkins. It comes out that it does connect successfully, however there is an error all the time: https://macosx105-i386.pdlab.puredata.info/computer/muranyia.dyndns.org/ Any ideas what is this? András I was just setting up the Windows XP build machine as a Jenkins slave and ran into the same issue. Its because your Java install doesn't trust the CAcert.org certificate used by the jenkins master. You need to import the cacert certificate into the Java keystore, then it'll validate OK and should work. Here's how: sudo keytool -keystore /usr/lib/jvm/default-java/jre/lib/security/cacerts -storepass changeit -import -trustcacerts -v -alias cacertclass1 -file /usr/share/ca-certificates/cacert.org/cacert.org.crt Or if I messed up the paths, there is more info here: http://wiki.cacert.org/FAQ/ImportRootCert#Java .hc signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pdlab chroots: more distros/release to build/test with
The PdLab Debian servers also host some chroots that you can use with the pddev account. I added a blurb about them on the wiki: http://puredata.info/docs/developer/PdLab Currently these are available: Debian: squeeze-i386 wheezy-i386 Ubuntu: precise-i386 precise-amd64 raring-amd64 Raspbian for RPi: raspbian-wheezy-armhf I'm running my first full Pd-extended build for Raspbian on that new chroot, I'll post it when its done tomorrow. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pdlab chroots: more distros/release to build/test with
The PdLab Debian servers also host some chroots that you can use with the pddev account. I added a blurb about them on the wiki: http://puredata.info/docs/developer/PdLab Currently these are available: Debian: squeeze-i386 wheezy-i386 Ubuntu: precise-i386 precise-amd64 raring-amd64 Raspbian for RPi: raspbian-wheezy-armhf I'm running my first full Pd-extended build for Raspbian on that new chroot, I'll post it when its done tomorrow. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] ssh access to MacOSX106-x86_64
chaos.medien.uni-weimar.de is the actually hostname of that machine and 141.54.159.89 is the IP. MacOSX106-x86_64.pdlab.puredata.info just maps to puredata.info, so that's not right. MacOSX106-X86_64 is also a lab machine at Weimar, so sometimes its not available. I can't reach it either. Try macosx105-i386.pdlab.puredata.info .hc On 01/22/2013 12:23 PM, Antoine Villeret wrote: hi all, i logged in MacOSX106-X86_64 this afternoon to build pix_opencv and my session hanged up and I get time out now : ~$ ssh pddev@141.54.159.89 ssh: connect to host 141.54.159.89 port 22: Connection timed out IP was found here : http://puredata.info/docs/developer/MacOSX106X8664 but doesn't equal the one point by MacOSX106-x86_64.pdlab.puredata.info and i can't ping this one : $ ping MacOSX106-x86_64.pdlab.puredata.info PING MacOSX106-x86_64.pdlab.puredata.info (193.170.191.182) 56(84) bytes of data. nor logging in : $ ssh pddev@MacOSX106-x86_64.pdlab.puredata.info Permission denied (publickey). where am i wrong ? do i miss something ? cheers antoine -- do it yourself http://antoine.villeret.free.fr ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdlab licid-amd64 (was Re: autobuild: fribidi support)
On 01/22/2013 05:34 PM, András Murányi wrote: [...] BTW, rsync fails here with Host key verification failed. Actually, I forgot to say, if you want to run it as a jenkins build slave, that would definitely still be useful. .hc Jenkins is behaving bad here (doesn't seem to start up at boot, then it doesn't connect to the master when started) but i'll try to discipline it. As for the autobuild script, I've done svn up, yet it fails with the following *before it still tries to rsync*. Shall we try to fix it or shall I dump it? I think we don't need the auto-build if the jenkins builds work. we can produce working Lucid packages in Launchpad. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Question about error in external
On 01/18/2013 06:33 AM, IOhannes zmölnig wrote: On 01/18/2013 10:41 AM, Thomas Mayer wrote: Hello, while I am working on PuREST JSON, I have gotten an interesting error, but only on Windows: Two of my objects do not load correctly with the message: load_object: Symbol rest_setup not found On Linux, this works without any problems, as do the other objects in Windows. What is different with [rest] and [oauth] objects? Both are using a lot on w32 you have to explictely export symbols from a dll, in order to be able to use them from another dll (e.g. pd). either with the /export linker-flag or with the __declspec(dllexport) attribute. I think MinGW handles this for you, which compiler are you using on Windows? .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Xcode and some commands
Hey Ed, Could you fix up the MacPorts HOWTO? Maybe a quick intro section on installing just enough to build Vanilla, then a follow up section on all the libs for Pd-extended? http://puredata.info/docs/developer/MacOSXMacPorts The auto-builds all use Fink, those instructions are here, for a reference: http://puredata.info/docs/developer/MacOSXFink The old reference will provide a more useful listing of packages for all of the libs needed for Pd-extended: http://puredata.info/docs/developer/AlternateMacOSXFink .hc On Jan 14, 2013, at 8:49 AM, Ed Kelly wrote: Hi Alexandros, Getting autotools and similar *nix packages: A good package manager to make these things easier is macports: http://www.macports.org/ Ed Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ - Original Message - From: IOhannes m zmoelnig zmoel...@iem.at To: pd...@iem.at; pd-dev pd-dev@iem.at Cc: Sent: Monday, 14 January 2013, 13:16 Subject: Re: [PD-ot] Xcode and some commands -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-14 12:50, Alexandros Drymonitis wrote: Hi all, hi. this is probably best targetted at pd-dev (pd-list), but anyhow... I'm trying to install some externals in Pd vanilla. Till now I've managed to install the Gem library. But now I'm trying to install zexy, but opening Pd with the '-lib zexy' flag from the command line is not enough. Trying to follow the installation guidelines of the library, I'm facing some problems. Trying to run './bootstrap.sh; ./configure; make' I get the following errors: ./bootstrap.sh: line 3: aclocal: command not found checking for gcc... no checking for cc... no checking for cl.exe... no configure: error: in `/Applications/Pd-0.44-0.app/Contents/Resources/extra/zexy-2.2.4/src': configure: error: no acceptable C compiler found in $PATH See `config.log' for more details -bash: make: command not found I have Xcode, version 4.5.2 installed in my /Applications directory (I've been told in the past I need to have developer tools in order to be able to run some commands), but that won't do the job..maybe it's quite obvious, but my knowledge on this is extremely limited. Any ideas? Obviously I have OS X. My version is 10.8.2, upgraded since I have quite an old laptop. i cannot help you in detail (some other devs might be more osx-savy, though), but i will try to give some generic hints. it seems like your system cannot find a number of needed things, namely - - a valid compiler (gcc) - - a valid make - - working autotools (e.g. aclocal) at least the former two should be installed when you have XCode properly installed. either you missed something when installing (e.g. only copied XCode app, but forgot to run the installer), or you have to add some paths to your PATH variable. try locating the make binary (e.g. `find / -name make`) and add that path to your PATH. autotools used to come with xcode, but it seems that they are not shipping it any longer (confirm [1]). you might have luck using a package-manager like fink. fgasdrm IOhannes [1] http://jsdelfino.blogspot.co.at/2012/08/autoconf-and-automake-on-mac-os-x.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlD0BRMACgkQkX2Xpv6ydvTyHwCgvDNVxboc0fWpO8UfWVCtQMoj +pcAoNR8SCx4CEerQL/EAmUKbcyWkAgQ =BZPs -END PGP SIGNATURE- ___ Pd-ot mailing list pd...@iem.at http://lists.puredata.info/listinfo/pd-ot ___ Pd-ot mailing list pd...@iem.at http://lists.puredata.info/listinfo/pd-ot ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] autobuild: fribidi support
On 01/10/2013 10:48 AM, András Murányi wrote: On Wed, Jan 9, 2013 at 3:11 PM, Hans-Christoph Steiner h...@at.or.atwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 libfribidi-dev is now installed on all of the Debian-deriv auto-build machines, and all chroots except oneiric-* since those will be deleted soon. Does Gem 0.93.4 in Pd-extended have support for this lib? .hc Well, today's Pd-extended in lucid-amd64 built alrite without it, but I've installed it now anyway. BTW, rsync fails here with Host key verification failed. The new auto-build system no longer uses rsync since that server went away. It fetches everything from svn. So run 'svn up' in ~/auto-build/pd-extended/scripts to get the latest scripts. Now that I have finally made Pd-extended into a proper Debian package, we can now build for Lucid on Launchpad: https://launchpad.net/~eighthave/+archive/pd-extended/+packages So it might be time to retire your build server. One thing that would be very useful is to test those Lucid packages and make sure they're working well. I only have my ubuntu/precise laptops around to test with. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] autobuild: fribidi support
On 01/10/2013 10:48 AM, András Murányi wrote: On Wed, Jan 9, 2013 at 3:11 PM, Hans-Christoph Steiner h...@at.or.atwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 libfribidi-dev is now installed on all of the Debian-deriv auto-build machines, and all chroots except oneiric-* since those will be deleted soon. Does Gem 0.93.4 in Pd-extended have support for this lib? .hc Well, today's Pd-extended in lucid-amd64 built alrite without it, but I've installed it now anyway. BTW, rsync fails here with Host key verification failed. Actually, I forgot to say, if you want to run it as a jenkins build slave, that would definitely still be useful. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jenkins: macosx105-powerpc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Greg Pond runs it. He said the machine died and he left town for a bit. He told me he was planning on trying to get it going again. But if anyone else has a PowerPC machine that could take its place, it sounds like the hardware might be dying on the old one. .hc On 01/09/2013 07:43 AM, IOhannes m zmoelnig wrote: quick question: is the osx10.5-ppc machine gone for good, or is it likely to return? the machine seems to be online, but i cannot login to it any more (Permission denied (publickey)). also jenkins hasn't built on that machine for a while now. fgmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJQ7W69AAoJEJ8P5Yc3S76BDe4P/Rj3cICmmP0MEoAeMHsqOqfb biIYpx8msXhgyU5VccZSRlCYlte1ScST32xcfIFgyVSNufrx7F1JNLfNx+w7J2L8 W/RiDAK+1zkzmKecgkwOduN+VCJeu8APfrTeYxog1jhPyxuMz/nfy+LvFsx6Hezu S7uqfxIkNeGhEGH3V6yDoD3ocNGxvMDQUm3GpD8T1/0yVjoNv1vVczJHDL3Uw0u8 +Akb7mczPNuESirEKg57kc9VzjzYEYcfANAB1gMpAU6hPqoL7Kl583iQ1eWqFIVT +J/+44Kd+YCLi3un+kjPz/zg2oQReyVRg4uQ7VN8pXqJcL7GrEjhpVI1Hte5J9QX 52S6/enGD/Nef8MnRahsbdeJLYbE8/cpbSSml6IRZAPP9U54N8GYJTxSDYwBUxM8 1yknxI3h60m3uKK9MjtxL+JSk7oT787DmvVWh7jZnf1K1kJjTDvQT1mP39iGmUH5 LUrvBkm7vqX4wiG2InfdW0uwXG9oqyLy5VxHx486bYL1p/jUqe7BZIh7DZ0LfTmi 1Gz7wnONSin0TfITJO9eGNEvFbCCxvGfpzyTVFV7iHUTKLm6Y6I3QMJrwi8673Wa KJESBWn0fHOUXEvAVJOIqWpBiHiqwuafU3v49N3/JOlIjb3sBkqax/oCImOOs2bL 7ycDP9GZ1ChqgkwdMzw5 =WtFe -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] autobuild: fribidi support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 libfribidi-dev is now installed on all of the Debian-deriv auto-build machines, and all chroots except oneiric-* since those will be deleted soon. Does Gem 0.93.4 in Pd-extended have support for this lib? .hc On 01/09/2013 08:15 AM, IOhannes m zmoelnig wrote: On 2013-01-09 14:15, IOhannes m zmoelnig wrote: hi. recently i have added bidirectional text rendering support to Gem (this basically means that arabic and hebrew strings will be correctly rendered right-to-left). however, this depends on the libfribidi library [1]. since there exist packages for debian and fink (though those are a bit outdated), would it be possible to install them on the autobuild servers? fgasdmkr IOhannes [1] http://www.fribidi.org/ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJQ7XqdAAoJEJ8P5Yc3S76BptIP/1VUXImh9zSLg7LIK+KhXAJR Ie1biM9Qr1vTWikffagAgWypd9dnrtaxt73GjeR8R8pDn7qk1g7lpCiPIeq3tMw8 BZXUr5NeblDKXJ+v/RFe0fQq8SLGwHoa4kL8xJxIFgYV52vWX4aH6mmKat52ac8D +YrzS1oVgCeK66JICkfQ+urXohKM4ULIcjNeabfR7M4ryCfEXBMionTCwkJHV8m/ 1ApKQRBM45++e9Jq5G4i+lLboOpDbm1k5Rq0BbkJcU/5q5VtXZze1JnO/9/tP30F TzOtp1UGKguiodO/kWgzVGVIODpfyOO9/sDIMRA2q9CAq/BibHz0I1KXZbrw10WQ 1fcnY63GwUDtSi8U7PmP1glqn23Fi76M8G0vdJ45LRYjt4Y3AiMQuT+EQx4NtMVW p8q1AkNnBsFVMSe1rFmR0M23V9Xz4ALY2G1Xjj9RYGZZbDzp7bekemLYO4HQnFrd MzUgUMuxUYURGmORVLy+7UIZjqLaIKRkr8cqh++2v6oyreT/xzNw+DN9yN8AWZGE 1kDZq0zmNQQDWMq+Vocny+qzYTiWCHOFTi+4/O7ceh7CSDxjQviUSf91yFcvXbnO muXjdz3r1JTZFgxZxHfIBdR8hrX0438U8JQXCdV82nP2KqJhVfnc6wr4pnuUynqA lwSAHbQjt7kVN/MBoBmN =v9eY -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pdlab package updates
On IOhannes' request, I've added some new packages to the pdlab machines to support new Gem features: on all Debian-derivative: libfribidi-dev libvlc-dev On the Intel Macs: fribidi-dev /Applications/VLC.app (which includes headers and libs) .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] stackoverflow tag
Anyone on Stack Overflow with more than 1500 reputation? If so, please create a puredata or pd tag, you need at least that many points to be allowed to do so. http://stackoverflow.com/privileges/create-tags The question is, I guess, should the official tag be 'puredata' so we can beat IBM to the punch, or 'pd'. I think 'puredata' is clearer. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] scale and speedlim
I'm CC'ing pd-dev since others may be interested in the answer as well. On Jan 7, 2013, at 2:36 PM, Olivier Baudry wrote: Dear all I try to search source code to speedlim and scale object in puredata with this command find ~/pd-0.43-4/ -type f -print0 | xargs -0 grep 'speedlim' macbook-pro-de-olivier:~ olivierbaudry$ macbook-pro-de-olivier:~ olivierbaudry$ find ~/pd-0.43-4/ -type f -print0 | xargs -0 grep 'scale' /Users/olivierbaudry/pd-0.43-4//src/g_vumeter.c: class_addmethod(vu_class, (t_method)vu_scale, gensym(scale), A_DEFFLOAT, 0); macbook-pro-de-olivier:~ olivierbaudry$ I think the objects you want are both externals, so you'd run that same command on the complete Pd-extended source, or in SVN in trunk/externals I think both are in maxlib. You can also get help on them, then look at the title of the help patch window. In Mac OS X, you can Cmd-click on the filename i.e. speedlim-help.pd and then you'll see the full path: inline: Screen shot 2013-01-07 at 5.47.48 PM.png___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] updates to search_plugin for translation support
On Dec 22, 2012, at 9:34 PM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev List pd-dev@iem.at Sent: Saturday, December 22, 2012 8:00 PM Subject: Re: [PD-dev] updates to search_plugin for translation support On Dec 22, 2012, at 7:47 PM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-dev List pd-dev@iem.at Cc: Sent: Friday, December 21, 2012 10:30 PM Subject: [PD-dev] updates to search_plugin for translation support Hey Jonathan, I just committed my updates to your search_plugin, here's what I did: * renamed Browser2.0 to Search * renamed Keyword Search title to Search by Tag. The keyword part didn't seem to make sense once doing the translation, since the keywords won't be translated, or they won't work. So it seem to me they are really more tags than keywords. That will cause confusion. The pd META subpatch consists of various comments with the form TAG value1 value2 etc.. One of those tags happens to be KEYWORDS. All the blue links listed under the heading Keyword Search are possible values that I've used after the tag KEYWORDS in help patches. Therefore, it is a Keyword Search-- a search for values from a specific type of tag named KEYWORDS-- and not a Search by Tag, which implies values matched from various tags like KEYWORDS, DESCRIPTION, OUTLET_1, etc. The fact that you can't translate the keywords is simply a limitation of pd's implementation which has no way to sensibly translate content inside patches. (At least none that I know of.) I think that the PDDP KEYWORDS are really functionally like tags in the blog/etc. sense, like in this sense: http://en.wikipedia.org/wiki/Tag_(metadata) I can't think of a common usage for the term 'keyword' for describing this, though its a synonym. So I wanted try to use the most common language possible. As far as pd META, I'm pretty sure KEYWORDS was there in a template already. If you want to use common language go ahead and write a script to replace KEYWORDS inside any [pd META] for the entire svn, plus change the relevant part of the gui-plugin. I don't think they're used anywhere else ATM. Its tempting to rename KEYWORDS to TAGS... but with such a big change, I'd want to be extra sure. We might just have to live with it. But yes, I agree, calling it tags one place and keywords another will cause confusion. The term KEYWORDS isn't wrong, just much less common. Maybe it could incorporate both terms: Search by Keyword Tag See my commit. seems ok, I'm happy to leave it at that. One thing I'm struggling with in my mind is the keywords/tags are in English. So if they are translated in the listing in the front page, there will be confusion when someone tries to type in the keyword in their native language to search by, it won't work. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] no sound from bsaylor/svf~ and cyclone/svf~
Turns out adding -fno-strict-aliasing after -ftree-vectorize does nothing, so the no sound part is indeed caused by bsaylor/svf~ being compiled with -fstrict-aliasing. I get the right help patch in all cases I could think of using Pd-extended 0.43.4 2012-12-19, see attached: svf-helps.pd Description: Binary data .hc On Dec 21, 2012, at 4:53 PM, katja wrote: Have to eat my words. Nothing wrong with cyclone/svf~, it's just that Pd-E would erroneously load the help patch of bsaylor/svf~ after a click on cyclone/svf~ in the help browser (after bsaylor/svf~ was loaded once). So the problem is with bsaylor/svf~, that's probably an easy fix. What about the help browser? It loads the wrong help patch because of a namespace clash. Will Pd never reload an external with same symbol but different path? Katja On Fri, Dec 21, 2012 at 10:30 PM, katja katjavet...@gmail.com wrote: So I was going to replace type punning flush-to-zero in bsaylor/svf~ with something else, but first wanted to check how it behaves in Pd-E 0.42 and in latest 0.43 autobuild. As it happens, it gives no output sound at all in latest autobuild. It's compiled with fno-strict-aliasing. By coincidence it occurred to me to check cyclone /svf~. No sound either! In dutch we say 'alsof de duvel ermee speelt'. The issues may be unrelated. cyclone/svf~ has four inlets and one outlet now, while it used to have three inlets and four outlets. This is with Pd-0.43.4-extended-20121221.app for OSX 10.5 i386 (but very unlikely that cyclone/svf~ has different number of outlets on other platforms). Weather forecasts are unfavorable for this weekend and I may spend some time on these issues. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Patches-3597233 ] Win32: use binary open mode by default everywhere
On Dec 21, 2012, at 5:34 PM, Claude Heiland-Allen wrote: On 21/12/12 22:27, SourceForge.net wrote: Patches item #3597233, was opened at 2012-12-18 08:43 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=3597233group_id=55736 Summary: Win32: use binary open mode by default everywhere Initial Comment: This patch enables binary open mode on Win32 everywhere, thereby ignoring the special Win32 text translation mode. This makes the Win32 API more like the POSIX API, which is used by every other platform Pd supports. But it seems to break somethings, like the loading of some soundfiles. Attached is an example patch for the failure. Guessing here: a file saved wrongly in text mode (by old Pd, perhaps) might be corrupted in a way that text mode old Pd can read fine, but makes binary mode software (like new Pd, perhaps) fails. (sorry for not checking the example patch or using sf.net tracker) Unfortuantely, it seems more insidious than that since it only affects MinGW builds... I was testing using the classic voice.wav, which has been in continuous service to Pd users bringing soft and relaxing sounds to their headphones. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] no sound from bsaylor/svf~ and cyclone/svf~
On Dec 21, 2012, at 6:09 PM, katja wrote: On Fri, Dec 21, 2012 at 11:07 PM, Hans-Christoph Steiner h...@at.or.at wrote: I get the right help patch in all cases I could think of using Pd-extended 0.43.4 2012-12-19, see attached: Ah I see. I also get the right help patch but with the wrong svf~! Try this: start Pd, first load bsaylor/svf~, then the help patch from cyclone/svf~. You get cyclone's patch but with bsaylors' svf~ (with four inlets and one outlet), no? And the other way round is also true. This is what confused me. But probably this makes sense (though it is not the desired behaviour in all cases): once a symbol is loaded, Pd will not reload it. Pd does not remember the path where a symbol was loaded from, or does it? Yeah, this is a bummer. This the big problem with the namespaces as they are now. If a binary object is loaded like [bsaylor/svf~], still claims the [svf~] name. So in this case, [cyclone/svf~] comes first in the search path, so its normally [svf~]. But if [svf~] or [cyclone/svf~] has never been loaded, then the 'svf~' name is unclaimed. Then when [bsaylor/svf~] is loaded, it claims [svf~]. Sad but true. So the help patch you get is a good clue to which one actually claimed [svf~]. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] updates to search_plugin for translation support
Hey Jonathan,
I just committed my updates to your search_plugin, here's what I did:
* renamed Browser2.0 to Search
* renamed Keyword Search title to Search by Tag. The keyword part didn't
seem to make sense once doing the translation, since the keywords won't be
translated, or they won't work. So it seem to me they are really more tags
than keywords.
* rearranged some code to get [_ ] everywhere, some lists needed more than
trivial rearrangedments (i.e. [list foo bar] instead of {foo bar})
Hope these all work for you.
.hc
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] help patch bug reports
- Original Message - From: IOhannes m zmoelnig zmoel...@iem.at To: pd-dev@iem.at Cc: Sent: Thursday, December 20, 2012 10:51 AM Subject: Re: [PD-dev] help patch bug reports -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-12-20 15:27, Hans-Christoph Steiner wrote: Hey Jonathan, I'm guessing that you're the one filing all the bug reports about help patches. I'm wondering what your goal is with filing them. It seems that you're also committing stuff to the same help patches? of course i cannot speak for jonathan, but it seems like the help-patch edits remove the TODO found in [pd META] - as these TODOs are now tracked in the bugreport tickets: moved doc errors from META subpatch to svn tracker actually i think having these tickets in the sf-tracker is a good idea. You are correct. Most of the commits were simply as stated. Some of the META comments didn't apply anymore so I removed those without adding to the tracker. Everything added to the tracker should be current help patch bugs which may be: * missing example patch * missing description of the object * failing to explain what an xlet does * broken connections * some or all of the above Doing this makes the search results with the gui-plugin prettier and centralizes all bugs to the tracker. -Jonathan That makes sense, just wondering what the idea was. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Win32 - unicode support for files, with public API for externals
On Dec 18, 2012, at 4:56 AM, IOhannes m zmölnig wrote:
On 12/18/2012 04:40, Hans-Christoph Steiner wrote:
I think this approach works.
thanks
The patch you provided seems totally untested, as in not even compiled on
GNU/Linux or Mac OS X. It includes the _close() function in sys_close()
which only works on Win32 and it gives this warning when building on Mac OS
X:
thanks for the compliments :-)
i can assure you that the code is tested as in compiled without warning on
gcc-4.7.2 on a debian/gnu linux (wheezy/sid) system and has been
field-tested and shown to be able to load externals that the old code has not
been able to load.
however, you are of course right that the use of _close() is indeed an
oversight, which only did not trigger a problem so far, as sys_close() is
nowhere used yet.
s_path.c: In function ‘sys_open’:
s_path.c:450: warning: ‘mode_t’ is promoted to ‘int’ when passed through
‘...’
s_path.c:450: warning: (so you should pass ‘int’ not ‘mode_t’ to ‘va_arg’)
s_path.c:450: note: if this code is reached, the program will abort
the patch includes some comments pointing to an online discussion of the
problem. to summarize: using mode_t in va_list will always trigger some
problems. either we accept the warning (the code will never be reached, since
a runtime-test will use a va_arg(..., int) instead) or we move the test to
configure (autoconf).
since i am the only one who seems to like autoconf, i decided for the less
invasive solution.
I think it makes sense to restore sys_close() for backwards ABI compatibility.
Microsoft says that the POSIX close() was deprecated in 2005, and to use their
ISO C++ _close() instead [1][2], so the new sys_close() should look like this:
/* close a previously opened file
this is needed on platforms where you cannot open/close resources
across dll-boundaries */
int sys_close(int fd)
{
#ifdef _WIN32
return _close(fd);
#else
return close(fd);
#endif
}
And leave sys_open, sys_fopen, and sys_fclose as macros in the header. This
implementation of sys_open and warning are much more complicated. And tho
normally I think its good to avoid #ifdefs in headers, in this case I think it
actually communicates why we have these sys_open/sys_close sys_fopen/sys_fclose
in the first place: Win32 lacks good POSIX API support, everything else works
as is.
Attached is my patch that I think should replace
2b8a4c13904f6b8bef3a8ae52b5258a131eb6a19 provide sys_close(),... on all
platforms
.hc
0001-restore-sys_close-as-a-function-on-all-platforms-to-.patch
Description: Binary data
[1] http://msdn.microsoft.com/en-US/library/ms235443(v=vs.80).aspx
[2] http://msdn.microsoft.com/en-US/library/5fzwd5ss(v=vs.80).aspx
(I attached the patch for reference, it doesn't seem to be up on the patch
tracker any more.)
it seems that the patch has moved to the bug tracker.
i moved it back to patches [1].
fgmasdr
IOhannes
[1]
https://sourceforge.net/tracker/?func=detailaid=3596865group_id=55736atid=478070
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Win32 - unicode support for files, with public API for externals
Windows is most definitely not POSIX compliant. If it was, we wouldn't be
having this discussion since the Win32 open() would just work. It has lots
POSIX compliant things, but is also missing many key ones. For example, WIN32
does not define any of the POSIX open() flags (O_CREAT, O_TRUNC, etc.) but
instead uses _O_CREAT, _O_TRUNC, etc. The WIN32 open() permissions flags its
uses work differently than POSIX.
Microsoft marked close() as deprecated in 2005. It seems worthwhile to heed
that.
The other issue with this patch is the giant warning it gives on Mac OS X:
s_path.c: In function ‘sys_open’:
s_path.c:456: warning: ‘mode_t’ is promoted to ‘int’ when passed through ‘...’
s_path.c:456: warning: (so you should pass ‘int’ not ‘mode_t’ to ‘va_arg’)
s_path.c:456: note: if this code is reached, the program will abort
.hc
On Dec 18, 2012, at 12:28 PM, Miller Puckette wrote:
... but if POSIX has a close() I think there's no issue here - MSW is POSIX
compliant, they say, and hence they're committeed to maintaining close().
So I think it's fine just to use close() and not have a sys_close() at
all (or if someone is actually using sys_close() we choud just:
int sys_close(int fd)
{
return close(fd);
}
:)
M
On Tue, Dec 18, 2012 at 12:22:29PM -0500, Hans-Christoph Steiner wrote:
On Dec 18, 2012, at 4:56 AM, IOhannes m zmölnig wrote:
On 12/18/2012 04:40, Hans-Christoph Steiner wrote:
I think this approach works.
thanks
The patch you provided seems totally untested, as in not even compiled on
GNU/Linux or Mac OS X. It includes the _close() function in sys_close()
which only works on Win32 and it gives this warning when building on Mac
OS X:
thanks for the compliments :-)
i can assure you that the code is tested as in compiled without warning on
gcc-4.7.2 on a debian/gnu linux (wheezy/sid) system and has been
field-tested and shown to be able to load externals that the old code has
not been able to load.
however, you are of course right that the use of _close() is indeed an
oversight, which only did not trigger a problem so far, as sys_close() is
nowhere used yet.
s_path.c: In function ‘sys_open’:
s_path.c:450: warning: ‘mode_t’ is promoted to ‘int’ when passed through
‘...’
s_path.c:450: warning: (so you should pass ‘int’ not ‘mode_t’ to ‘va_arg’)
s_path.c:450: note: if this code is reached, the program will abort
the patch includes some comments pointing to an online discussion of the
problem. to summarize: using mode_t in va_list will always trigger some
problems. either we accept the warning (the code will never be reached,
since a runtime-test will use a va_arg(..., int) instead) or we move the
test to configure (autoconf).
since i am the only one who seems to like autoconf, i decided for the less
invasive solution.
I think it makes sense to restore sys_close() for backwards ABI
compatibility. Microsoft says that the POSIX close() was deprecated in 2005,
and to use their ISO C++ _close() instead [1][2], so the new sys_close()
should look like this:
/* close a previously opened file
this is needed on platforms where you cannot open/close resources
across dll-boundaries */
int sys_close(int fd)
{
#ifdef _WIN32
return _close(fd);
#else
return close(fd);
#endif
}
And leave sys_open, sys_fopen, and sys_fclose as macros in the header. This
implementation of sys_open and warning are much more complicated. And tho
normally I think its good to avoid #ifdefs in headers, in this case I think
it actually communicates why we have these sys_open/sys_close
sys_fopen/sys_fclose in the first place: Win32 lacks good POSIX API
support, everything else works as is.
Attached is my patch that I think should replace
2b8a4c13904f6b8bef3a8ae52b5258a131eb6a19 provide sys_close(),... on all
platforms
.hc
[1] http://msdn.microsoft.com/en-US/library/ms235443(v=vs.80).aspx
[2] http://msdn.microsoft.com/en-US/library/5fzwd5ss(v=vs.80).aspx
(I attached the patch for reference, it doesn't seem to be up on the patch
tracker any more.)
it seems that the patch has moved to the bug tracker.
i moved it back to patches [1].
fgmasdr
IOhannes
[1]
https://sourceforge.net/tracker/?func=detailaid=3596865group_id=55736atid=478070
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
[PD-dev] tclpd vs unicode on GNU/Linux
Hey Federico, I just finished getting full unicode support on Pd-extended 0.43.4 and ran into a bizarre problem. It turns out that when tclpd is loaded by default, Pd freaks out on some Portugeuse text like modulação. Replace the ç and ã with c and a, and the problem goes away. Or stop loading tclpd at startup and the problem goes away. I attached the patch in question. This only happens on GNU/Linux, Windows and Mac OS X are unaffected. I tried looking around the code, and using strace to follow the function calls, but I didn't see anything. I'd like to be able to include tclpd by default in Pd-extended, but this is a show stopper. .hc #N canvas 189 80 742 698 10; #N canvas 220 274 450 300 hacks 0; #X obj 146 45 vanilla/tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 141 81 vanilla/dac~; #X obj 160 147 vanilla/cnv 15 100 60 empty empty empty 20 12 0 14 -233017 -66577 0; #X obj 300 68 vanilla/hsl 128 15 0 127 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 0 1; #X obj 271 111 vanilla/nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -8 0 10 -262144 -1 -1 0 256; #X restore 415 29 pd hacks; #X obj 500 537 vanilla/cnv 15 200 140 empty empty empty 20 12 0 14 -204800 -66577 0; #X obj 499 31 vanilla/cnv 15 198 138 empty empty empty 20 12 0 14 -261682 -66577 0; #X obj 501 200 vanilla/cnv 15 198 138 empty empty empty 20 12 0 14 -204786 -66577 0; #N canvas 0 22 450 300 (subpatch) 0; #X array phasor1 441 float 1; #A 0 0.765351 0.769886 0.774421 0.778956 0.783492 0.788027 0.792562 0.797097 0.801632 0.806167 0.810702 0.815238 0.819773 0.824308 0.828843 0.833378 0.837913 0.842448 0.846984 0.851519 0.856054 0.860589 0.865124 0.869659 0.874195 0.87873 0.883265 0.8878 0.892335 0.89687 0.901405 0.905941 0.910476 0.915011 0.919546 0.924081 0.928616 0.933151 0.937687 0.94 0.946757 0.951292 0.955827 0.960362 0.964897 0.969433 0.973968 0.978503 0.983038 0.987573 0.992108 0.996643 0.00117864 0.00571378 0.0102489 0.0147841 0.0193192 0.0238544 0.0283895 0.0329247 0.0374598 0.041995 0.0465301 0.0510653 0.0556004 0.0601356 0.0646707 0.0692059 0.073741 0.0782761 0.0828113 0.0873464 0.0918816 0.0964167 0.100952 0.105487 0.110022 0.114557 0.119092 0.123628 0.128163 0.132698 0.137233 0.141768 0.146303 0.150838 0.155374 0.159909 0.16 0.168979 0.173514 0.178049 0.182585 0.18712 0.191655 0.19619 0.200725 0.20526 0.209795 0.214331 0.218866 0.223401 0.227936 0.232471 0.237006 0.241541 0.246077 0.250612 0.255147 0.259682 0.264217 0.268752 0.273287 0.277823 0.282358 0.286893 0.291428 0.295963 0.300498 0.305034 0.309569 0.314104 0.318639 0.323174 0.327709 0.332244 0.33678 0.341315 0.34585 0.350385 0.35492 0.359455 0.36399 0.368526 0.373061 0.377596 0.382131 0.38 0.391201 0.395736 0.400272 0.404807 0.409342 0.413877 0.418412 0.422947 0.427482 0.432018 0.436553 0.441088 0.445623 0.450158 0.454693 0.459229 0.463764 0.468299 0.472834 0.477369 0.481904 0.486439 0.490975 0.49551 0.500045 0.50458 0.509115 0.51365 0.518185 0.522721 0.527256 0.531791 0.536326 0.540861 0.545396 0.549931 0.554467 0.559002 0.563537 0.568072 0.572607 0.577142 0.581677 0.586213 0.590748 0.595283 0.599818 0.604353 0.60 0.613424 0.617959 0.622494 0.627029 0.631564 0.636099 0.640634 0.64517 0.649705 0.65424 0.658775 0.66331 0.667845 0.67238 0.676916 0.681451 0.685986 0.690521 0.695056 0.699591 0.704126 0.708662 0.713197 0.717732 0.722267 0.726802 0.731337 0.735873 0.740408 0.744943 0.749478 0.754013 0.758548 0.763083 0.767619 0.772154 0.776689 0.781224 0.785759 0.790294 0.794829 0.799365 0.8039 0.808435 0.81297 0.817505 0.82204 0.826575 0.83 0.835646 0.840181 0.844716 0.849251 0.853786 0.858321 0.862857 0.867392 0.871927 0.876462 0.880997 0.885532 0.890068 0.894603 0.899138 0.903673 0.908208 0.912743 0.917278 0.921814 0.926349 0.930884 0.935419 0.939954 0.944489 0.949024 0.95356 0.958095 0.96263 0.967165 0.9717 0.976235 0.98077 0.985306 0.989841 0.994376 0.998911 0.00344622 0.00798137 0.0125165 0.0170517 0.0215868 0.026122 0.0306571 0.0351923 0.0397274 0.0442626 0.0487977 0.0533328 0.057868 0.0624031 0.0669383 0.0714734 0.0760086 0.0805437 0.0850789 0.089614 0.0941492 0.0986843 0.103219 0.107755 0.11229 0.116825 0.12136 0.125895 0.13043 0.134965 0.139501 0.144036 0.148571 0.153106 0.157641 0.162176 0.166712 0.171247 0.175782 0.180317 0.184852 0.189387 0.193922 0.198458 0.202993 0.207528 0.212063 0.216598 0.221133 0.225668 0.230204 0.234739 0.239274 0.243809 0.248344 0.252879 0.257414 0.26195 0.266485 0.27102 0.27 0.28009 0.284625 0.289161 0.293696 0.298231 0.302766 0.307301 0.311836 0.316371 0.320907 0.325442 0.329977 0.334512 0.339047 0.343582 0.348117 0.352653 0.357188 0.361723 0.366258 0.370793 0.375328 0.379863 0.384399 0.388934 0.393469 0.398004 0.402539 0.407074 0.41161 0.416145 0.42068 0.425215 0.42975 0.434285 0.43882 0.443356 0.447891 0.452426 0.456961 0.461496 0.466031 0.470566 0.475102 0.479637 0.484172 0.488707 0.493242 0.49 0.502312 0.506848 0.511383 0.515918 0.520453 0.524988 0.529523 0.534058 0.538594 0.543129
Re: [PD-dev] Win32 - unicode support for files, with public API for externals
On Dec 17, 2012, at 6:05 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-12-17 10:55, IOhannes m zmoelnig wrote: this makes packaging externals for e.g. Debian a nightmare, as it basically should trigger a .so-name change, but since we are linking against the application instead of an ordinary library, all the tools that would detect such an incompatibility will fail. this is not only theoretical, but already happened: the Gem binary as currently packaged in Debian cannot be loaded anymore with the git/master version of puredata. so please revert the #define sys_close close stanzas. instead i would ask you to provide sys_open() (and friends) implementations in s_path, even for platforms where they are mere wrappers around the system functions. i created a patch on sourceforge that implements sys_f?(open,close) on all platforms and thus re-establishes binary compatibility. the new functions are simply wrappers around the system open/close functions. the open wrappers also use sys_bashfilename (like the w32 version), which should be quite a noop on non-w32 platforms for now. see: https://sourceforge.net/tracker/?group_id=55736atid=478072 I think this approach works. The patch you provided seems totally untested, as in not even compiled on GNU/Linux or Mac OS X. It includes the _close() function in sys_close() which only works on Win32 and it gives this warning when building on Mac OS X: s_path.c: In function ‘sys_open’: s_path.c:450: warning: ‘mode_t’ is promoted to ‘int’ when passed through ‘...’ s_path.c:450: warning: (so you should pass ‘int’ not ‘mode_t’ to ‘va_arg’) s_path.c:450: note: if this code is reached, the program will abort (I attached the patch for reference, it doesn't seem to be up on the patch tracker any more.) .hc 0001-provide-sys_close-.-on-all-platforms.patch Description: Binary data ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [GEM-dev] pix_opencv
I think the best way to make it easy to find, download and install is to make binaries structured as libdirs and post them on puredata.info/downloads. I think with a little work that we can make a Gem external template based on the Library Template. I've done it before quick and dirty, that's not hard. .hc On Dec 12, 2012, at 11:46 AM, Antoine Villeret wrote: hello, i realize that pix_opencv is not include anywhere and people have to search it in the SVN and to built it themselves i'm wondering how we can help them to use this library i think it's a bit difficult to rewrite it's build system to fit the template because of the dependencies on Gem and OpenCV but could it possible to include this library in Gem ? in the extras ? like pix_fiducial and others ? what do you think about that ? + a -- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter ___ GEM-dev mailing list gem-...@iem.at http://lists.puredata.info/listinfo/gem-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] autotools on Mac OS X WAS: Build failed in Jenkins: pure-data » macosx106 #164
On Dec 11, 2012, at 3:35 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-12-10 22:17, Hans-Christoph Steiner wrote: I'm CC'ing pd-dev since this is good to have in the public and on the record. yes, definitely. thanks. i'm moving it from pd-list to pd-ev though. I think the problem was that Fink's 'autoconf' was installed but not Fink's 'automake-1.10'. So we need to decide to either go full native or full Fink for the autotools. The minimum build env I support is 10.5, so that means: i think this explains the problem and suggests the correct solution. If things need newer versions than that, then I say we just use all of the Fink packages. Then we could have: personally i think it is a good idea to have the build farm provide both native and fink environments. for PdX, fink is probably the way to go, but for single externals it could be interesting to build it on the native platform as well. Ok, so they all have these installed: autoconf2.6 2.69 automake1.111.11.6 libtool22.4.2 .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] separate the audio-backends
On Oct 31, 2012, at 10:36 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-10-31 15:11, Hans-Christoph Steiner wrote: What about taking it in this direction fully and making it possible to encapsulate the entire implementation for a given audio API in a single file? Then having it so s_audio.c is never modified. in theory it is like that... in practice it's almost like that: the entire implementation of a given backend is contained within a single file. however, we still have references of the built-in audio-APIs in s_audio.c. why? well the target platform is Pd-vanilla. i assume that it will take some time util Pd-vanilla itself will make all the default audio-backends as loadable modules. personally i would prefer it that way, but Pd has a history of keeping a number of functionality built-in; e.g. most objects could/should be loaded a runtime rather than being statically linked into the Pd binary ... see your attempts with the vanilla library) so until then all audio-apis that come with Pd will continue to be built-in. now all audio-apis have to register themselves, similar to how each objectclass has to register itself. if you check the code for how e.g. metro gets added, you'll see that the relevant code is called in metro_setup(), which in turn gets called by x_time_setup() which in turn gets called by conf_init(), pd_init(), sys_main(), main(). the same holds now true for audioapi_oss() (which registers the OSS API), getting called by audioapi_register(), sys_set_audio_api(),... i could have moved the #ifdef USEAPI_OSS from s_audio.c to s_audio_oss.c. but given that s_audio_oss.c is only compiled with HAVE_OSS is set, it seemed easier to do it that way. Would it be possible to provide an alternative implementation for the same API as a built-in using this? So for example, an alternate Jack or ALSA implementation in a loadable module? .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] separate the audio-backends
On Dec 9, 2012, at 1:19 PM, IOhannes m zmölnig wrote: On 12/09/2012 17:31, Hans-Christoph Steiner wrote: Would it be possible to provide an alternative implementation for the same API as a built-in using this? So for example, an alternate Jack or ALSA implementation in a loadable module? (iirc) the current implementation allows us to overwrite/override a given backend by simply registering another backend of the same name. so es, you could provide a bug-fixed jack-implementation without touching the pd-code. and of course, you could provide 3 different jack implementations (e.g. with different features sets) at the same time, by just using different API-names. This sounds excellent. I'd like to include this in Pd-extended 0.44. Did you have a chance to look at the issue I reported in this thread where portaudio doesn't work on OSX? .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] UTF-8 problems on Windows
There is a problem on Windows that has me stumped. If you open a file with a non-ASCII character in the name or path using pd -open it works fine. If you open it using File - Open, then it freezes Pd. If you print the filename to the Pd window right before its sent to Pd, it prints properly: C:/Documents and Settings/pd/Desktop/comma,coüüümma.pd But running pd.com -d 3 shows: pd open comma\,co├╝├╝├╝mma.pd C:/Documents\ and\ Settings/pd/Desktop; open: C:/Documents and Settings/pd/Desktop/comma,co├╝├╝├╝mma.pd: No such file or directory comma,co├╝├╝├╝mma.pd: No such file or directory So somewhere in the network receiving the unicode is going wrong, but only on Windows. Its a bad bug for anyone who uses non-ASCII letters on Windows. Any ideas? .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding a built-in [change] object to the built-in GUI objects
That's how I ended up implementing it, based on Jonathan's suggestion:
http://sourceforge.net/tracker/?func=detailaid=3591986group_id=55736atid=478072
.hc
On Dec 4, 2012, at 12:06 PM, Miller Puckette wrote:
I'd suggest cacheing the pixel value, not the value value. It's an easy
fix and I can go through and do it while I'm waiting for other bugs to
surface after trying to make all the 0.44-critical changes on the pile.
(these are resolving my having broken the new build system in my
impoartation
of portaudio, and also finally acting on the hip~ and inlet~ bugs.)
cheers
Miller
On Fri, Nov 30, 2012 at 11:20:53PM -0500, Hans-Christoph Steiner wrote:
Lots of patches use the built-in GUI objects for displays, and often a fast
stream of events is hooked straight up to the GUI object, causing the GUI
object to send many pointless updates, like draw commands when the number
hasn't changed, or multiple draw commands per screen refresh cycle.
I propose to only send the GUI update commands when the relevant value has
changed. I think this should apply to both the main element, like the
slider knob, and the label for that GUI object, since that's often used as a
display. The code change is pretty simple, but I was wondering if people
thought there could be any problems caused by this
Here is the needed change, for example, for the hslider knob:
index b352fb9..88681fc 100644
--- a/src/g_all_guis.h
+++ b/src/g_all_guis.h
@@ -185,6 +185,7 @@ typedef struct _hslider
t_iemgui x_gui;
int x_pos;
int x_val;
+int x_prev_val;
int x_center;
int x_thick;
int x_lin0_log1;
index 470771a..e1a3c83 100644
--- a/src/g_hslider.c
+++ b/src/g_hslider.c
@@ -33,7 +33,7 @@ static t_class *hslider_class;
static void hslider_draw_update(t_gobj *client, t_glist *glist)
{
t_hslider *x = (t_hslider *)client;
-if (glist_isvisible(glist))
+if (glist_isvisible(glist) x-x_val != x-x_prev_val)
{
int r = text_xpix(x-x_gui.x_obj, glist) + (x-x_val + 50)/100;
int ypos=text_ypix(x-x_gui.x_obj, glist);
@@ -57,6 +57,7 @@ static void hslider_draw_update(t_gobj *client, t_glist
*glist)
x-x_thick = 0;
}
}
+x-x_prev_val = x-x_val;
}
}
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding a built-in [change] object to the built-in GUI objects
On Dec 1, 2012, at 3:28 AM, Jonathan Wilkes wrote:
- Original Message -
From: Hans-Christoph Steiner h...@at.or.at
To: pd-dev@iem.at List pd-dev@iem.at
Cc:
Sent: Friday, November 30, 2012 11:20 PM
Subject: [PD-dev] adding a built-in [change] object to the built-in GUI
objects
Lots of patches use the built-in GUI objects for displays, and often a fast
stream of events is hooked straight up to the GUI object, causing the GUI
object
to send many pointless updates, like draw commands when the number hasn't
changed, or multiple draw commands per screen refresh cycle.
The multiple draw commands per screen refresh cycle seems like the more common
source of needless draw commands.
That should be addressed too, but that's a lot more complicated. Honestly, I
think it would be better to rewrite the basic GUI objects from scratch rather
than put more into the current ones.
I propose to only send the GUI update commands when the relevant value has
changed. I think this should apply to both the main element, like the
slider
knob, and the label for that GUI object, since that's often used as a
display. The code change is pretty simple, but I was wondering if people
thought there could be any problems caused by this
At the end of hslider_set, why not just check if x-x_value==(int)(100.0*g +
0.4)
before assigning it? If its already equal just return.
Good idea, that's what I ended up doing:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16643
Then I did something similar for the [label ( draws:
http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended.git;a=commitdiff;h=0271c92082c6db85eccba0f0b1226b9dbff09ceb
.hc
Here is the needed change, for example, for the hslider knob:
index b352fb9..88681fc 100644
--- a/src/g_all_guis.h
+++ b/src/g_all_guis.h
@@ -185,6 +185,7 @@ typedef struct _hslider
t_iemgui x_gui;
int x_pos;
int x_val;
+int x_prev_val;
int x_center;
int x_thick;
int x_lin0_log1;
index 470771a..e1a3c83 100644
--- a/src/g_hslider.c
+++ b/src/g_hslider.c
@@ -33,7 +33,7 @@ static t_class *hslider_class;
static void hslider_draw_update(t_gobj *client, t_glist *glist)
{
t_hslider *x = (t_hslider *)client;
-if (glist_isvisible(glist))
+if (glist_isvisible(glist) x-x_val != x-x_prev_val)
{
int r = text_xpix(x-x_gui.x_obj, glist) + (x-x_val +
50)/100;
int ypos=text_ypix(x-x_gui.x_obj, glist);
@@ -57,6 +57,7 @@ static void hslider_draw_update(t_gobj *client, t_glist
*glist)
x-x_thick = 0;
}
}
+x-x_prev_val = x-x_val;
}
}
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
[PD-dev] building for Windows on GNU/Linux
Hey Miller, I see that you are using MSVC via Wine on GNU/Linux. I don't know how well supported that arrangement is, for a widely supported version of that arrangement, you should try running the MinGW builds on GNU/Linux. The makefile.mingw should work fine for that just set compiler (i.e. make CC=/path/to/mingw-gcc). Here's lots of docs for doing this on Fedora: https://fedoraproject.org/wiki/MinGW Most distros include a mingw-gcc cross-compiler, so they just need to 'yum install', 'apt-get install', etc. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] adding a built-in [change] object to the built-in GUI objects
Lots of patches use the built-in GUI objects for displays, and often a fast
stream of events is hooked straight up to the GUI object, causing the GUI
object to send many pointless updates, like draw commands when the number
hasn't changed, or multiple draw commands per screen refresh cycle.
I propose to only send the GUI update commands when the relevant value has
changed. I think this should apply to both the main element, like the slider
knob, and the label for that GUI object, since that's often used as a display.
The code change is pretty simple, but I was wondering if people thought there
could be any problems caused by this
Here is the needed change, for example, for the hslider knob:
index b352fb9..88681fc 100644
--- a/src/g_all_guis.h
+++ b/src/g_all_guis.h
@@ -185,6 +185,7 @@ typedef struct _hslider
t_iemgui x_gui;
int x_pos;
int x_val;
+int x_prev_val;
int x_center;
int x_thick;
int x_lin0_log1;
index 470771a..e1a3c83 100644
--- a/src/g_hslider.c
+++ b/src/g_hslider.c
@@ -33,7 +33,7 @@ static t_class *hslider_class;
static void hslider_draw_update(t_gobj *client, t_glist *glist)
{
t_hslider *x = (t_hslider *)client;
-if (glist_isvisible(glist))
+if (glist_isvisible(glist) x-x_val != x-x_prev_val)
{
int r = text_xpix(x-x_gui.x_obj, glist) + (x-x_val + 50)/100;
int ypos=text_ypix(x-x_gui.x_obj, glist);
@@ -57,6 +57,7 @@ static void hslider_draw_update(t_gobj *client, t_glist
*glist)
x-x_thick = 0;
}
}
+x-x_prev_val = x-x_val;
}
}
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] weirdness in ctrl-f Find
I tried this on Pd-extended 0.42.5 and 0.43.5 on Mac OS X, and it worked fine for me, as long as I unchecked match whole word only .hc On Nov 29, 2012, at 3:27 PM, Jonathan Wilkes wrote: Try this: 1) Create new patch 2) Make a comment with this text: (foo) 3) Click ctrl-f and type this in the entry widget: foo No match. 4) Create a message box with this text: (foo) 5) Click ctrl-f and type this in the entry widget: foo Match. This manifests itself in other cases, too-- I'll get search results with the search-plugin but if I open the patch and do ctrl-f for the search term I won't get any results because the term happens to be in a comment, up against a parenthesis. If someone can confirm I'll post on the bug tracker. -Jonathan ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] search plugin in Pd-extended
What's the pd.info stuff? .hc On Nov 16, 2012, at 12:42 AM, Jonathan Wilkes wrote: But how do I keep the pd.info stuff in sync with your changes? -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev@iem.at List pd-dev@iem.at Sent: Thursday, November 15, 2012 10:07 PM Subject: Re: [PD-dev] search plugin in Pd-extended I just checked in some changes to search-plugin to try the translation stuff. First, I added [_ ] to most of the strings there. The rest I left because they'll need a little more work. Then I added a 'po' folder with a Makefile to generate the translations. I mostly did this to have a dev environment for trying out having translation support for plugins. .hc On 11/15/2012 07:14 PM, Jonathan Wilkes wrote: Here's an initial re-refactoring back to the plugin interface: https://puredata.info/Members/jancsika/browser2.0plugin/view Don't use this one yet, because I have some more changes to make based on the following question: 1) How do I remove the old helpbrowser entry from the Help menu from inside my plugin? That way the new helpbrowser will show up for new users, along with an accelerator ctrl-g, without disturbing old grumps and their ctrl-b browser. -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev@iem.at List pd-dev@iem.at Sent: Thursday, November 15, 2012 9:36 AM Subject: Re: [PD-dev] search plugin in Pd-extended For Pd-extended, I'd much rather keep it as a plugin than make it an internal file. I think it will be much easier for you to work on the search plugin if it stays as a plugin. If its a plugin that's included in Pd-extended, it can be upgraded by the user by just dropping a new version into ~/pd-externals. The dev process will be easier too, since updates won't have to go thru the patch tracker to be accepted into pd-extended.git. For Vanilla, you'll have to ask Miller. I think this same approach could work for vanilla too with the same advantages. All that Miller would need to do to include it is check in the search-plugin into pd/extra/ .hc On 11/15/2012 01:45 AM, Jonathan Wilkes wrote: I already did substantial work on the drop-in replacement for the helpbrowser based on the feedback I got. I had no idea the gui-plugin infrastructure was ready to ship actual plugins running by default in pd-extended. -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-dev@iem.at List pd-dev@iem.at Cc: Sent: Wednesday, November 14, 2012 11:31 PM Subject: [PD-dev] search plugin in Pd-extended Hey Jonathan, I committed your latest search-plugin.tcl into scripts/guiplugins/search-plugin, overwriting my original, simple one. I put it there because I'm adding it to Pd-extended. I think it makes sense to just include your plugin directly rather than as a remixed helpbrowser.tcl. I also just committed a check that makes sure that pd-gui doesn't try to load a plugin that has already been loaded. That way when you make new version of the search plugin, people can just drop it into ~/pd-externals and it'll override the built-in search-plugin.tcl. As for scripts/guiplugins/search-plugin, feel free to take that over and do whatever you want with it. I can't see a reason to keep the old one around any more, your search plugin is very thorough. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] search plugin in Pd-extended
I just checked in some changes to search-plugin to try the translation stuff. First, I added [_ ] to most of the strings there. The rest I left because they'll need a little more work. Then I added a 'po' folder with a Makefile to generate the translations. I mostly did this to have a dev environment for trying out having translation support for plugins. .hc On 11/15/2012 07:14 PM, Jonathan Wilkes wrote: Here's an initial re-refactoring back to the plugin interface: https://puredata.info/Members/jancsika/browser2.0plugin/view Don't use this one yet, because I have some more changes to make based on the following question: 1) How do I remove the old helpbrowser entry from the Help menu from inside my plugin? That way the new helpbrowser will show up for new users, along with an accelerator ctrl-g, without disturbing old grumps and their ctrl-b browser. -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev@iem.at List pd-dev@iem.at Sent: Thursday, November 15, 2012 9:36 AM Subject: Re: [PD-dev] search plugin in Pd-extended For Pd-extended, I'd much rather keep it as a plugin than make it an internal file. I think it will be much easier for you to work on the search plugin if it stays as a plugin. If its a plugin that's included in Pd-extended, it can be upgraded by the user by just dropping a new version into ~/pd-externals. The dev process will be easier too, since updates won't have to go thru the patch tracker to be accepted into pd-extended.git. For Vanilla, you'll have to ask Miller. I think this same approach could work for vanilla too with the same advantages. All that Miller would need to do to include it is check in the search-plugin into pd/extra/ .hc On 11/15/2012 01:45 AM, Jonathan Wilkes wrote: I already did substantial work on the drop-in replacement for the helpbrowser based on the feedback I got. I had no idea the gui-plugin infrastructure was ready to ship actual plugins running by default in pd-extended. -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-dev@iem.at List pd-dev@iem.at Cc: Sent: Wednesday, November 14, 2012 11:31 PM Subject: [PD-dev] search plugin in Pd-extended Hey Jonathan, I committed your latest search-plugin.tcl into scripts/guiplugins/search-plugin, overwriting my original, simple one. I put it there because I'm adding it to Pd-extended. I think it makes sense to just include your plugin directly rather than as a remixed helpbrowser.tcl. I also just committed a check that makes sure that pd-gui doesn't try to load a plugin that has already been loaded. That way when you make new version of the search plugin, people can just drop it into ~/pd-externals and it'll override the built-in search-plugin.tcl. As for scripts/guiplugins/search-plugin, feel free to take that over and do whatever you want with it. I can't see a reason to keep the old one around any more, your search plugin is very thorough. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] clearing out old build system
Yes, this sounds great! On the topic of the new build system, its quite close to working on MinGW. The new build system will never work for MSVC, so it makes sense to keep the makefile.nt, but I think it should renamed Makefile.msvc to make it clear what its for. Also, in Pd-extended, I've removed some stuff from configure.ac to simplify it. There are a number of tests that we don't need there. I think the key to keeping the build system maintainable is to keep it as simple as possible. So including tests of things that have no automatic response is not useful for all but a couple people who know how to add them in anyhow. Attached is my patch to remove those tests. simplify-configure.ac.patch Description: Binary data .hc On Nov 18, 2012, at 2:42 PM, Miller Puckette wrote: To Pd developers - I'm finally gearing up to clean out the old build system which, I believe, will entail removing these files from pd/src: config.h.in configure configure.in install-sh makefile.clean makefile.dependencies makefile.in ... any objections? (i.e. is anyone but me still using this who can't move forward to the new' system (cd pd; autogen.sh; ./configure; make) ? I'm planning on leaving makefile.nt and makefile.mingw around for luddites, and also will probably supply a makefile.gnu as a fallback for when, I predict inevitably, the new build system crumbles under its own weight. cheers Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] clearing out old build system
On Nov 19, 2012, at 5:20 PM, IOhannes m zmölnig wrote: On 11/19/2012 07:33 PM, Hans-Christoph Steiner wrote: The new build system will never work for MSVC, why? what keeps you from using autotools with msvc? (sure, autotools require mingw/cygwin to run the bash-script (and once you installed mingw/cygwin, installing gcc is easy enough), but whether your compiler is gcc or msvc shouldn't matter) I have no particular objection to someone doing it, it just seems like a recipe for a lot of pain with little good reason. Sounds like you have to do a lot of crazy kludges: http://lists.gnu.org/archive/html/autoconf/2004-09/msg00061.html in which case, I think it'll be much less work for everyone involved to maintain the MSVC builds in a separate file, just like the build systems for Rockbox, iOS, Android, etc. Basically no one is using the autotools build that is there for iOS and Android. I think we should remove the iOS and Android stuff from the autotools build and call libpd the official iOS and Android build system. That's already the de facto case. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] search plugin in Pd-extended
Hey Jonathan, I committed your latest search-plugin.tcl into scripts/guiplugins/search-plugin, overwriting my original, simple one. I put it there because I'm adding it to Pd-extended. I think it makes sense to just include your plugin directly rather than as a remixed helpbrowser.tcl. I also just committed a check that makes sure that pd-gui doesn't try to load a plugin that has already been loaded. That way when you make new version of the search plugin, people can just drop it into ~/pd-externals and it'll override the built-in search-plugin.tcl. As for scripts/guiplugins/search-plugin, feel free to take that over and do whatever you want with it. I can't see a reason to keep the old one around any more, your search plugin is very thorough. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] separate the audio-backends
On Oct 31, 2012, at 5:48 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-10-31 04:11, Hans-Christoph Steiner wrote: I think this would be super valuable. libpd already has an implementation of parts of this idea, but making fully separate modules would be quite nice. Have you talked with Peter Brinkmann at all? It would be nice to have these efforts synced up since they seem to have the same aim. i haven't talked with peter about this recently. anyhow, i cleaned up the code a bit and pushed it to my github fork. check it out at [1]. What about taking it in this direction fully and making it possible to encapsulate the entire implementation for a given audio API in a single file? Then having it so s_audio.c is never modified. I think this is how it is for libpd, but I suppose that's easier there since libpd assumes there is some other program that will handle that stuff. If there was a register function like how loaders are registered, and a very simple load path like a pre-defined folder like pd/lib, then pd -audioapi jack could just look for libaudio-jack.so there and load it. Or maybe it would be better to use the normal Pd search path. This would have the extra benefit of making it easy for people to distribute and use alternate implementations of the various APIs. currently MIDI has not been touched yet. also the preferences system (including startup flags) would need some slight modifications (e.g. use something like -audioapi jack rather than -jack; and use symbolic values (audioapi: jack) in the .pdsettings file as well, rather than some weirdo numbers (audioapi: 42 anyone?) The symbolic values make a lot of sense. We should leave in the code in Pd that reads the numeric values to support old files, but just have it always write out the symbol values. That should make the transition easier. I tried this on Mac OS X, it builds and runs. Jack works, but portaudio does not. It does not give me any audio devices when I try to configure portaudio (see attached pic): inline: Screen shot 2012-10-31 at 9.43.01 AM.png .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] lib name and trunk commit
On Oct 31, 2012, at 9:20 AM, Cyrille Henry wrote: hello, I would like to commit a new library. I've heard that having a pmpd object in a pmpd lib did cause problem for some, but i can't remember why. so does it matter to have a library name different from all objects name, or can i use the same? If you want to make a library that is only one object, then that is the best approach, check out plugin~, bassemu~, freeverb~, etc. By default when loading [classname] Pd will try classname/classname.pd_linux then classname.pd_linux. If you have a library called 'bar' and it includes many objects including one called 'bar', that will make things confusing for a number of reasons. [bar] will load just by typing [bar] (i.e. it'll find bar/bar.pd-linux) but any other object in that library will not load until you load the library itself using [declare] or [import]. vbap currently is like this and that setup is quite annoying. Since finding a lib is harder when it's located in a developer directory, and since i will not be the only dev for this lib, can i upload it directly in trunc, or should i still use the nusmuk folder? I agree that the developer folders make things harder to find. Just put anything directly in trunk/externals where most libraries are. Feel free to move anything out of nusmuk there too. If you base your libraries on the Library Template like pmpd, then it'll automatically be built as part of a nightly test build: https://macosx105-i386.pdlab.puredata.info/job/template-libraries/ .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] separate the audio-backends WAS: pd 0.43-3 released
On Jul 4, 2012, at 3:51 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-03 23:11, Miller Puckette wrote: Hi all, Pd version 0.43-3 is available on http://crca.ucsd.edu/~msp/software.htm cool. I'm ready to start hacking on 0.44. The most urgent thing seems to be for me to go back and work on the audio system (and perhaps tweak MIDI a bit more too). i have a project lying on my hardisk for 1 year (iirc, shortly before the 0.32.0 release), that is related to that: separating the audio system(s) from Pd-core. background: currently Pd supports a number of audio-backends. while these backends are mainly separated into several source files (e.g. s_audio_alsa.c for ALSA), there is a lot of theoretically backend-agnostic code (s_audio, s_midi, s_main) cluttered with #ifdef USEAPI_ALSA and the like. this makes the current code badly readable and thus maintainable, it also makes it hard to add new audio systems as backends (and the more you add, the more complicated the codebase gets). more background: currently all audio backends are linked to the main Pd binary. if your version of Pd is compiled for alsa, jack, OSS and portaudio (the default on debian), you have quite a number of dependencies. (as maintainer of the puredata debian package i prefer to keep necessary dependencies at a minimum). furthermore, Pd supports outdated/deprecated backends like OSS (both audio and midi). in practice i haven't used OSS-midi for a number of years (and i doubt whether it is actually still supported by the mainline kernels), and i used OSS-audio only seldomly in very specific setups. from this i follow, that the majority of people have to fight their way through a lot of dead options that are more confusing than helpful, and which should probably be removed in most cases. suggestion: so what i ended up doing, was separate the audio-backends from the pd-core code a bit more, in a similar way to how Pd's object registration works. the means that people could write new audio-backends and load them on-demand, just like externals. it also means that Pd's non-audiosystem codebase has only a minimum of #ifdef USEAPI_ALSA (there's only one, when it comes to loading the internal audio-system at startup). all this also applies to MIDI. if there's interest, i could cleanup the patches (and make them work again with 0.43.3) and submit them for review. if there's confusion, i could try to try again and explain what i want. I think this would be super valuable. libpd already has an implementation of parts of this idea, but making fully separate modules would be quite nice. Have you talked with Peter Brinkmann at all? It would be nice to have these efforts synced up since they seem to have the same aim. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
On Oct 28, 2012, at 4:10 PM, Miller Puckette wrote: Why not use the same throttling mechanism Miller put for data structures for iemguis and see if it's suitable? I think what you'll find is that this is a complex problem, and you certainly won't get a consensus that just make the gui get out of the way for the sound is the right approach. In fact for anything that is handling user input through the GUI you'd better make sure the GUI responds when it's supposed to, otherwise it _will_ appear to be broken from the standpoint of the user. Just look at the history of video games-- game developers are willing to remove entire voices at will in the audio in order to keep the interface from becoming sluggish. You might say this is just the visual bias in our culture, but the more significant factor is that a light switch that reacts to the force from your finger one second after you flip it is no longer a switch-- it's a physical anomaly. Anyway, I think the problem is often on the c side instead of the tk side. If you load a 20sec sample into an array while dsp is on and soundfiler isn't threaded, what do you really expect to happen?[1] -Jonathan [1] Hm... rather than threaded... what if you could set a flag that tells [soundfiler] the maximum amount of the soundfile to process every block? Or maybe have an object called [soundfiler~], where you can give it an arg to set the number of samples to be loaded every block? That's what readsf~ does... just dump the output into a tabwrite~ and you're got it. But the question of how to smoothly update table graphics without messing up real-time behavior is still wode open. Ideally there would be some way of sharing the table memory with the GUI process. Then the GUI process would just read that table using the clock of the screen refresh, at something like 60Hz, and handling the drawing itself. Then the DSP code could be totally ignorant of the drawing. That would also make it easy to set the DSP processing priority higher than the redrawing priority. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
On Oct 28, 2012, at 11:34 PM, Hans-Christoph Steiner wrote: On Oct 28, 2012, at 4:10 PM, Miller Puckette wrote: Why not use the same throttling mechanism Miller put for data structures for iemguis and see if it's suitable? I think what you'll find is that this is a complex problem, and you certainly won't get a consensus that just make the gui get out of the way for the sound is the right approach. In fact for anything that is handling user input through the GUI you'd better make sure the GUI responds when it's supposed to, otherwise it _will_ appear to be broken from the standpoint of the user. Just look at the history of video games-- game developers are willing to remove entire voices at will in the audio in order to keep the interface from becoming sluggish. You might say this is just the visual bias in our culture, but the more significant factor is that a light switch that reacts to the force from your finger one second after you flip it is no longer a switch-- it's a physical anomaly. Anyway, I think the problem is often on the c side instead of the tk side. If you load a 20sec sample into an array while dsp is on and soundfiler isn't threaded, what do you really expect to happen?[1] -Jonathan [1] Hm... rather than threaded... what if you could set a flag that tells [soundfiler] the maximum amount of the soundfile to process every block? Or maybe have an object called [soundfiler~], where you can give it an arg to set the number of samples to be loaded every block? That's what readsf~ does... just dump the output into a tabwrite~ and you're got it. But the question of how to smoothly update table graphics without messing up real-time behavior is still wode open. Ideally there would be some way of sharing the table memory with the GUI process. Then the GUI process would just read that table using the clock of the screen refresh, at something like 60Hz, and handling the drawing itself. Then the DSP code could be totally ignorant of the drawing. That would also make it easy to set the DSP processing priority higher than the redrawing priority. This is a potential way to do it: http://tcl-mmap.sourceforge.net/ .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
I think everyone agrees with that, but its a big job and someone needs to do
that work. You can help with that. Take on a piece that most interests you
and try to make it better. Or try profiling various parts to figure out what
is causing the slowness.
I've had good luck with sticking print statements with single letters to
represent different stages of something. You can do that by adding this to the
C code:
fprintf(stderr, B);
Then run Pd like: pd -stderr. With this you then set a log of what's happening
and you can narrow down the problem. For example, with the array redrawing
stopping, I was able to see that its not in the GUI at all, since pd stops
sending GUI commands.
.hc
On Oct 26, 2012, at 2:36 PM, Lorenzo Sutton wrote:
I'm not sure if this is relevant but following this thread triggered
something I'm thinking of since a while and was a little sceptical to share
anyway here goes...
I really think all those parts of the gui which have an impact on performance
(e.g. having lots of sliders or big arrays update and you get clicks and
glitches in the audio) should be redone.
Personally I don't care about aesthetics actually I always like the way Pd
looks. What I find frustrating is when I can't use or am limited in using the
gui because it has an impact on audio performance.
Does this make any sense? Is it agreeable?
Lorenzo.
On 25/10/12 23:13, Miller Puckette wrote:
The lines,
if (phase = endphase)
{
tabwrite_tilde_redraw(x);
phase = 0x7fff;
}
fix it so that a tabwrite~ only redraws the array once it's completely
overwritten.
In my view, the updates should be split into chunks (not made into one long
message for the entire table) and they should scan across the table at
some controlled rate. I don't know how the rate should be chosen though
(and it might want to depend on what other graphical activity there is.)
It gets ugly because when the array is drawn as points they're not tagged
in the right way to allow partial redraws.
cheers
Miller
On Thu, Oct 25, 2012 at 05:04:22PM -0400, Hans-Christoph Steiner wrote:
My brain is already halfway in it, can you give me some pointers on where to
look? Do you know what code is stopping the updates?
.hc
On 10/25/2012 04:56 PM, Miller Puckette wrote:
THe whole edifice needs to be reworked I'm afraid... but it's a big project
which I haven't yet been able to get started on.
cheers
M
On Thu, Oct 25, 2012 at 04:37:53PM -0400, Hans-Christoph Steiner wrote:
I can see a reason to rate limit the updates, but totally stopping them
seems
really bad to me. Anyone disagree?
.hc
On 10/25/2012 03:56 PM, Jonathan Wilkes wrote:
At arraysize = 4352 I get animation for the full range of the slider
At arraysize = 4353 I get frozen array for full range
Of course if I try to move the number box down with arraysize at 4352
I get freezes.
Changing to polygons or points doesn't change it.
In general there's nothing special about the98.5 rate. For arraysize=n
there's obviously an update rate x under which it no longer sends
updates,
and I guess for the size you chose that's it.
How does other software like Supercllider deal with scope updates?
-Jonathan
- Original Message -
From: Hans-Christoph Steiner h...@at.or.at
To: pd-dev@iem.at
Cc:
Sent: Thursday, October 25, 2012 2:28 PM
Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~]
into visual array
OK, this is strange. Lorenzo's patch works fine on mine too, down to
2ms.
But my patch still has the same 98.5ms issue. Its attached again, if
you could
try it.
.hc
On 10/25/2012 06:21 AM, Lorenzo Sutton wrote:
Same here, 0.43.4-extended-20121022 - Wheezy (guess it's the most
recent
extended autobuild?)
The attached patch works all the way down to 2 msec, of course with
various
'artefacts'.
Lorenzo
On 25/10/12 04:28, Jonathan Wilkes wrote:
It updates fine with 0.43.1-extended-20120815 on Wheezy, even at
[metro
2]
although I
start getting sluggishness with that setting.
-Jonathan
- Original Message -
From: Hans-Christoph Steiner h...@at.or.at
To: pd-dev List pd-dev@iem.at
Cc:
Sent: Wednesday, October 24, 2012 9:33 PM
Subject: Re: [PD-dev] strange behavior of [metro 98.5] for
[tabwrite~] into
visual array
No ideas on this one? It is a serious bug since it means that
arrays stop
being drawn at all when banged often than 100ms.
.hc
On 10/08/2012 12:26 PM, Hans-Christoph Steiner wrote:
I've noticed that if you bang a [tabwrite~ array1] more
often than
about 100ms, the array that its writing to will not send updates to
the
GUI. It
seems that its a kind of a fade out with [metro 100] seems to send
all
updates,
[metro 98.8] send some updates and [metro 95] sends basically none
Re: [PD-dev] Mouse pointer disappears over pdp windows...
Let's keep this on the list. I'm not a pdp or graphics dev, so I won't be able to help as the questions get deeper, but I'm happy to help you dig. It would be good to have more work on PDP, its a solid library. I do remember vaguely Tom Schouten talking about this, did you try to search the archives of the pd lists? Or maybe try emailing Tom directly. You could also look at Gem and gridflow to see how they handle it. .hc On 10/25/2012 09:29 AM, Gert De Roost wrote: I'm using Linux (32bit Arch) and havent tried any others. The output method Im concerned with is pdp_glx but I remember same problem exists for pdp_xv... Gert On Thu, Oct 25, 2012 at 2:23 AM, Hans-Christoph Steiner h...@at.or.atwrote: Which OS and which output method? Have you tried others? Also, I think that the solution to this problem will vary based on those as well. .hc On 10/24/2012 02:39 PM, Gert De Roost wrote: Since some time Ive been developing a videomixer with PureData ( http://www.ewocprojects.be) and one of the less pressing problems is the mouse pointer behaviour when using pdp output windows. At the moment the pointer disappears when over any of these windows, and since my mixer uses a multiple of windows onscreen, this makes the program more difficult to control, cause one can easily lose the mouse pointer... Is there anyone with knowledge of pdp source who knows how to fix this problem, Id really appreciate also any info as to why, technically, the pointer disappears, because then maybe I can fix this myself? Thanks, Gert De Roost ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
Really? You see the array getting updated constantly? I've tried two computers and both where the same. .hc On 10/25/2012 06:21 AM, Lorenzo Sutton wrote: Same here, 0.43.4-extended-20121022 - Wheezy (guess it's the most recent extended autobuild?) The attached patch works all the way down to 2 msec, of course with various 'artefacts'. Lorenzo On 25/10/12 04:28, Jonathan Wilkes wrote: It updates fine with 0.43.1-extended-20120815 on Wheezy, even at [metro 2] although I start getting sluggishness with that setting. -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-dev List pd-dev@iem.at Cc: Sent: Wednesday, October 24, 2012 9:33 PM Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array No ideas on this one? It is a serious bug since it means that arrays stop being drawn at all when banged often than 100ms. .hc On 10/08/2012 12:26 PM, Hans-Christoph Steiner wrote: I've noticed that if you bang a [tabwrite~ array1] more often than about 100ms, the array that its writing to will not send updates to the GUI. It seems that its a kind of a fade out with [metro 100] seems to send all updates, [metro 98.8] send some updates and [metro 95] sends basically none. Any ideas what could be causing this? I didn't see anything. This happens on 0.42.5, 0.43.4 and pure-data.git master. Attached is patch to demonstrate this. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
OK, this is strange. Lorenzo's patch works fine on mine too, down to 2ms. But my patch still has the same 98.5ms issue. Its attached again, if you could try it. .hc On 10/25/2012 06:21 AM, Lorenzo Sutton wrote: Same here, 0.43.4-extended-20121022 - Wheezy (guess it's the most recent extended autobuild?) The attached patch works all the way down to 2 msec, of course with various 'artefacts'. Lorenzo On 25/10/12 04:28, Jonathan Wilkes wrote: It updates fine with 0.43.1-extended-20120815 on Wheezy, even at [metro 2] although I start getting sluggishness with that setting. -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-dev List pd-dev@iem.at Cc: Sent: Wednesday, October 24, 2012 9:33 PM Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array No ideas on this one? It is a serious bug since it means that arrays stop being drawn at all when banged often than 100ms. .hc On 10/08/2012 12:26 PM, Hans-Christoph Steiner wrote: I've noticed that if you bang a [tabwrite~ array1] more often than about 100ms, the array that its writing to will not send updates to the GUI. It seems that its a kind of a fade out with [metro 100] seems to send all updates, [metro 98.8] send some updates and [metro 95] sends basically none. Any ideas what could be causing this? I didn't see anything. This happens on 0.42.5, 0.43.4 and pure-data.git master. Attached is patch to demonstrate this. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev #N canvas 511 185 450 300 10; #N canvas 0 22 450 278 (subpatch) 0; #X array array1 4410 float 5; #A 0 0.501334 -0.778581 0.964787 0.405799 -0.79286 -0.78484 0.835877 -0.321006 -0.471601 0.0544877 0.223917 -0.392722 -0.348716 -0.256218 0.317765 0.37008 0.0837448 0.352364 -0.55163 0.953955 0.671133 -0.87613 0.854393 -0.488035 -0.888171 0.0856294 -0.0521629 0.22305 0.972863 0.158036 -0.92033 0.651404 -0.794454 -0.236073 -0.194551 -0.394152 -0.838911 -0.062046 0.650946 -0.50079 -0.893769 -0.0640379 0.34 -0.792304 0.238862 -0.655638 0.749008 -0.569737 0.203652 0.689504 0.794815 0.548002 0.107672 0.547059 0.578077 0.983503 -0.963981 -0.848616 0.460016 0.0602379 0.067445 0.504907 -0.134184 -0.638068 -0.38592 0.177814 -0.193654 0.160176 -0.616409 0.681946 0.451347 -0.491052 0.59131 0.478443 -0.446761 0.779899 -0.717217 0.587309 -0.589745 -0.0819185 0.325336 -0.406511 -0.0372808 -0.824322 0.423695 0.756246 0.558668 -0.528625 0.635616 -0.381467 -0.78052 -0.750265 0.387504 0.11637 -0.594503 -0.15942 0.990045 -0.811782 0.281652 -0.681645 0.653824 -0.115645 0.483091 0.861513 -0.995043 0.976251 -0.619199 -0.388117 -0.899292 -0.93406 -0.152765 0.0340511 0.945121 -0.804601 0.521933 -0.225271 0.504643 -0.0440769 -0.422847 0.0221356 0.223747 -0.902505 -0.0165101 0.365365 -0.959442 -0.361832 0.275506 0.153769 -0.0975214 0.473432 0.817352 0.356325 0.781815 -0.514402 -0.431607 -0.078983 -0.8086 -0.846834 -0.651164 0.634206 0.200218 0.660202 0.60535 0.480007 -0.0509686 0.505714 -0.323303 -0.500334 0.666005 -0.386972 0.559351 0.15093 -0.817669 0.93916 0.173128 0.167427 0.947853 -0.41581 -0.873193 -0.0819612 -0.453307 -0.599355 -0.0162415 0.266275 -0.287124 0.102863 -0.972434 0.929649 -0.154047 0.876376 -0.472344 -0.660946 0.0266265 0.487282 0.504915 -0.00186262 -0.467621 -0.108379 0.997325 0.342675 -0.146907 -0.655251 -0.174423 -0.900054 -0.79332 0.0107127 0.858708 -0.851891 0.554703 0.0716257 -0.220286 0.875576 -0.881998 -0.662957 0.351184 0.04039 -0.60768 0.353337 0.180923 0.129595 -0.336073 0.0130687 -0.0124272 -0.781385 0.0252457 -0.335631 0.366242 -0.669371 -0.109524 -0.279692 0.0541274 0.295944 -0.98878 0.768273 -0.303857 0.11137 -0.00789281 -0.820658 -0.889459 -0.200403 0.306419 -0.782339 0.054538 0.768569 -0.188284 -0.350185 0.489942 0.670859 -0.234542 0.854207 0.348776 -0.236957 -0.659365 0.430432 0.7989 -0.234923 -0.358612 -0.691351 -0.990358 -0.78033 -0.781365 0.358962 0.417418 -0.64834 -0.914302 -0.499213 0.491361 0.42739 -0.766075 -0.687764 -0.00106015 0.614079 0.648316 -0.860517 -0.228408 -0.660795 0.823149 -0.293853 0.970344 -0.85013 0.777604 0.222662 0.851436 0.0721815 -0.42861 -0.00434752 0.0319494 0.470627 0.320366 0.537311 -0.744571 0.407447 -0.28783 0.17477 -0.34249 -0.497989 -0.97816 -0.840521 0.531543 -0.709807 0.627445 -0.723419 0.594218 0.0837439 0.0257037 -0.0457195 0.75119 0.329671 -0.652388 0.873228 0.362703 0.469609 0.37407 -0.924112 -0.990782 -0.700803 -0.948496 0.575918 -0.242966 0.827453 -0.492508 0.467541 -0.0760855 -0.363851 -0.433609 -0.46508 -0.655286 0.739185 -0.235041 -0.638463 0.137002 -0.0580329 -0.132019
Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
I can see a reason to rate limit the updates, but totally stopping them seems really bad to me. Anyone disagree? .hc On 10/25/2012 03:56 PM, Jonathan Wilkes wrote: At arraysize = 4352 I get animation for the full range of the slider At arraysize = 4353 I get frozen array for full range Of course if I try to move the number box down with arraysize at 4352 I get freezes. Changing to polygons or points doesn't change it. In general there's nothing special about the98.5 rate. For arraysize=n there's obviously an update rate x under which it no longer sends updates, and I guess for the size you chose that's it. How does other software like Supercllider deal with scope updates? -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-dev@iem.at Cc: Sent: Thursday, October 25, 2012 2:28 PM Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array OK, this is strange. Lorenzo's patch works fine on mine too, down to 2ms. But my patch still has the same 98.5ms issue. Its attached again, if you could try it. .hc On 10/25/2012 06:21 AM, Lorenzo Sutton wrote: Same here, 0.43.4-extended-20121022 - Wheezy (guess it's the most recent extended autobuild?) The attached patch works all the way down to 2 msec, of course with various 'artefacts'. Lorenzo On 25/10/12 04:28, Jonathan Wilkes wrote: It updates fine with 0.43.1-extended-20120815 on Wheezy, even at [metro 2] although I start getting sluggishness with that setting. -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-dev List pd-dev@iem.at Cc: Sent: Wednesday, October 24, 2012 9:33 PM Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array No ideas on this one? It is a serious bug since it means that arrays stop being drawn at all when banged often than 100ms. .hc On 10/08/2012 12:26 PM, Hans-Christoph Steiner wrote: I've noticed that if you bang a [tabwrite~ array1] more often than about 100ms, the array that its writing to will not send updates to the GUI. It seems that its a kind of a fade out with [metro 100] seems to send all updates, [metro 98.8] send some updates and [metro 95] sends basically none. Any ideas what could be causing this? I didn't see anything. This happens on 0.42.5, 0.43.4 and pure-data.git master. Attached is patch to demonstrate this. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
My brain is already halfway in it, can you give me some pointers on where to look? Do you know what code is stopping the updates? .hc On 10/25/2012 04:56 PM, Miller Puckette wrote: THe whole edifice needs to be reworked I'm afraid... but it's a big project which I haven't yet been able to get started on. cheers M On Thu, Oct 25, 2012 at 04:37:53PM -0400, Hans-Christoph Steiner wrote: I can see a reason to rate limit the updates, but totally stopping them seems really bad to me. Anyone disagree? .hc On 10/25/2012 03:56 PM, Jonathan Wilkes wrote: At arraysize = 4352 I get animation for the full range of the slider At arraysize = 4353 I get frozen array for full range Of course if I try to move the number box down with arraysize at 4352 I get freezes. Changing to polygons or points doesn't change it. In general there's nothing special about the98.5 rate. For arraysize=n there's obviously an update rate x under which it no longer sends updates, and I guess for the size you chose that's it. How does other software like Supercllider deal with scope updates? -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-dev@iem.at Cc: Sent: Thursday, October 25, 2012 2:28 PM Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array OK, this is strange. Lorenzo's patch works fine on mine too, down to 2ms. But my patch still has the same 98.5ms issue. Its attached again, if you could try it. .hc On 10/25/2012 06:21 AM, Lorenzo Sutton wrote: Same here, 0.43.4-extended-20121022 - Wheezy (guess it's the most recent extended autobuild?) The attached patch works all the way down to 2 msec, of course with various 'artefacts'. Lorenzo On 25/10/12 04:28, Jonathan Wilkes wrote: It updates fine with 0.43.1-extended-20120815 on Wheezy, even at [metro 2] although I start getting sluggishness with that setting. -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-dev List pd-dev@iem.at Cc: Sent: Wednesday, October 24, 2012 9:33 PM Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array No ideas on this one? It is a serious bug since it means that arrays stop being drawn at all when banged often than 100ms. .hc On 10/08/2012 12:26 PM, Hans-Christoph Steiner wrote: I've noticed that if you bang a [tabwrite~ array1] more often than about 100ms, the array that its writing to will not send updates to the GUI. It seems that its a kind of a fade out with [metro 100] seems to send all updates, [metro 98.8] send some updates and [metro 95] sends basically none. Any ideas what could be causing this? I didn't see anything. This happens on 0.42.5, 0.43.4 and pure-data.git master. Attached is patch to demonstrate this. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Mouse pointer disappears over pdp windows...
Which OS and which output method? Have you tried others? Also, I think that the solution to this problem will vary based on those as well. .hc On 10/24/2012 02:39 PM, Gert De Roost wrote: Since some time Ive been developing a videomixer with PureData ( http://www.ewocprojects.be) and one of the less pressing problems is the mouse pointer behaviour when using pdp output windows. At the moment the pointer disappears when over any of these windows, and since my mixer uses a multiple of windows onscreen, this makes the program more difficult to control, cause one can easily lose the mouse pointer... Is there anyone with knowledge of pdp source who knows how to fix this problem, Id really appreciate also any info as to why, technically, the pointer disappears, because then maybe I can fix this myself? Thanks, Gert De Roost ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
No ideas on this one? It is a serious bug since it means that arrays stop being drawn at all when banged often than 100ms. .hc On 10/08/2012 12:26 PM, Hans-Christoph Steiner wrote: I've noticed that if you bang a [tabwrite~ array1] more often than about 100ms, the array that its writing to will not send updates to the GUI. It seems that its a kind of a fade out with [metro 100] seems to send all updates, [metro 98.8] send some updates and [metro 95] sends basically none. Any ideas what could be causing this? I didn't see anything. This happens on 0.42.5, 0.43.4 and pure-data.git master. Attached is patch to demonstrate this. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] converting OSCx to a template library
On 10/20/2012 04:07 AM, IOhannes m zmölnig wrote: On 10/20/2012 01:26 AM, Hans-Christoph Steiner wrote: I'm not going to take on the maintenance of those patches, so just copying them into Pd-extended is not an option. I'm think Pd-extended should have an 'oscx' compatible library , and 'oscx' is already there, tested, etc. etc means known to be buggy unmaintained. i'm not arguing against OSCx because of it's architectural flaws but because it's not working as it should. I'd happily ditch it if there was a drop in replacement. For example, I've had many students come to me with the most popular Processing -- Pd starter patch, and its based on oscx. If it wasn't include, that patch would not work at all. So buggy but working is still better than not at all. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
