Pd-dev July 2010

pd-dev@lists.iem.at

20 participants
139 discussions

Re: [PD-dev] Join the Compile Farm (was Re: 64-bit build for, Windows?)
by Hans-Christoph Steiner 09 Jul '10

09 Jul '10

Its not as complicated as it looks, its mostly a matter of getting the files in the right places. You should also install MSYS, check the WindowsMinGW page for how. But perhaps you should use a newer version of MSYS. Then try a build, download the Pd-extended source, and do this from the MSYS shell: cd pd/src make -f makefile.mingw My guess is that the 64-bit instructions are going to end up looking quite similar to the WindowsMinGW page. .hc On Jul 8, 2010, at 3:38 PM, Pierre-Olivier Boulant wrote: > Hello Hans and everyone, > > Thank you for the encouragment. It might take time, indeed. :) > > OK, I installed the tdm-gcc.tdragon.net x32 and x64 MinGW. > > > > On 08/07/2010 21:09, Hans-Christoph Steiner wrote: >> >> Working on this is definitely not a waste of time, but it is not a >> simple project. We all start somewhere, so motivation is the key >> rather than skills. >> >> I would avoid trying to build anything and instead install from >> binaries. Building compilers can be a real pain. Cygwin is quite >> easy to install, so I see no harm in installing it. >> >> I created a wiki page to document our progress, everyone should >> write notes there: >> https://puredata.info/docs/developer/Windows64BitMinGWX64 > >> >> Upon looking at it, I think a good place to start is by downloading >> the most recent of mingw-w64-bin-x86_64: >> >> http://www.drangon.org/mingw/ >> >> This looks even more promising though: >> http://tdm-gcc.tdragon.net/ > >> >> .hc >> >> On Jul 2, 2010, at 6:10 PM, Pierre-Olivier Boulant wrote: >> >>> Hello everyone, >>> >>> I'm new here. I've offered to help with the Windows 64bit build. >>> I'm really new to compiling software, so I'll probalby need some >>> help to get started. If you think this is unmanageable for a >>> beginner don't be afraid to tell me so. I have some good will and >>> patience, but I don't want to waste anyone's time. :) >>> >>> >>> I'm reading the MinGW-w64 pages on Sourceforge. >>> I should be looking for a native compiler for w64, but I can't >>> seem to find any. I suppose since it's a native compiler I can >>> build it myself. Is this correct. Then, should I download a >>> tarball and compile from the source? >>> Otherwise I found what seems to be a native version here: >>> http://www.drangon.org/mingw/ >>> >>> I cannont find either the MinGW-get installer mentioned on the >>> 32bit version of the instructions. I suppose there is nothing >>> similar for the 64bit version for the time being. >>> >>> >>> I suppose I have to get Cygwin for compilation too. Anything I >>> should pay special attention to concerning this? >>> >>> >>> Thanks for your help >>> Pierre-Olivier >>> >>> >>> >>> On 02/07/2010 22:46, Hans-Christoph Steiner wrote: >>>> >>>> A Windows 7 build sounds like a good idea. The first place to >>>> start is getting a MinGW-w64 build environment setup. If you get >>>> that installed, then first try just building the core of pd- >>>> extended without all the libraries. That shouldn't be too hard >>>> to get going. >>>> http://mingw-w64.sourceforge.net/ >>>> >>>> Here is the whole instructions for the 32-bit environment: >>>> http://puredata.info/docs/developer/WindowsMinGW >>>> >>>> Perhaps it makes sense to continue this discussion on pd-dev? >>>> >>>> .hc >>>> >>>> On Jul 1, 2010, at 4:56 PM, Pierre-Olivier Boulant wrote: >>>> >>>>> Hello, >>>>> >>>>> I've been using Puredata for a year now and I'd be glad to help >>>>> with the new release. >>>>> I'll be getting a new computer for performances in the coming up >>>>> week. >>>>> >>>>> It will be an Asus N82 (it's not on their website at the moment). >>>>> Intel Core i7 - 720QM (quad core) with 4GB of RAM an Nvidia >>>>> Geforce GT335M >>>>> The OS is a Windows 7 64bit. I might install some linux distro >>>>> too alongside the original OS. >>>>> >>>>> I can leave the computer on as much as needed for the autobuild >>>>> process. I will use the computer for my own too. But I can leave >>>>> it on at night. >>>>> >>>>> I don't know if you want specifically Windows XP or if Windows 7 >>>>> which is more and more widespread now can do too. >>>>> >>>>> You can contact me with this email or with skype (same email >>>>> address). >>>>> >>>>> Cheers >>>>> Pierre-Olivier ---------------------------------------------------------------------------- All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne

2 4

