Pd-dev November 2015

pd-dev@lists.iem.at

16 participants
20 discussions

Re: [PD-dev] Pd-extended EOL?
by Dan Wilcox 11 Jan '16

11 Jan '16

Yeah, that’s what I mean. Basically so people will stop downloading an out of date extended if there is an easy way to get the same/similar functionality from a much newer version of vanilla+externals. Judging from the continued extended bug reports of things which are generally fixed in vanilla, I’m thinking it would be a good idea to see what’s needed for a transition and start that more formal conversation. -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Oct 1, 2015, at 4:00 AM, pd-dev-request(a)lists.iem.at wrote: > > If by 'relative parity' you mean availability of all the externals the > last version of Pd-extended came with, this might have been reached > already. Search for 'extended' in deken. It shows a lot of (all?) > externals directly packaged from Pd-extended. Many thanks to IOhannes > for uploading all those.

8 18

Fwd: Message Delivery Failure Was: auto-build server not synced with svn
by Fred Jan Kraan 28 Nov '15

28 Nov '15

As the message bounced on the main recepient's email address "hans(a)at.or.at", I assume a response can take a while. Or maybe someone can forward this to a working email address of Hans? Fred Jan On 2015-11-25 09:49 AM, Hans-Christoph Steiner wrote: > > If anyone wants to take over the pool of auto-build machines from me, there are 3 Debian VMs still up and running. I think the Windows one is still going too. > Looking at http://autobuild.puredata.info/auto-build/latest/ there are only three different packages produced in 2015: Pd-0.44.0-extended-macosx106-x86_64.dmg 2015-04-04 09:29 39M Pd-0.44.0-extended-debian-wheezy-amd64.deb 2015-11-25 12:56 38M Pd-0.44.0-extended-chaos.dmg 2015-02-23 23:15 39M At least the Debian wheezy package does not reflect the latest sourceforge changes, as I mentioned in my mail of Januari 5th. In the planned/current decentralized setup of Pd external libraries, I am not sure which function an auto-build machine should fulfill. Anyone can fork from https://git.puredata.info/cgit/svn2git/ and make and build a library in 'deken/pd-lib-builder' compliant format. At some time I plan to do this for some unsupported but useful libraries. >From the Pd-extended codebase, it would be interesting to extract patches from the pd-core code to make Pd-vanilla compliant with the Pd-extended help-patches. This could be based on the legendary patch-series, but I don't seem to be able to find them on sourceforge . > .hc Greetings, Fred Jan

1 0

auto-build server not synced with svn
by Fred Jan Kraan 28 Nov '15

28 Nov '15

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: ./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

5 6

Windows 64bit support
by Luke Iannini 25 Nov '15

25 Nov '15

Hi Miller! Here's a tiny patch that allows 64bit builds of Pure Data on Windows. Working wonderfully for me so far : ) Cheers Luke

1 0

Pull-request: deken plugin with commit history
by Chris McCormick 22 Nov '15

22 Nov '15

Hi Miller, I generated a branch of the deken plugin git repository with only the deken-plugin.tcl file changes in it: https://github.com/pure-data/deken/tree/deken-plugin-only I rebased it onto your Pure Data master and pushed it to GitHub here: https://github.com/pure-data/pure-data/tree/deken-plugin-history-merged To merge this into Pd you can paste the following into a terminal window inside your pure-data repository working copy: # add github as a remote git remote add github git@github.com:pure-data/pure-data.git # fetch the github remote's branches git fetch github # merge the deken-plugin-history-merged branch git merge deken-plugin-history-merged This will merge the 114 commits that lead to deken-plugin.tcl into the mainline Pd commit history linked to tcl/pd_deken.tcl thereby preserving the full commit history of the deken plugin changes. The resulting tcl/pd_deken.tcl is exactly the same as the one currently in your repository except that it has the commit history attached. You can view the full log of the changes to the plugin once merged as follows: git log --follow tcl/pd_deken.tcl I hope you'll consider doing this. Git history is important as an archival and code-history preserving mechanism - useful to futurepeople. They will examine our commit histories in minute detail from the comfort of their hover-domes I am sure! Also I want people to see my name many times in Pd's commit history so that they may know my greatness. Cheers, Chris. -- http://mccormick.cx/

3 5

[pure-data:patches] #567 prevent TCL-backtrace when using plugin-dispatch with an unknown receiver
by IOhannes m zmölnig 21 Nov '15

21 Nov '15

