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:
.…
[View More]/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
[View Less]
---
** [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 …
[View More]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.
[View Less]
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-…
[View More]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
[View Less]
---
** [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…
[View More]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.
[View Less]
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? …
[View More]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
____________________
[View Less]
---
** [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 …
[View More]a mailing list, you can unsubscribe from the mailing list.
[View Less]
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 …
[View More]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.
>
...
[View Less]
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 …
[View More]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
[View Less]