Pd-dev August 2017

pd-dev@lists.iem.at

12 participants
17 discussions

Re: [PD-dev] Pd 0.48 app bundle without src dir
by Dan Wilcox 04 Dec '17

04 Dec '17

It's an easy fix. I originally thought creating the app bundle with the full source tree files and the compilation step .o files was a bug and not a feature. The resulting .app is thus smaller. The app bundler script was written before the pd con and I didn't recognize the feature when presented. I'd say that if Pd is easier to build, we don't need this but I'm probably wrong. At the very least, the header directory can be named back to "src" > On Aug 15, 2017, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Dan was unaware of this when reorganizing the build scripts for the > bundle, and while I'm writing this he opened an issue suggesting a > fix: > https://github.com/pure-data/pure-data/issues/181 <https://github.com/pure-data/pure-data/issues/181> -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 26

[pure-data:feature-requests] #145 Move output~.pd from doc to extra
by Ticket 145 30 Aug '17

30 Aug '17

--- ** [feature-requests:#145] Move output~.pd from doc to extra** **Status:** open **Group:** Next Release (example) **Created:** Wed Aug 30, 2017 07:48 PM UTC by Anonymous **Last Updated:** Wed Aug 30, 2017 07:48 PM UTC **Owner:** nobody Since output~.pd in the documentation folder is such a useful abstraction would it make sense to move it to the extras folder in future distrubtions. This would help us in educational institutions that have to use enterpirse IT envrionments from having to move the abstraction a hundred times per update. Thank you. --- 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

MIDI fixes
by Dan Wilcox 29 Aug '17

29 Aug '17

FYI MIDI heads I've done some work to flesh out the Pd MIDI handling so all messages come through. I also found and fixed a pretty major bug in Portmidi on macOS which has been accepted upstream where Pm hangs when receiving a realtime message during a running status byte situation. See: https://github.com/pure-data/pure-data/pull/214 <https://github.com/pure-data/pure-data/pull/214> and my test program: https://github.com/danomatika/miditester <https://github.com/danomatika/miditester> I've tested on macOS and all values are coming in and out correctly. This needs to be tested on Linux and Windows. I also went a bit crazy and implemented song select, song position, and time code objects but that got out of hand a bit as MTC is more complicated then I originally thought. This work is in a separate branch and not included in the PR above. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD-dev] jack detection on OSX (Re: [PD] Pd-0.48 for macOS not compiled with jack support(?))
by Dan Wilcox 28 Aug '17

28 Aug '17

Jack support on macOS is contingent on the --enable-jack flag as it on all other platforms. The --disable-jack-framework flag was added to be able to control the link type on macOS as is decent upon whether jack support is enabled. That made the most sense to me while keeping existing defaults. > On Aug 28, 2017, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > On 08/28/2017 11:24 AM, Roman Haefeli wrote: >> I cannot confirm. The instructions say: >> >> ./configure >> >> but without '--enable-jack' no Jack support will be enabled, neither >> with weak linking nor without. Or do I miss something? > > i think you are right. > > looking at the code, it seems that on OSX autotools will automatically > set JACK_FRAMEWORK for you (unless overridden), but the src/Makefile.am > only checks JACK_FRAMEWORK if JACK is also set (which will *not* be set > by default). > i also wonder about the jack=xrun case. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

jack detection on OSX (Re: [PD] Pd-0.48 for macOS not compiled with jack support(?))
by IOhannes m zmölnig 28 Aug '17

28 Aug '17

On 08/28/2017 11:24 AM, Roman Haefeli wrote: > I cannot confirm. The instructions say: > > ./configure > > but without '--enable-jack' no Jack support will be enabled, neither > with weak linking nor without. Or do I miss something? i think you are right. looking at the code, it seems that on OSX autotools will automatically set JACK_FRAMEWORK for you (unless overridden), but the src/Makefile.am only checks JACK_FRAMEWORK if JACK is also set (which will *not* be set by default). i also wonder about the jack=xrun case. gfdsr IOhannes

1 0

Re: [PD-dev] Pd-ceammc
by Dan Wilcox 22 Aug '17