Re: [PD-dev] Join the Compile Farm (was Re: 64-bit build for, Windows?)
by Pierre-Olivier Boulant 08 Jul '10

08 Jul '10

Hello everyone, I'm new here. I've offered to help with the Windows 64bit build. I'm really new to compiling software, so I'll probalby need some help to get started. If you think this is unmanageable for a beginner don't be afraid to tell me so. I have some good will and patience, but I don't want to waste anyone's time. :) I'm reading the MinGW-w64 pages on Sourceforge. I should be looking for a native compiler for w64, but I can't seem to find any. I suppose since it's a native compiler I can build it myself. Is this correct. Then, should I download a tarball and compile from the source? Otherwise I found what seems to be a native version here: http://www.drangon.org/mingw/ I cannont find either the MinGW-get installer mentioned on the 32bit version of the instructions. I suppose there is nothing similar for the 64bit version for the time being. I suppose I have to get Cygwin for compilation too. Anything I should pay special attention to concerning this? Thanks for your help Pierre-Olivier On 02/07/2010 22:46, Hans-Christoph Steiner wrote: > > A Windows 7 build sounds like a good idea. The first place to start > is getting a MinGW-w64 build environment setup. If you get that > installed, then first try just building the core of pd-extended > without all the libraries. That shouldn't be too hard to get going. > http://mingw-w64.sourceforge.net/ > > Here is the whole instructions for the 32-bit environment: > http://puredata.info/docs/developer/WindowsMinGW > > Perhaps it makes sense to continue this discussion on pd-dev? > > .hc > > On Jul 1, 2010, at 4:56 PM, Pierre-Olivier Boulant wrote: > >> Hello, >> >> I've been using Puredata for a year now and I'd be glad to help with >> the new release. >> I'll be getting a new computer for performances in the coming up week. >> >> It will be an Asus N82 (it's not on their website at the moment). >> Intel Core i7 - 720QM (quad core) with 4GB of RAM an Nvidia Geforce >> GT335M >> The OS is a Windows 7 64bit. I might install some linux distro too >> alongside the original OS. >> >> I can leave the computer on as much as needed for the autobuild >> process. I will use the computer for my own too. But I can leave it >> on at night. >> >> I don't know if you want specifically Windows XP or if Windows 7 >> which is more and more widespread now can do too. >> >> You can contact me with this email or with skype (same email address). >> >> Cheers >> Pierre-Olivier -- ~ Pierre-Olivier Boulant ~ -o- www.puffskydd.net -o- ~ www.flickr.com/pob31/sets ~ -o- www.lepixophone.net -o-

2 2

pd_error() for udpsend, tcpsend, etc.
by Hans-Christoph Steiner 08 Jul '10

08 Jul '10

Hey Martin, I've been using udpsend/udpreceive in a project and they've been great. I have one small request, which I'd happily implement if you don't want to. For the error like "not connected", it would be very handy if they used pd_error() so that the error is findable. .hc ---------------------------------------------------------------------------- There is no way to peace, peace is the way. -A.J. Muste

3 5

[ pure-data-Bugs-3025286 ] font sizes
by SourceForge.net 05 Jul '10

05 Jul '10

Bugs item #3025286, was opened at 2010-07-05 00:41 Message generated for change (Tracker Item Submitted) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3025286&group_… 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: pd-extended Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Wilkes (jancsika1) Assigned to: Hans-Christoph Steiner (eighthave) Summary: font sizes Initial Comment: The attached patch looks different on linux, osx, and windows in pd-extended. I tested in winxp and osx using nightly builds from the past few days, but the version for testing on linux is a bit old (Pd version 0.42.5-extended-20100414). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3025286&group_…

1 0

[ pure-data-Bugs-3025233 ] widget disappears when its canvas is not visible
by SourceForge.net 05 Jul '10

05 Jul '10

Bugs item #3025233, was opened at 2010-07-04 21:11 Message generated for change (Tracker Item Submitted) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3025233&group_… 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: widget disappears when its canvas is not visible Initial Comment: Along with the [widget] object's inability to handle dollarsign variables correctly, this severely limits the flexibility of the [widget] object. For example, you can't initialize a [widget]'s values using loadbang, nor can you use one in an abstraction and send data to it (like you can with [tgl]). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3025233&group_…

1 0

[ pure-data-Bugs-3025232 ] widget doesn't handle dollarsign variables
by SourceForge.net 05 Jul '10

05 Jul '10

Bugs item #3025232, was opened at 2010-07-04 21:08 Message generated for change (Tracker Item Submitted) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3025232&group_… 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: widget doesn't handle dollarsign variables Initial Comment: If you create [widget button $1-b], the button won't be displayed (as opposed to [widget button b]). If you create [widget button $0-b], it gets saved with the value of $0 instead of \$0-b. Same thing happens with the flags: -text "$0-foo", etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3025232&group_…

