Pd-dev September 2017

pd-dev@lists.iem.at

6 participants
7 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

Re: [PD-dev] message crash when using menuclose on patch
by Dan Wilcox 22 Oct '17

22 Oct '17

I'm not really a huge fan of dynamics patching for this as simply open and close seems so much cleaner. That being said, I wish there was a vanilla way to close an open patch using it's $0, etc. That's more of a matter for my suggestions for a more general canvas info etc object... The funny thing is that I never experienced this issue before, way back to the original system running in 2006. I think the difference is the hardware was slower, so the list might have been traversed before the patch was closed whereas now the patch closes more quickly while the message is mid-list. Or vice versa. I haven't experienced this with Pd-extended either and have played many shows, including the one in Nov at the Pd-con. It's only with trying to adapt this setup to vanilla that I'm running into things. (Yes, I've still been using extended for some older sets but am transitioning now.) Maybe this is something fixed in extended? > On Sep 28, 2017, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > That said, I think that @Dan could use dynamic patching; I've just > successfully tested creating/destroying abstractions every 5 millis, while > the abstractions were forwarding a value updated every millisecond from > master patch, without any crash. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 5

message crash when using menuclose on patch
by Dan Wilcox 27 Sep '17

27 Sep '17

I've been trying to track down a bug which crashes pd when switching song patches in my performance system. I first recall seeing this with 0.47-1 and never had a problem before with Pd-extended. It's a showstopper and keeping me from using PdParty for what I built it for. Basically, I have a main performance patch for audio io, playlist management, transport control, and OSC communication. Songs are separate patches that are opened and closed when running through the playlist using the "pd open $file $dir" and "pd-PatchName.pd menu close 1" messages. The song patches communicate with the performance patch via send and receive objects. The problem comes where sometimes closing a patch leads to a crash. I've tested numerous approaches and opening is not a problem, only the close message. Digging through with the debugger shows the crash generally happens in pd_typedmess and it seems as though messages being sent to the global send objects between the patches are being processed in a patch even after it was just closed which ends in a BAD_ACCESS. At least that's as far as I've been able to figure things out. I can provide backtraces, etc. I'm hoping to figure this out as I've been wanting to develop for and use my newer system but this is really killing any chance so far. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 4

Remove "make app"?
by Dan Wilcox 26 Sep '17

26 Sep '17

Now that the 0.48.0 release is distributed with TK 8.5, perhaps we should remove the "make app" build target and the old version of Wish included with the sources. I added this originally as a quick way to get a "canonical" mac build, but this is no longer the case and the documentation we have now is pretty full featured on how to call the mac/osx-app.sh script directly anyway. Any thoughts? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

TCL_*_VERSION variables
by Dan Wilcox 22 Sep '17

22 Sep '17

Where are the TCL_MAJOR_VERSION, TCL_MINOR_VERSION, & TCL_BUGFIX_VERSION set? There are listed as globals in pd-gui.tcl and don't seem to be set on mac when running Pd from the command line. I'm trying to check the BUGFIX version in order to detect if the buggy 8.5.9 is being used on macOS. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 7

Re: [PD-dev] atoms not same height as objects?
by Dan Wilcox 21 Sep '17

21 Sep '17

No, I was thinking more for the filled object boxes, colors, etc. The sizing of things would be the same since, as you point out, it's a nightmare if the sizing stays different. In any case, I'm walking back a bit to port the sizing stuff first as I feel there are probably better ways to handle color & fill without hardcoding two headers (or such) with values. > On Sep 21, 2017, at 10:19 AM, pd-dev-request(a)lists.iem.at wrote: > > so people are supposed building their GUIs to be pixel-by-pixel correct > (because this seems to be what many here *want* to do), and then we have > a flag to destroy their attempts? > and when you hand out your patches, there's a README saying that "this > patch must be opened with the '-style extended-is-the-new-legacy' to > look correctly"? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

atoms not same height as objects?
by Dan Wilcox 21 Sep '17

21 Sep '17

Is there a reason why atoms and slightly shorter in height than object boxes, at least on macOS? I'm not asking for the technical reason, as I know in the code why this is, but more the conceptual reason, or is it a bug? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

5 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 September 2017