Pd-dev September 2010

pd-dev@lists.iem.at

15 participants
90 discussions

Windows 64-bit build of Pd-extended
by Hans-Christoph Steiner 17 Sep '10

17 Sep '10

Hey mescalinum, I am posting your 64-bit build of Pd-extended for Windows to see if anyone wants to try it: http://dl.dropbox.com/u/89643/pd/Pd-0.43.0-x64-extended-20100915.exe Also, I was hoping you'd be up for trying a 64-bit build of the newly released Pd-extended 0.42.5. .hc ---------------------------------------------------------------------------- "We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill

1 0

[ pure-data-Bugs-3067959 ] GUI elements with "init" don't respond
by SourceForge.net 16 Sep '10

16 Sep '10

Bugs item #3067959, was opened at 2010-09-16 22:46 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3067959&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Z. Tamás () Assigned to: Hans-Christoph Steiner (eighthave) Summary: GUI elements with "init" don't respond Initial Comment: Pd version: 0.42.5-extended Windows 7 Professional, Intel Core2 Duo P8600 @ 2.4Ghz built-in sound Saved a patch with some GUI-elements (sliders) having their "init"-property turned on, so they should have initialized themselves with the previously saved position. Although they do initialized themselves, after reopening the patch, they didn't respond graphically to any interactions. Trying to interact with the objects does change their values, however, their appear to be frozen, so their graphics do not update according to their current value (sometimes they do update, when send the patch-window to the taskbar, and then bring it back...). I found, that this problem occurs, when any of the GUI elements have their "init"-proprty activated - if no element have this feature, everything works normally. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3067959&group_…

1 0

0.43 failing on "make uninstall"
by Hans-Christoph Steiner 16 Sep '10

16 Sep '10

I'm enjoying this new buildbot, its really quite nice. We now have the pure-data.git builds set up to do the build in multiple steps (git, ./autogen.sh, configure, compile, make dist, make install, make uninstall): http://128.238.56.50:8010/builders/pure-data%20Linux% 20debian-stable-i386/builds/7 One thing is caught is that it is failing on "make uninstall": http://128.238.56.50:8010/builders/pure-data%20Linux% 20debian-stable-i386/builds/7/steps/make%20uninstall/logs/stdio ...usr/local/lib/pd/extra/expr~: No such file or directory .hc

1 0

[ pure-data-Bugs-3066945 ] Display position for Contextual menu bug
by SourceForge.net 15 Sep '10

15 Sep '10

Bugs item #3066945, was opened at 2010-09-15 15:33 Message generated for change (Tracker Item Submitted) made by boonier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3066945&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: boonier (boonier) Assigned to: Hans-Christoph Steiner (eighthave) Summary: Display position for Contextual menu bug Initial Comment: Sometimes it appears randomly offset from the mouse cursor (to the left). Sometimes it appears right under the cursor (as expected). Generally I find creating a new canvas makes the menu appear normally. Does this have to do with the fact that some patches created in older versions have a 'dirty' flag or something that recreates the bug? (as it appears to work fine for newly created canvases) cheers Pd 0.42.5 extended rc6 Mac OS X 10.6.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3066945&group_…

1 0

using the MSYS and Cygwin shells on the PdLab server
by Hans-Christoph Steiner 15 Sep '10

15 Sep '10

I'm cc'ing pd-dev so others may benefit from this. There is nothing magic about the files in Cygwin and MSYS, they are all on the same file system. The problem is each system has its own root path: * in Windows, its C:\ * in Cygwin, its /cygdrive/c * in MSYS, its /c For /tmp in Cygwin, its C:\cygwin\tmp. I think MSYS uses the Windows $TEMP or $TMP location. As for ssh/scp and UNIX utils, I would stick with the Cygwin ones, they work much better. I only use MSYS for running the actual builds, and Cygwin for everything else. I'll check the home dir perms, Windows is a pain to deal with, so sorry its messed up. .hc On Sep 15, 2010, at 4:10 AM, IOhannes m zmoelnig wrote: > however, it' a bit awkward to get data into the msys shell. > is there any drive/mountpoint where i can share data between cygwin > and > msys? > > in cygwin, my ${HOME} is C:\cygwin\home\pddev > in MSYS, my ${HOME} is C:\msys\1.0\home\pddev > > in msys, it seems like i cannot access the cygwin home all, as this is > not mounted (via msys:/etc/fstab) > > in cygwin, i can cd into /c/msys/1.0/home/pddev/, but i have no > permissions to write here. > > in msys, if i open the shell using run...->"C:\msys\1.0\msys.bat" (or > Programs->MinGW->MSYS->MSYS), i get into /home/pddev (which seems to > be > C:\msys\1.0\home\pddev as well) but i have no permissions to write > either(!) > > it seems like the only place i can write to from msys, is /tmp (which > according to msys:/etc/fstab is mapped from c:/DOCUME~1/pd/LOCALS~1/ > Temp) > unfortunately i cannot access this path from neither cygwin nor from > plain "windows" (explorer, cmd), as i don't even have read > permissions. > > so i thought about using a FAT32 partition (D:), as this is the usual > way to share data on w32 systems. > unfortunately i can only access it from cygwin and win, but not from > msys. > > > > so i'm currently runing out of wit. > > or do i have to scp things from cygwin to my local machine, then put > that onto an http server and download it within msys ;-)? > ...i just noticed that there is an ssh client in msys as well, so i > could use that... > still doesn't sound very elegant to me... > > > > i guess, if only one 3rd person (apart from you and me) has ever > logged > into the machine as pddev they had the same problems solved in some > way, > but it seems i cannot do it. > > please help! > > fgmasdr > IOhannes > > ---------------------------------------------------------------------------- "Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman

