Pd-dev July 2015

pd-dev@lists.iem.at

13 participants
9 discussions

auto-build server not synced with svn
by Fred Jan Kraan 28 Nov '15

28 Nov '15

Hi, After checking in some changes for cyclone, I hoped to see the results in the last remaining daily build, the Pd-0.44.0-extended-20150104-debian-wheezy-amd64.deb <http://autobuild.puredata.info/auto-build/2015-01-04/Pd-0.44.0-extended-201…>. But it appears it is no longer synced with the svn repository and builds the same code every day. To make sure the state of cyclone code is still ok, I checked out the repositry and recompiled. Cyclone is ok, but some other libraries fail: ./pure-data-svn/externals/iem/iem_ambi/src/ambi_decode2.c:7:20: fatal error: iemlib.h: No such file or directory ./pure-data-svn/externals/iemlib/iemlib1/src/biquad_freq_resp.c:8:20: fatal error: iemlib.h: No such file or directory ./pure-data-svn/externals/iem/iem_delay/src/block_delay~.c:7:20: fatal error: iemlib.h: No such file or directory loaders-pdlua: pdlua.c:45:17: fatal error: lua.h: No such file or directory gem: TextBase.h:38:22: fatal error: FTFont.h: No such file or directory For the loaders-pdlua library I found it expects the lua.h in /usr/lib/lua/ while the actual directory is lua5.2. This is on Xubuntu 14.04.1 LTS x86_64 Fred Jan

5 6

Re: [PD-dev] Pd-dev Digest, Vol 124, Issue 2
by Dan Wilcox 20 Oct '15

20 Oct '15

This is exactly what we were *nudging* for. It's not a movement against, just a growing process. The SVN has served it's purpose but now a more decentralized approach works since the tools and dev approach have changed. I created the "pure-data" GH group as an umbrella for this kind of development, so we could think about moving generally useful & actively support externals there. Then anyone can do a PR or be given externals development access via GH groups, etc without worrying about "stepping on anyones toes" or being stuck with something on their personal account. Original authors, of course, are free to take over their own projects and move them if they want, but there are definitely cases of externals which have become more community developed. A centralized SVN repository with all externals in it seems like it has > been a point of friction in the Pd development ecosystem. > > You could set up your stuff in Github repositories, and if somebody > wants to continue to use SVN and also wants your fixes then they can > figure out how to merge them back. I would make contact with people who > are doing packaging of the externals for distributions and tell them > that you have versions of those externals with newer modifications and > they can decide whether to continue to use the SVN version or your newer > versions with changes. > > Hm, maybe this is too aggressive a strategy, I don't know. > > In any case, I don't think there is anything inherently wrong with > forking code and putting it in a Github repository and making > improvements. That's basically the whole point of FLOSS. Then if people > want to use your new versions, great. > -- Dan Wilcox @danomatika danomatika.com robotcowboy.com

10 38

Compiling externals for Windows
by Roman Haefeli 26 Jul '15

26 Jul '15

Hey all The new deken plugin makes me want to compile externals for Windows. There seem to be many ways to go and I might save some time if I knew beforehand what works and what no so well. I have access to the following archs: * Debian 7 (i386, amd64, armv6l) * Debian 8 (i383, amd64) * Ubuntu 14.04 (i386, amd64) * Windows XP (w32) What are people using? Are you compiling directly on Windows or are you cross-compiling from Linux? Are you going with the tool chain from your Distro or are you downloading the highest and latest manually? On a related note: How feasible is it to cross-compile for Mac OS X? Roman

8 26

sourceforge...
by IOhannes m zmoelnig 21 Jul '15

21 Jul '15

due to the continued outage of the sourceforge repository service, i wonder whether anybody has a *complete* backup (including the entire history) of the Pd repository? if somebody has a recent checkout of the entire tree (or at least trunk) they might want to make a backup as well. just in case... mfgasd IOhannes

5 5

[pure-data:feature-requests] #143 Option to rescan Midi Devices?
by William Huston 11 Jul '15

11 Jul '15