--- ** [patches:#567] prevent TCL-backtrace when using plugin-dispatch with an unknown receiver** **Status:** open **Group:** bugfix **Labels:** pd-gui **Created:** Sat Nov 21, 2015 10:22 PM UTC by IOhannes m zmölnig **Last Updated:** Sat Nov 21, 2015 10:22 PM UTC **Owner:** Miller Puckette **Attachments:** - [0001-check-whether-a-plugin-dispatcher-is-registered-for-.patch](https://so… (1.6 kB; text/x-diff) there's a "plugin-dispatch" mechanism built into pd/pd-gui, that provides a uniform way to send messages from pd-core (e.g. an abstraction) to a pd-gui plugin. unfortunately, the current implementation does not do any error checking, so if an abstraction assumes that a gui-plugin is installed (although it is not) and sends `[; pd plugin-dispatch foo(` (where *foo* is the receiver label of the gui plugin), then Pd will give a long and ugly **Tcl-Backtrace**, which is not very helpful to anybody. the attached patch fixes this by silently ignoring `plugin-dispatch` messages to unknown receivers (assuming that it's easy on the patch/plugin level to establish a little ping/pong handshake between patch and gui-plugin to establish the proper initialization of both, and issue an error if this is not the case). an alternative solution would be to replace the backtrace by a single error-line (though this does not allow for custom error messages :-() --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

Re: [PD-dev] [PD] [packOSC] reentrancy problem
by IOhannes m zmoelnig 20 Nov '15

20 Nov '15

On 2015-11-19 09:49, IOhannes m zmoelnig wrote: > to keep the performance of a heap allocated buffer, i would suggest to: > - use the original scheme for an "immediate" (non-recursive) message > - detect recursion, and if so, allocate buffers on the stack. attached is a patch that implements that. the patch is against current HEAD, though i really worked on HEAD~1, so it reverts a number of (imho unneccessary) things. it only touches functions that actually do output things (minus the revert-last-commit), fgmaf IOhannes

3 2

Re: [PD-dev] Canvas Dialog Apply
by Dan Wilcox 19 Nov '15

19 Nov '15

I figured it would be easier to ask just to reenable the Apply button rather than change the dialog behaviour overall. The Apply button certainly works when it’s there. That being said, I’d love to see Apple-like behavior if possible. I guess that would basically just mean adding the dialog send message to the end of edits? -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Nov 19, 2015, at 2:53 AM, pd-dev-request(a)lists.iem.at wrote: > > From: IOhannes m zmoelnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > Date: November 19, 2015 at 1:07:06 AM MST > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Canvas Dialog Apply > > > On 2015-11-19 07:04, Dan Wilcox wrote: >> I’m wondering why the apply button is not shown on Mac OS X in dialog_canvas.tcl. Editing GOP size and position is a pain since you have to edit, then hit ok, then reopen the dialog, then edit, the hit ok, repeat, etc ... >> >> Commenting out lines 211 & 215 gives me back the Apply button which works quite well. I suppose this is something to do with the Apple Human Interface Guidelines that prefer saving edits automatically on close over requiring the user to hit a save/apply button. In this case, however, the Apply button is mainly useful for live edits (it could be renamed to Update?). I suppose another option is to update the interface whenever enter is received in a text box. > > > yep, i afair that was the reason why the "apply" button was removed. > >> >> Anyway, I’d like to see the Apply button back in 0.47 :D >> > > why would you prefer that over an automatic apply for each "enter"? > > fgmasdr > IOhannes

1 0

Re: [PD-dev] Windows installer for Pd
by Dan Wilcox 19 Nov '15

19 Nov '15

Exactly. I see no reason why is has to be installer OR zip. Most open source projects provide *both* and leave it up to the downloaders. (Also, I don’t believe Roman was ever advocating for *not* providing a zip.) How does creating the installer work? Is it be a script that just bundles the build/zip file contents etc? If so, I see no reason why calling a script can’t be added to the current Windows build process that already generates a zip … -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Nov 10, 2015, at 11:53 AM, pd-dev-request(a)lists.iem.at wrote: > > From: Hans-Christoph Steiner <hans(a)at.or.at <mailto:hans@at.or.at>> > Date: November 10, 2015 at 8:03:59 AM MST > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Windows installer for Pd > > > > > IOhannes m zmoelnig: >> On 2015-11-10 11:29, Roman Haefeli wrote: >>> >>> I tried to do all the work and would welcome some feedback. >> >> i think it's one of the beautiful sides of Pd that you do *not* need an >> installer (even on windows!) and can run it from any media you like >> (even if it's a read-only CD). >> >> probably the best thing would be to have a menu-entry (maybe hidden in >> the "preferences"), where people could enable things like >> file-association and startup menus with the click of a button). > > A .zip for Windows is very useful. But that is a separate question. Windows > users expect installers. And making an installer does not prevent also a .zip > file from being made and used. Pd-extended has both for Windows. > > .hc

6 12

Canvas Dialog Apply
by Dan Wilcox 19 Nov '15

19 Nov '15

I’m wondering why the apply button is not shown on Mac OS X in dialog_canvas.tcl. Editing GOP size and position is a pain since you have to edit, then hit ok, then reopen the dialog, then edit, the hit ok, repeat, etc ... Commenting out lines 211 & 215 gives me back the Apply button which works quite well. I suppose this is something to do with the Apple Human Interface Guidelines that prefer saving edits automatically on close over requiring the user to hit a save/apply button. In this case, however, the Apply button is mainly useful for live edits (it could be renamed to Update?). I suppose another option is to update the interface whenever enter is received in a text box. Anyway, I’d like to see the Apply button back in 0.47 :D -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 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 November 2015