22 Aug '17

Ok. At the very least, I can reach out to the authors and see if they would agree to the port. > On Aug 21, 2017, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > On 2017-08-20 19:51, Dan Wilcox wrote: >> (Sending again, in thread) >> >> Even if a lot of those changes come from Pd-extended? Kind of forward-back-porting? > > this doesn't really matter. > Pd-extended itself aimed towards GPL-3, so a lot of patches for Pd might > have been distributed under that license. > > having a(ny) pedigree makes re-licensing more complicated, as the number > of parties that must agree to re-licensing increases. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 2

Re: [PD-dev] Pd-ceammc
by Dan Wilcox 21 Aug '17

21 Aug '17

(Sending again, in thread) Even if a lot of those changes come from Pd-extended? Kind of forward-back-porting? In any case, I can see a clean diff between this project and the pure-data repository on Github... > On Aug 20, 2017, at 10:09 AM, pd-dev-request(a)lists.iem.at <mailto:pd-dev-request@lists.iem.at> wrote: > > Date: Sun, 20 Aug 2017 08:09:42 +0000 > From: zmoelnig(a)iem.at <mailto:zmoelnig@iem.at> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Pd-ceammc > Message-ID: > <20170820080942.Horde.ITpcfe5IO7AJHhkCK4OZ1fB(a)webmail.iem.at <mailto:20170820080942.Horde.ITpcfe5IO7AJHhkCK4OZ1fB@webmail.iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed"; > DelSp="Yes" > > > Quoting Dan Wilcox <danomatika(a)gmail.com <mailto:danomatika@gmail.com>>: >> There could be some solutions for many things worth backporting... > > > well, they are releasing the source changes under GPL-3, so > backporting is (currently) not possible from a legal pov. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

Re: [PD-dev] Pd-dev Digest, Vol 149, Issue 15
by Dan Wilcox 20 Aug '17

20 Aug '17

Even if a lot of those changes come from Pd-extended? Kind of forward-back-porting? In any case, I can see a clean diff between this project and the pure-data repository on Github... > On Aug 20, 2017, at 10:09 AM, pd-dev-request(a)lists.iem.at wrote: > > Date: Sun, 20 Aug 2017 08:09:42 +0000 > From: zmoelnig(a)iem.at <mailto:zmoelnig@iem.at> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Pd-ceammc > Message-ID: > <20170820080942.Horde.ITpcfe5IO7AJHhkCK4OZ1fB(a)webmail.iem.at <mailto:20170820080942.Horde.ITpcfe5IO7AJHhkCK4OZ1fB@webmail.iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed"; > DelSp="Yes" > > > Quoting Dan Wilcox <danomatika(a)gmail.com <mailto:danomatika@gmail.com>>: >> There could be some solutions for many things worth backporting... > > > well, they are releasing the source changes under GPL-3, so > backporting is (currently) not possible from a legal pov. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Pd-ceammc
by Dan Wilcox 20 Aug '17

20 Aug '17

Has anyone seen this? https://github.com/uliss/pure-data Binaries here: https://github.com/uliss/pure-data/releases/tag/v2017.07 <https://github.com/uliss/pure-data/releases/tag/v2017.07> There could be some solutions for many things worth backporting... -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 2

Re: [PD-dev] libpd multiinstance issues, pd: unknown message dsp 1
by Dan Wilcox 20 Aug '17

20 Aug '17

We haven't completed really integrating the new changes in libpd yet ala an official libpd_* API that should help with these kinds of issues. If you run in good ways to isolate the instance calls so problems don't happen, let us know. Also, the current pd sources are not up to date with the 0.48 release. I will do that for now at least. > On Aug 14, 2017, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > I'm using libpd master: 9a0bbd2a2b461c8345d5df5e9d347510b37756db > > Any ideas whats up? I used to explicitly load the libpd.so into its own > memory space from a unique temp file and that worked but wasn't ideal. Real > multi instance support is going to be nice once I can get that going :) It > seems like it must be an initialization or compile flag issue? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 11

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 August 2017