1 0

[ pure-data-Bugs-3024970 ] pix_film crashes MacMini running OSX 10.5
by SourceForge.net 04 Jul '10

04 Jul '10

Bugs item #3024970, was opened at 2010-07-04 05:36 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3024970&group_… 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: pix_film crashes MacMini running OSX 10.5 Initial Comment: I’ve been working on a Puredata patch that uses MIDI input from an external device to control playback of 2 movies that are displayed in a single GEM window. I have been able to get the patch working properly on my own computer (a 2.53GHz MacBook Pro with OSX 10.6.3) but can’t get it to work on the computer where the patch needs to run (a 1.66GHz MacMini with OSX 10.5). I’ve read through the forums and archives and based on the input I have created several version of the patch (all of them have crashed on the MacMini). I couldn’t find any instance of a bug report documenting this issue so I decided to add it here. I’ve posted my code, two different approaches each with the associated full crash reports. In the first approach I use two separate Gemheads to control the movies; in the second approach I use a single Gemhead to control both movies. Please note that the download is quite large (100MB). The reason being, I have included videos in the zip files so that the application can run properly. One more important note, you need to install pdmtl in order to run the patch (as I use one of their abstractions in my patches). Link to code and crash reports: http://itp.nyu.edu/~jt1428/downloads/gem_issue/see-saw-examples.zip Any help is greatly appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3024970&group_…

1 0

Re: [PD-dev] flext
by Hans-Christoph Steiner 02 Jul '10

02 Jul '10

On Jul 1, 2010, at 12:33 PM, dmotd wrote: > hi hans, > > okay, i still have no real idea what you are talking about > here? i get the makefile template, but how exactly does this > relate to a buildsystem, the examples that use the template > are still called by the centralised makefile? yes, check ext13 externals/Makefile for example. > thomas maintains his own buildsystem and as much as its > apparently stumped a bunch of people in the past, it is > designed for cross platform AND max/msp. to redesign an > entire build system to fit a template, for sake of maintaining > some design rules seems a little over the top, that's why i > decided to simply wrap it. besides, the flext layer has enough > complexity to require a decent autoconf first, and if recent > threads are correct, there's no libdir based autoconf > template. A libdir autoconf template would be awesome to have though. Building C or C++ objects for Pd isn't hard. What about flext makes things so complicated? In the process of making that template Makefile, I realized that autotools is really rarely needed for externals. Only really when there are a lot of library dependencies. > the thing that has me confused is this notion of packaging? > if pd-X is going to disolve into a system of separated libs > (libdirs?) called by a virtual package 'pd-X', and thus > 'debianize' the entire system, then i support that - however > there must be some wrapper script that does the job that > pd-X currently does? i understand that the template is > designed to make that job simpler, by making the build > assumptions the responsibility of each lib and creating a > libdir path, but how does this actually spawn packages? > > what i like about pd-X is that it unifies a lot of extras > and provides a neat wrapper for the build, so i'm assuming > that your direction will be providing scripts to wrap > certain build environments (osx/win/fed/deb/ubu/etc). have > you got examples of how this next generation of build > scripts will look with the makefile-template, or will the > current centralised system slowly morph into the desired > endpoint? i am a little concerned that a 'one size fits all' > may not fit all... The core idea is to avoid one-size-fits-all by decentralizing the libraries. If libraries are really easy to make, distribute and install, then there isn't a strong need to have all the libraries included in Pd-extended itself. People can maintain their libraries entirely separately, removing the unavoidable roadblocks that happen when things get centralized. For Pd-extended 0.43, I think we should be removing a bunch of libraries that are not really used or maintained and make them separately distributed. You can see some idea of the plans here: http://puredata.info/dev/NextRelease That said, there is value to having a default set of libraries that you know will always be included with Pd-extended. I think to get to that point, libraries need to be very stable both in terms of their interface/features and their bugginess. Think of python libraries, or ruby, etc. .hc > anyway, without some guidelines, i'm not sure i will ever > understand what you have in mind, and what is acceptable > practice. i'm just wanting to contribute something that's > been missing from the pd-x object pool, without getting too > caught up in some fundamental change of practice. > > best, > dmotd > > Hans-Christoph Steiner wrote: >> >> The idea is to have all libraries have their own standalone build >> systems that do not rely on the packages/Makefile.buildlayout stuff. >> That's the idea with the Makefile/library template. >> >> I think the best plan for flext would be to make a version of the >> template Makefile that works for C++/flext. Then that Makefile can >> easily be used for Debian/Ubuntu/RPM/etc. packaging. >> >> http://puredata.info/docs/developer/MakefileTemplate >> >> I could see including the flext library itself in Pd-extended, that >> is if it is not changing much. But the externals itself should >> start out separately distributed libdirs IMHO. >> >> .hc >> >> On Jun 28, 2010, at 9:50 PM, dmotd wrote: >> >>> hi hans, >>> >>> the work i've done slots straight into the existing >>> externals/Makefile structure and currently builds fine on >>> linux, it uses thomas' build system and until a better >>> autoconf alternative is created, this is by far the easiest >>> (and has been working quite well for years). as such this a >>> multi-class single lib system. >>> >>> i have followed the libdir rules, with help-files >>> abstraction (and in py/ext case scriptets) in each libs own >>> dir, and other stuff in examples. the actual flext headers >>> and libs get installed in their own $prefix/include >>> $prefix/lib. >>> >>> my intention is to get the flext externals into the nightly >>> autobuid. i'm not sure what you mean by 'distribuited as >>> stand-alone', if this is a reference to your plan to split >>> supported pd-extended libs into individual packages, then >>> i'll need to know more about what scripts you have at your >>> disposal and your release schedule for this new packaging >>> system. >>> >>> i've attached a diff of my working makefile, which will need >>> to be tested against other platforms and linux >>> distributions. currently the following libs build and >>> install correctly: absattr, pool, py, xsample (i am waitinng >>> on some fixes up stream for clk and vasp) >>> >>> sorry for not emailing earlier, i've had little time to work >>> on this stuff and just ran with the momentum with the small >>> time i have had. >>> >>> cheers, >>> dmotd >>> >>> Hans-Christoph Steiner wrote: >>>> >>>> Hey, I just saw you are working flext stuff, lots of people will >>>> appreciate that. I don't know your plan, but I wanted to save you >>>> some effort. At this point, I think that the flext stuff should be >>>> distributed as standalone libraries, rather than integrated with >>>> Pd- >>>> extended. That makes it easier to package too, for things like >>>> archlinux, Debian, Fedora, etc. >>>> >>>> Also, if you are starting in on packaging things for archlinux, >>>> check out the externals/template. If you can make a template >>>> archlinux packaging file for that, then it'll be really easy to >>>> make >>>> packages for all of the libraries that use that template: >>>> >>>> http://puredata.info/docs/developer/MakefileTemplate >>>> >>>> .hc >>>> >>>> ---------------------------------------------------------------------------- >>>> >>>> News is what people want to keep hidden and everything else is >>>> publicity. - Bill Moyers >>>> >>>> >>> <flext.diff> >> >> >> ---------------------------------------------------------------------------- >> >> I hate it when they say, "He gave his life for his country." Nobody >> gives their life for anything. We steal the lives of these kids. - >> Admiral Gene LeRocque >> >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev(a)iem.at >> http://lists.puredata.info/listinfo/pd-dev ---------------------------------------------------------------------------- Information wants to be free. -Stewart Brand