2 1

[ pure-data-Patches-3065242 ] tcl-error when modifying subpatch with hidden parentwindow
by SourceForge.net 14 Sep '10

14 Sep '10

Patches item #3065242, was opened at 2010-09-13 08:00 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3065242&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: tcl-error when modifying subpatch with hidden parentwindow Initial Comment: i get tcl-errors when editing a subpatch in a GOP-enabled abstraction that has it's window closed. currently i haven't found any real consequences except for the annoying error-lines in the pd-console. cause of the bug: Pd tries to make the title of the abstraction-window reflect the "modified" state, but since there is no such window tcl throws an error. steps to reproduce: - i have an abstraction that has GOP enabled. all the code is in a subpatch of this abstraction. finally, i have a pristine instance of this abstraction in my patch. - i open the abstraction - i open the subpatch in the abstraction - i close the abstraction window - i edit the contents of the subpatch - pd-console shows an error: (Tcl) UNHANDLED ERROR: bad window path name ".x8f67d30" while executing "wm title $mytoplevel "$name$dirtychar$arguments - $path" " (procedure "pdtk_canvas_reflecttitle" line 11) invoked from within "pdtk_canvas_reflecttitle .x8f67d30 {/Net/iem/Benutzer/zmoelnig/src/git/pure-data} {abstraction.pd} {} 1" ("uplevel" body line 3) invoked from within "uplevel #0 $cmd_from_pd" ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-09-14 01:30 Message: A given $mytoplevel window is not guaranteed to be visible when pdtk_canvas_reflecttitle is called, so skip setting the title if $mytoplevel does not exist. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-09-13 08:00 Message: btw, this does not happen if the abstraction is not GOP-enabled ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3065242&group_…

1 0

Re: [PD-dev] buildbot or some other proper build automation
by Hans-Christoph Steiner 14 Sep '10

14 Sep '10

On Mon, 2010-09-13 at 17:49 +0200, András Murányi wrote: > > > Also, about the slave names, would it be possible to > use the same names > that are on the PdLab page? I.e. not CamelCase, but > with-dashes > instead :) > > > Sure, i will. Soon :) > > > Done - used the names verbatim from the PdLab page, which means there > is *some* CamelCase, also x86_64 *and* amd64. At least it's now in > perfect sync with the wiki page. > Tonight i'll try to set up the slaves. > > > Now i'm at CVS polling... it goes with a script snippet, which > i'm not sure about if it does what we want... could you take a > look at http://128.238.56.50:8010/waterfall sometimes and see > if the changes trigger the right builder? The snippet is like > this: > > def my_file_splitter(path): # file splitter for > BRANCHNAME/PROJECT/FILEPATH repos > pieces = path.split('/') > if pieces[0] == 'trunk': > branch = None > pieces.pop(0) # remove 'trunk' > elif pieces[0] == 'branches': > pieces.pop(0) # remove 'branches' > # grab branch name > branch = 'branches/' + pieces.pop(0) > else: > return None # something weird > projectname = pieces.pop(0) > # if projectname != 'pure-data': > # return None # wrong project > return (branch, '/'.join(pieces)) > > > further explanation is here: > http://buildbot.net/buildbot/docs/latest/SVNPoller.html > > It really seems to me that buildbout does not understand yet which > builder to start upon which change. Once you have time, you could take > a look into this 'splitter' thing. Ok, will do. Its great to have buildbot running nightly builds, so that will just be cake. Let me finish the Pd-extended release and the pure-data 0.43 release... > Also, please note, that the pd-extended build fails in buildbot - with > various reasons. > http://128.238.56.50:8010/waterfall Ok, I just committed a fix to this, hopefully. > BTW i have reorganized builders so that we see now what's up on > different platforms. It's a bit frightening to think about how this > will look with each external building independently (multiplied by > platforms) - i think a second master shall be dedicated to them, and > then the so called 'categories' will help to keep some order. Yeah, I think it makes sense to have Pd-extended and pure-data.git builds separate from all of the libraries. I don't know enough about buildbot to say how best it should be done. .hc

