Pd-dev December 2017

pd-dev@lists.iem.at

16 participants
21 discussions

IEM GUI position & size
by Pierre Guillot 07 Dec '17

07 Dec '17

With libPd, calling the getrect function of the IEM's GUIs gives coordinates that seem to be slightly different from what is really drawn. I've seen in the Github PR 227 ( https://github.com/pure-data/pure-data/pull/227), that the IEM's GUIs have been updated. Do the size and the position of the objects has changed? The Pd submodule of libPd is behind Pd vanilla, so in this case I should wait before trying to correct these small offsets in my code. If changes has been made, does it respect now the Purr-Data "expectations" (see https://git.purrdata.net/jwilkes/purr-data/issues/243#note_1995)? Cheers (an thanks for the work!) Pierre

1 1

Re: [PD-dev] 0.48-1 release plans
by Dan Wilcox 05 Dec '17

05 Dec '17

Sounds good. Let me know if I can help, ie. merge some of the various PRs into a single PR. > On Nov 30, 2017, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > I put this right in 'head' on a clone of my own repo; it compiles OK for me > here on linux/64 and widows-32 so I think it's provisionally working, but needs > lots of testing. > > If there's no reason not to I'll just throw that all in my own 'head' and push > it all back to the git repo. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 11

comment endlines
by Dan Wilcox 04 Dec '17

04 Dec '17

I know this comes up from time to time, but I think it would be great if comments would support saving end line characters. The canvas clearly supports it as I can paste in multiline text and it looks great. The end lines are of course gone when reloading the patch. Since their is already the convention for escaping semis and commas, maybe all we need is to escape and end line. Something like \n? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

expose midi parser?
by Dan Wilcox 04 Dec '17

04 Dec '17

Part of my motivation to work on Pd's internal midi parsing was to find a way to use t_midiparser within libpd. What would be a good way to expose t_midiparser for this? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 4

debian folder?
by Dan Wilcox 04 Dec '17

04 Dec '17

(This is more of a question for IOhannes.) Is the debian folder in the Pd git repo used for anything at this point? It seems pretty old, although the info may not have needed any changes. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

noise~ inlet?
by Dan Wilcox 04 Dec '17

04 Dec '17

What does the inlet for the [noise~] object do? It's not mentioned in the help file... -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 8

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] Pd macOS app naming
by Dan Wilcox 01 Dec '17

01 Dec '17

I can add the architecture to the info string, although I believe IOhannes is adding/has added support for the pd core to send it's compiled arch tire info to the GUI. This is mainly for deken but it would be helpful in general. The other way to do this is to use the file command ala: file /Applications/Pd-0.48-0.app/Contents/Resources/bin > On Dec 1, 2017, at 6:44 PM, pd-dev-request(a)lists.iem.at wrote: > > Date: Fri, 1 Dec 2017 12:44:21 -0500 > From: Federico Camara Halac <camarafede(a)gmail.com <mailto:camarafede@gmail.com>> > Cc: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Pd macOS app naming > Message-ID: > <CAO_HSB4w9V-tneT7cYcEwNd8=JWUB_Av0gzdetv7_GDX=03XVw(a)mail.gmail.com <mailto:CAO_HSB4w9V-tneT7cYcEwNd8=JWUB_Av0gzdetv7_GDX=03XVw@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Pd.app would be fine, yes. But, i think some flag should be added to > distinguish 32 from 64 bit versions, like the current *-i386.app one, or > simply Pd-32.app. This would be helpful when using Gem on OSX, for example. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

Pd macOS app naming
by Dan Wilcox 01 Dec '17

01 Dec '17

Howdy all, Now that the Pd mac app bundle is built with the version info included, we could consider dropping the version name from the app bundle name and just use "Pd.app" or "PureData.app". For comparison, Pd extended uses "Pd-extended.app". The versions are differentiated by the OS using the info in the app's plist automatically and users can see the version info in Finder's Get Info dialog. The only downside is users who have multiple versions of vanilla on their systems will need to manually rename the app bundle if they want to keep these versions together in the /Applications folder. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 3

question about current directory
by Dan Wilcox 01 Dec '17

01 Dec '17

I'm noticing that pd and the pd-gui seem to have different notions about the current directory: * pd: when started on commandline, current path is the working directory when pd was started * pd-gui: when started before pd, current path for panels is $::env(HOME) aka home directory ... even though *actual* current dir is pd bin folder The problem I'm noticing is that pd-gui's "current path" is only reflected in [openpanel] & [savepanel] while the *actual* tcl current path is different. On macOS, starting Pd by double-clicking a patch sets the cwd to the parent folder of that patch, so relative start directories to a panel work as expected. Opening Pd and then opening the patch leads to different behavior as the actual current working directory is not the same as that of the patch. In this second example, there is also a disparity between what you see when baking an [openpanel] and what relative paths it might find since the displayed location is *different* from the actual location. I see 5 possible solutions: 1. EASY: append any relative paths from [openpanel] / [savepanel] to the current panel directories ($::fileopendir / $::filenewdir) 2. EASY (but could lead unexpected behavior): change directory to the $::fileopendir on startup when the GUI is started first and without any specific location (aka opened a patch) 3. EASY (but not user friendly): do *not* set $::fileopendir / $::filenewdir to anything other than the tcl [pwd] 4. HARDER (but more user friendly): [openpanel] / [savepanel] could append relative paths to the current canvas path 5. HARDER (but more generally useful): add the ability to query the canvas path in order to build proper fullpaths to give to [openpanel] / [savepanel] Maybe the best solution is a mix of 2-3 of the above? In any case, I can implement 1-4 relatively easily. IMHO #4 is the better way to go, although it would mean using [openpanel] within an abstraction using the abstraction's parent directory with relative paths... This probably also touches about path expectations when using [soundfiler] and [readsf~]... -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 2

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