3 3

Re: [PD-dev] flext
by dmotd 01 Jul '10

01 Jul '10

hi hans, the work i've done slots straight into the existing externals/Makefile structure and currently builds fine on linux, it uses thomas' build system and until a better autoconf alternative is created, this is by far the easiest (and has been working quite well for years). as such this a multi-class single lib system. i have followed the libdir rules, with help-files abstraction (and in py/ext case scriptets) in each libs own dir, and other stuff in examples. the actual flext headers and libs get installed in their own $prefix/include $prefix/lib. my intention is to get the flext externals into the nightly autobuid. i'm not sure what you mean by 'distribuited as stand-alone', if this is a reference to your plan to split supported pd-extended libs into individual packages, then i'll need to know more about what scripts you have at your disposal and your release schedule for this new packaging system. i've attached a diff of my working makefile, which will need to be tested against other platforms and linux distributions. currently the following libs build and install correctly: absattr, pool, py, xsample (i am waitinng on some fixes up stream for clk and vasp) sorry for not emailing earlier, i've had little time to work on this stuff and just ran with the momentum with the small time i have had. cheers, dmotd Hans-Christoph Steiner wrote: > > Hey, I just saw you are working flext stuff, lots of people will > appreciate that. I don't know your plan, but I wanted to save you > some effort. At this point, I think that the flext stuff should be > distributed as standalone libraries, rather than integrated with Pd- > extended. That makes it easier to package too, for things like > archlinux, Debian, Fedora, etc. > > Also, if you are starting in on packaging things for archlinux, > check out the externals/template. If you can make a template > archlinux packaging file for that, then it'll be really easy to make > packages for all of the libraries that use that template: > > http://puredata.info/docs/developer/MakefileTemplate > > .hc > > ---------------------------------------------------------------------------- > > News is what people want to keep hidden and everything else is > publicity. - Bill Moyers > >

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev July 2010