2 1

[ pure-data-Bugs-3065532 ] on MinGW/MSYS ./configure barfs on IPHONEOS stuff
by SourceForge.net 13 Sep '10

13 Sep '10

Bugs item #3065532, was opened at 2010-09-13 16:46 Message generated for change (Tracker Item Submitted) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3065532&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: on MinGW/MSYS ./configure barfs on IPHONEOS stuff Initial Comment: On Windows XP with MinGW in the MSYS shell, using the latest HEAD in pure-data.git, running ./autogen.sh && ./configure causes this error: ./autogen.sh && ./configure && make libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `m4/config'. libtoolize: linking file `m4/config/config.guess' libtoolize: linking file `m4/config/config.sub' libtoolize: linking file `m4/config/install-sh' libtoolize: linking file `m4/config/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4/generated'. libtoolize: linking file `m4/generated/libtool.m4' libtoolize: linking file `m4/generated/ltoptions.m4' libtoolize: linking file `m4/generated/ltsugar.m4' libtoolize: linking file `m4/generated/ltversion.m4' libtoolize: linking file `m4/generated/lt~obsolete.m4' checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 ./configure: line 2551: syntax error near unexpected token `IPHONEOS=yes,' ./configure: line 2551: `PD_CHECK_IPHONE(IPHONEOS=yes, IPHONEOS=no, { { echo "$as_me:$LINENO: error: iPhoneOS SDK not available" >&5' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3065532&group_…

1 0

[ pure-data-Bugs-3065242 ] tcl-error when modifying subpatch with hidden parentwindow
by SourceForge.net 13 Sep '10

13 Sep '10

Bugs item #3065242, was opened at 2010-09-13 14:00 Message generated for change (Tracker Item Submitted) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3065242&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: tcl-error when modifying subpatch with hidden parentwindow Initial Comment: i get tcl-errors when editing a subpatch in a GOP-enabled abstraction that has it's window closed. currently i haven't found any real consequences except for the annoying error-lines in the pd-console. cause of the bug: Pd tries to make the title of the abstraction-window reflect the "modified" state, but since there is no such window tcl throws an error. steps to reproduce: - i have an abstraction that has GOP enabled. all the code is in a subpatch of this abstraction. finally, i have a pristine instance of this abstraction in my patch. - i open the abstraction - i open the subpatch in the abstraction - i close the abstraction window - i edit the contents of the subpatch - pd-console shows an error: (Tcl) UNHANDLED ERROR: bad window path name ".x8f67d30" while executing "wm title $mytoplevel "$name$dirtychar$arguments - $path" " (procedure "pdtk_canvas_reflecttitle" line 11) invoked from within "pdtk_canvas_reflecttitle .x8f67d30 {/Net/iem/Benutzer/zmoelnig/src/git/pure-data} {abstraction.pd} {} 1" ("uplevel" body line 3) invoked from within "uplevel #0 $cmd_from_pd" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3065242&group_…

1 0

[ pure-data-Patches-3065109 ] [bugfix] for crasher bug when setting samplerate in alsa
by SourceForge.net 13 Sep '10

13 Sep '10

Patches item #3065109, was opened at 2010-09-13 10:58 Message generated for change (Tracker Item Submitted) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3065109&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix Status: Open Resolution: None Priority: 7 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: [bugfix] for crasher bug when setting samplerate in alsa Initial Comment: on my system (with an "nvidia CK804" onboard soundcard), i get immediate crashes if i select the plughw device (in Pd this shows up as "NVidia CK808 (plug-in)") with 44100Hz (the device only supports 48kHz) [1] with the help of the alsa-developpers i hunted the problem down; it can be easily worked around if Pd was not using snd_pcm_hw_params_set_rate_min() (without setting a rate_max()) but snd_pcm_hw_params_set_rate_near() instead [2]. this patch does this (it's a one-liner) so now i can select all devices that show up in the media menu without having to fear a crash. (since it's a crasher, i raise the priority) [1] i usually don't select plughw devices, so i haven't cared so much until now. but it's really annoying if you simply select a configuration in the preferences to make Pd crash) [2] when alsa-devs were finally able to reproduce my problem, they simply asked "but why don't you just use rate_near()?" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3065109&group_…

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

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 2010