--- ** [feature-requests:#143] Option to rescan Midi Devices?** **Status:** open **Group:** Next Release (example) **Created:** Sat Jul 11, 2015 03:53 AM UTC by William Huston **Last Updated:** Sat Jul 11, 2015 03:53 AM UTC **Owner:** nobody I am using PD 0.43.4-extended on Windows 7. If I start PD without my MIDI controller attached, there is nothing I can find to get PD to see it. I must start PD with the MIDI controller attached. Is it possible to ask PD to "rescan MIDI devices" while it is running? Thanks BH --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

Makefile.pdlibbuilder 0.0.0 on github
by katja 07 Jul '15

07 Jul '15

After a few months of puzzling and testing it was time to push Makefile.pdlibbuilder onto a public repository (before rumours would become too embarrassing): https://github.com/pure-data/pd-lib-builder Makefile.pdlibbuilder is a one-size-fits-all helper makefile for Pd external libraries. A build system in this approach will typically have two makefiles: 1 - Makefile - defines input files and other library-dependent variables 2 - Makefile.pdlibbuilder - defines library-independent paths, flags and build rules for Pd lib building You can think of this approach as a template split in two parts - specific and generic. Your Makefile is the specific part, to be updated when you make changes in your library. Makefile.pdlibbuilder is the generic part, to be updated in response to external conditions like OS and hardware developments. This partitioning makes it easy to (collectively) improve the generic part of the build system, and upgrade by simple file replacement. Makefile.pdlibbuilder is conceived in the same spirit as Hans Christoph Steiner's Makefile Template, but differs from it in several aspects (apart from the partitioning). It does not assume the strict libdir layout as described in https://puredata.info/docs/developer/Libdir. Source files (multiple) and link flags may be defined per class. C and C++ are both supported. For exact info read Makefile.pdlibbuilder's internal documentation paragraphs. The version number of this first public release is set at 0.0.0 to express that Makefile.pdlibbuilder's life as a community project starts here. It doesn't mean that this version is totally unstable. In the course of testing with ~60 libraries on 7 platforms, the 'API' was reconsidered a few times, but is now well defined. Discussions about flags, default paths and priorities thereof are to be expected however. Also, source packaging targets aren't implemented yet. And hopefully there's an interest to add platform definitions, for cross compiling in particular. You may wonder why those ~60 library test makefiles (written by Fred Jan Kraan) won't be published as such. Briefly: while it takes a few minutes to write a library makefile for the Makefile.pdlibbuilder approach, it takes a few hours or days to build and test a single library on 7 platforms and make sure that the build result is identical to that of the original build system. In some cases it is hard to understand what the original build system means to build and install, and there is a huge variety of build methods among Pd-extended libs. Fred Jan's test makefiles mainly served to figure out the requirements for Makefile.pdlibbuilder. We concluded that most libraries could be accommodated, including the rather complex case of cyclone. Libraries which need to check dependencies before building are still better served by Autotools. Katja

1 0

maintenance of builds for deken
by Roman Haefeli 07 Jul '15

07 Jul '15

Hey all I compiled some externals for several platforms to be used with Deken. Now, I'm thinking about stream-lining the process and I stumble across some culprits and I still have lots of questions. Here the list of externals / libraries I'm interested in maintaining builds: iemnet osc (mrpeach) slipdec / slipenc (mrpeach) ggee zexy readdir (moocow) The platforms I intend to support: Linux-i386 Linux-amd64 Linux-armv6 Windows-i386 (I'd love to support OS X, but have little knowledge and no access to an OS X machine). Currently, the different libraries use different build tools. Many use the template Makefile, some others like readdir come with their own autotools setup (which uses ancient defaults, btw). Slipdec/slipenc don't have any Makefile at all (probably they're meant to be part of mrpeach library) but compile fine with the template Makefile. Also, there is Katja's new standard Makefile available, which is obviously actively maintained and thus I'd prefer to use that instead of the template Makefile in svn. Now, before I dig too deep into stuff, I'd like to hear some opinions from pd-dev. First, how feel people about me maintaining builds of their source code? It seems for most externals no one maintains builds, that is why I'd like to do it. Zexy already is available in Deken, but shows up with weird, non-standard names. I don't need to maintain zexy separately, if you - IOhannes - have intentions to do that yourself. Also, there is the old rule, that devs only commit to their own folder in svn. Now, some parts haven't been touched for years and it seems cumbersome for everyone involved to make requests to the original author to apply certain changes. Should I commit my changes (build system stuff) directly to svn (i.e. by ignoring that rule)? Or would it be better, we move the maintained stuff out of svn and host them as git repository under the pure-data umbrella on github.com? Or am I better of with just doing my stuff privately (as I did for now)? I don't want anyone to think I plan to take over "their stuff". I happily continue if no one minds, but if the authors of the listed libraries prefer to maintain builds themselves, please just say so. Roman

3 3

[pure-data:bugs] #1213 pd-msg -> toggle, send message weirdness
by Ticket 1213 04 Jul '15

04 Jul '15

--- ** [bugs:#1213] pd-msg -> toggle, send message weirdness** **Status:** open **Group:** v0.46 **Labels:** dynamic patching toggle **Created:** Sat Jul 04, 2015 04:12 PM UTC by Anonymous **Last Updated:** Sat Jul 04, 2015 04:12 PM UTC **Owner:** Miller Puckette When I create a toggle with a message,say, ; pd-patch.pd obj 10 10 toggle send symbol send_route the send path doesn't work unless I right-click on the toggle and see the properties. --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to http://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at http://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

[pure-data:bugs] #1212 [declare -stdpath] does not work on Windows
by Roman Haefeli 04 Jul '15

04 Jul '15

--- ** [bugs:#1212] [declare -stdpath] does not work on Windows** **Status:** open **Group:** v0.46 **Created:** Sat Jul 04, 2015 11:37 AM UTC by Roman Haefeli **Last Updated:** Sat Jul 04, 2015 11:37 AM UTC **Owner:** Miller Puckette [declare -stdpath] doesn't expand any paths (or at least not the expected ones) on Windows. When using [declare -stdpath extra/osc] in Linux, [packOSC] can be loaded (at least) from the following locations: /usr/lib/pd/extra/osc /home/user/pd-externals/osc When using [declare -stdpath extra/osc] on Windows XP, [packOSC] is not found, while osc is installed in one of those folders: C:\Documents and Settings\user\Application Data\Pd\osc C:\Program Files\Common Files\pd\osc <pd-install-path>\extra\osc However, when Pd is installed in C:\Program Files\pd, this _is_ searched: C:\Program Files\pd\extra\osc (but not the other standard paths). There seems to be no issue with the -stdlib flag. When using [declare -stdlib extra/zexy], zexy objects can be instantiated when zexy is installed in one of those locations: C:\Documents and Settings\user\Application Data\Pd\zexy C:\Program Files\Common Files\pd\zexy <pd-install-path>\extra\zexy --- Sent from sourceforge.net because pd-dev(a)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.

1 0

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 2015