---
** [bugs:#1193] Mac version of Pd is not signed**
**Status:** open
**Group:** v0.46
**Created:** Wed Mar 25, 2015 08:46 AM UTC by Anonymous
**Last Updated:** Wed Mar 25, 2015 08:46 AM UTC
**Owner:** Jamie Bullock
I guess this is very low priority, but it's also relatively easy to fix:
Downloading and running Pd on a Mac results in the following warning: "Pd... can’t be opened because it is from an unidentified developer"
This can be circumvented by "right" clicking on the app and selecting Open from there
All Mac users will get this for fresh downloads unless they explicitly set "Allow apps downloaded from:" to "Anywhere" in Security and Privacy System Preferences.
The issue can be resolved by signing the application with a valid certificate using the codesign tool
---
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.
---
** [bugs:#1192] weird behavior of [counter] in 0.43.4-extended**
**Status:** open
**Group:** v0.43
**Created:** Tue Mar 24, 2015 12:28 PM UTC by Anonymous
**Last Updated:** Tue Mar 24, 2015 12:28 PM UTC
**Owner:** nobody
Using Pd 0.43.4-extended on win7, you can reproduce this with the help file counter-help.pd
When the counter value is 0 and message [dec( is sent to the first inlet, counter value (first outlet) changes to 2.14e+009 (make the number box wider if it doesn't show the whole result). I would expect it to change to -1.
---
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.
Hi,
I have some questions regarding the MakeFile template provided in svn…
AFAICT, it is designed for two cases:
1. A single external is built for each C source file specified in the SOURCES list
2. Additionally multiple sources can be linked in a single shared library if specified in the SHARED_SOURCE list. The external object is then linked dynamically to this shared library, so we get two files: e.g. myext.dylib myext.pd_darwin
So the questions:
- Does anyone know the reasoning behind “2”? It seems unnecessarily compllicated creating the shared library
- Is there any way to use the template as it stands, to create a single external from multiple sources (without the additional shared library being created)? It seems like make LIBRARY_NAME should do it, but on OS X, this gives me the following error:
make: *** No rule to make target `libmyext.o', needed by `myext'
Thanks,
Jamie
--
http://jamiebullock.comhttp://twitter.com/jamiebullock
Hello,
Currently I am working on a one-size-fits-all build method for Pd
libs. It is meant to take the template Makefile concept to a next
level. The template is a great help for building Pd libs but it has a
few limitations:
1. source and rule definitions are together in a single file so it is
a pain to upgrade Makefiles to a new template version
2. the template can not handle multiple source files for multiple
class executables
3. implicit dependencies (headers) aren't checked
Makefile.pdlibbuilder overcomes these limitations. It functions as an
include in a Makefile which defines sources for classes. For non-clean
build of target all, Makefile.dependencies is generated. A (re)build
of individual classes can be forced alternatively.
Makefile.pdlibbuilder is in an early stage of development. I've spent
much time sorting out the best approach for
multiple-source-per-executable procedures. This is working fine now.
By way of test I used the method to compile all tilde classes in
cyclone, which are all multiple-source. It worked right away without a
single gcc error. This is promising enough for me to continue the
effort.
My aim is to make it a user-friendly method for building individual
libs against any of the 'Pd-flavours', while at the same time
integrating with Pd-extended's unified build system. There's aspects I
can't figure out on my own, some due to my lack of knowledge, some
because they need discussion to make decisions.
My first issue is with the default install path for a Pd lib. In the
template Makefile it's definition boils down to
/usr/local/lib/pd-externals/, except for OSX where it is ~/Library/Pd.
The path is overruled by Pd-extended's central Makefile, but when
building an isolated lib you get this default (which you can
eventually overrule yourself). For one thing, I'm not fond of
Makefiles installing stuff deep in a file system, so I would consider
issuing a warning message or prompt for such a case. Apart from that,
the question is to which extent the default makes sense at all. I
found this overview of standard search paths for Pd externals:
http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files
Are these search paths valid in 'all Pd flavours' (vanilla, extended, L2Ork)?
By the way I don't want to clutter Pd-dev list with attachments but if
anyone is interested I'd be happy to send Makefile.pdlibbuilder in
it's current pre-pre-alpha state.
Katja
Would this be something you’d like to put on Github? I created an unofficial pure-data group: https://github.com/pure-data <https://github.com/pure-data>
You’re thinking is right along what Chris and I have been discussing. I have a script I use to build vanilla and the extended libs I need on Udoo (attached) and we’ve been thinking of ways to have a system with links to all the external repos, etc. Anyway, I’ll throw this at you and and bring Chris in since I think he has an alpha set of scripts as well. I think we’re all talking about the same thing ...
--------
Dan Wilcox
@danomatika
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
>
> From: katja <katjavetter(a)gmail.com>
> To: pddev <pd-dev(a)iem.at>
> Date: March 8, 2015 at 6:52:38 AM EDT
> Subject: [PD-dev] Makefile.pdlibbuilder and a question about default install paths
>
>
> Hello,
>
> Currently I am working on a one-size-fits-all build method for Pd
> libs. It is meant to take the template Makefile concept to a next
> level. The template is a great help for building Pd libs but it has a
> few limitations:
>
> 1. source and rule definitions are together in a single file so it is
> a pain to upgrade Makefiles to a new template version
>
> 2. the template can not handle multiple source files for multiple
> class executables
>
> 3. implicit dependencies (headers) aren't checked
>
> Makefile.pdlibbuilder overcomes these limitations. It functions as an
> include in a Makefile which defines sources for classes. For non-clean
> build of target all, Makefile.dependencies is generated. A (re)build
> of individual classes can be forced alternatively.
>
> Makefile.pdlibbuilder is in an early stage of development. I've spent
> much time sorting out the best approach for
> multiple-source-per-executable procedures. This is working fine now.
> By way of test I used the method to compile all tilde classes in
> cyclone, which are all multiple-source. It worked right away without a
> single gcc error. This is promising enough for me to continue the
> effort.
>
> My aim is to make it a user-friendly method for building individual
> libs against any of the 'Pd-flavours', while at the same time
> integrating with Pd-extended's unified build system. There's aspects I
> can't figure out on my own, some due to my lack of knowledge, some
> because they need discussion to make decisions.
>
> My first issue is with the default install path for a Pd lib. In the
> template Makefile it's definition boils down to
> /usr/local/lib/pd-externals/, except for OSX where it is ~/Library/Pd.
> The path is overruled by Pd-extended's central Makefile, but when
> building an isolated lib you get this default (which you can
> eventually overrule yourself). For one thing, I'm not fond of
> Makefiles installing stuff deep in a file system, so I would consider
> issuing a warning message or prompt for such a case. Apart from that,
> the question is to which extent the default makes sense at all. I
> found this overview of standard search paths for Pd externals:
>
> http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files
>
> Are these search paths valid in 'all Pd flavours' (vanilla, extended, L2Ork)?
>
> By the way I don't want to clutter Pd-dev list with attachments but if
> anyone is interested I'd be happy to send Makefile.pdlibbuilder in
> it's current pre-pre-alpha state.
>
> Katja
---
** [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.
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
---
** [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.
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
____________________
---
** [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.