Pd-dev February 2015

pd-dev@lists.iem.at

12 participants
8 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

[pure-data:bugs] #1191 Language setting
by Ticket 1191 26 Feb '15

26 Feb '15

--- ** [bugs:#1191] Language setting** **Status:** open **Group:** v0.46 **Created:** Thu Feb 26, 2015 09:29 AM UTC by Anonymous **Last Updated:** Thu Feb 26, 2015 09:29 AM UTC **Owner:** nobody I just installed, in English. The program is in Danish. Admittedly I am in Denmark on a computer bought here, but there are lots of us here who don't speak the language. --- 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

HD support in Pd
by BEB Digital Audio 23 Feb '15

23 Feb '15

Hello everybody, I have just joined the Pd-dev list and I would like to introduce myself : I am one of the member of the MMA HD development group (amongst other things related to MIDI and RTP-MIDI developments ;-) ) As you probably heard, the MMA has presented officially this new protocol during the NAMM2015 : http://www.midi.org/aboutus/news/hd.php This has been announced also on other places with some further details : http://www.synthtopia.com/content/2015/01/16/new-midi-hd-protocol-has-reach… So now, why am I here? The reason is simple : there is already a Max/MSP implementation of HD (still not public, because of the MMA NDA of HD, still active until HD is officially released in public domain), but no Pd... (By the way, it's not the only existing implementation of HD, believe me ;-) . Those who went to NAMM2015 could see a few other ones) I have taken a look to the possibility to include HD support in Pd (since I am the creator of the HD Max externals), but there is currently a huge stone in the middle of the road : HD is exclusively based on 32 bits unsigned integer atoms... so it's simply impossile for now to encode HD messages in Pd because of the restricted range of integers (due to the use of float for numbers). It would be eventually possible to use 64 bits version, but this would restrict Pd with HD support to "high end" platforms (and I like the idea of running Pd on small 32 bits platforms) Note that HD can be transported over normal MIDI (and MIDI can be transported over HD too :-) ), so it's also possible to use this as a solution... but knowing that shortest HD message is 3 atoms long (12 bytes...), this would quickly lead to messy patches to handle HD in current Pd. So, here is my question : what would Pd community think of including 32 bits native support in Pd? I know that it would mean a HUGE change in the code (basically it's implementing a new type!) but I would not like to see Pd being pushed out of HD just because it would be painful to implement 32 bits message Benoit

4 5

[pure-data:feature-requests] #142 PD on Raspbery Pi 2
by Ticket 142 21 Feb '15

21 Feb '15

--- ** [feature-requests:#142] PD on Raspbery Pi 2** **Status:** open **Group:** Next Release (example) **Created:** Sat Feb 21, 2015 01:48 PM UTC by Anonymous **Last Updated:** Sat Feb 21, 2015 01:48 PM UTC **Owner:** nobody Would like to see current PD working on a Raspberry Pi 2 with GPIO. Perhaps it is possible to take advantage of the faster quad-core CPU ALSO!!!! GPIO starting addresses have moved and DMA has changes breaking real world interfacing --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to http://sourceforge.net/p/pure-data/feature-requests/ To unsubscribe from further messages, a project admin can change settings at http://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

pd osx brew-cask permissions error
by me.grimm 08 Feb '15

08 Feb '15

Hi All, I tried to add pd (millers vanilla) to homebrew/caskroom yielding some errors. Here is what the developers say: "Hey there! This repros for me locally, looks like Pd-0.46-5-64bit.app comes out with permissions 555 dr-xr-xr-x 3 phinze staff 102B Jan 19 17:43 Pd-0.46-5-64bit.app So the cleanup operation after extraction is failing to remove the temporary dir. Would it be possible to work with the maintainers of pd to get them to repackage their tarball with proper permissions? If not we can look into seeing if Cask can proactively chmod all extracted tarballs, but that seems like overkill if we can just get the maintainers to help us out." what do we think? thanks! m -- ____________________ m.e.grimm, m.f.a, ed.m. syracuse u., tc3 megrimm.net ____________________

3 5

[pure-data:bugs] #1190 Search bar for help in yosemite does not work
by Ticket 1190 07 Feb '15

07 Feb '15

--- ** [bugs:#1190] Search bar for help in yosemite does not work ** **Status:** open **Group:** v0.46 **Created:** Sat Feb 07, 2015 06:49 AM UTC by Anonymous **Last Updated:** Sat Feb 07, 2015 06:49 AM UTC **Owner:** nobody --- 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

Re: [PD-dev] [PD] more about float limitation
by katja 05 Feb '15

05 Feb '15

Miller, I still have 100+ pages of (handwritten, Dutch) notes on Pd-double. If you're serious about making precision-related modifications to vanilla Pd I'll start re-reading these notes because it's a while ago and not all issues were trivial or self-evident. The page www.katjaas.nl/doubleprecision/doubleprecision.html doesn't document the implementation details. Katja On Tue, Feb 3, 2015 at 7:37 PM, Miller Puckette <msp(a)ucsd.edu> wrote: > The diffs are helpful - I would probably want to go and re-do all the > edits by hand to be sure I understand everything. A couple of things > probably will need tweaking to get it all up to date too. > ...

3 2

Re: [PD-dev] [PD] more about float limitation
by IOhannes m zmölnig 04 Feb '15

04 Feb '15

moving this to pd-dev.... On 02/03/2015 06:16 PM, katja wrote: > has for using Pd. When working on Pd-double in 2011 I was interested > in 'scientific' applications of Pd like impulse response measurement, > where double precision is crucial in some calculations. My current > focus is more on live performance and I've never felt a need for > doubles in this realm. Still I would be happy to help out with i cannot help thinking of chun's really nice expr~ live-coding set and the problem he experienced with the lack of precision (iirc, his [wrap~] based counters would eventually become inaccurate in timing...which turns into a problem if your minimal techno base drum get's out of sync...) anyhow. > 1. graceful handling of binary incompatibility between core <> > externals of different precision [...] > Regarding binary incompatibility between builds of different > precision, this is a serious problem which can't be resolved under the > quick-and-easy approach of specifying t_float at compile time. I would the main problem seems to be, that an external can register a new double-precision object-class to a single-precision pd-runtime (or vice versa, though the former case will lead easier to segfaults). how about this simple suggestion: a double-precision pd-runtime will only add new classes, if they are registering themselves with "class_new64()" rather than "class_new()". using a preprocessor macro, we can change the "class_new" to "class_new64" in case the user is compiling for double precision. the pd-runtime shall always support class_new64() but throw a warning when called in a single-precision build something like: <m_pd.h> EXTERN t_class *class_new32(...) EXTERN t_class *class_new64(...) #if PD_FLOATSIZE == 64 # define class_new class_new64 #else # define class_new class_new32 #endif </m_pd.h> <m_class.c> t_class*class_new_doit(...) { /* put the actual implementation of the class registry in here */ } t_class*class_new32(...) { #if PD_FLOATSIZE != 32 verbose(1, "not registering single-precision class"); return 0; #endif return class_new_doit(...); } t_class*class_new64(...) { #if PD_FLOATSIZE != 64 verbose(1, "not registering double-precision class"); return 0; #endif return class_new_doit(...); } #undef class_new t_class*class_new(...) { /* legacy way to register (single-precision) classes */ return class_new32(...); } </m_class.c> afaict, the only thing left is to make sure that Pd handles NULL-pointers as classptrs gracefully in the other class_... functions (class_addbang()) - that is: ignores them. gfmsadr IOhannes

4 10

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 February 2015