Pd-dev April 2009

pd-dev@lists.iem.at

13 participants
143 discussions

[ pure-data-Bugs-2250498 ] bug on canvas + label_pos inside gop
by SourceForge.net 20 Apr '09

20 Apr '09

Bugs item #2250498, was opened at 2008-11-09 13:46 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2250498&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: João Pais (jmmmp) >Assigned to: Miller Puckette (millerpuckette) Summary: bug on canvas + label_pos inside gop Initial Comment: there's an error (Pd-ext) when you use a canvas inside a gop with the command label_pos. basically, the label just jumps to somewhere in the patch (definite coordinates, not random). Here is a test patch. (windows here, latest official pd-ext) ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-04-20 17:46 Message: Confirmed on Mac OS X 10.5.6/Intel using Pd-vanilla 0.42-4 and Pd version 0.41.4-extended-20090419 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2250498&group_…

1 0

[ pure-data-Bugs-2773230 ] abstract creation audio engine
by SourceForge.net 20 Apr '09

20 Apr '09

Bugs item #2773230, was opened at 2009-04-18 22:26 Message generated for change (Comment added) made by reduzent You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2773230&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: Nobody/Anonymous (nobody) Assigned to: Miller Puckette (millerpuckette) Summary: abstract creation audio engine Initial Comment: I am using Pd version 0.40.3-extended (in a Mac OS X 10.5), Bug: Pd audio engine does not start at abstract creation time. Description: Here attached is an abstraction to illustrate this problem. When you open it in a "test.pd" window with an argument (say: 440) and initialize audio engine it will run the abstraction "sine.pd" which generate a sinewave of 440Hz. Now, if you create a new one, with another argument, say "sine 550" it will NOT generate a new sinewave (together with the sine 440) UNTIL you select/deselect it or tun on/off the audio engine. Thanks! Contact: tutifornari(a)gail.com ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2009-04-20 10:02 Message: bug #2764566 in only apparent on linux with ALSA, right? i haven't encountered the problem using jack. so i still suggest using the dsp-off-and-on approach, since it is much faster than the other workarounds, unless you are really on linux using ALSA. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-04-19 08:36 Message: confirmed on Pd-vanilla 0.42-4 and Pd-extended 0.40-3; other workarounds to make it work: - create yet another dsp-object - connect any dsp object turning on/off the dsp-engine is suboptimal as it triggers another bug #2764566 (on linux and Pd-0.40) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2773230&group_…

1 0

Re: [PD-dev] win32 build farm 'msys.exe' (WAS: symlinks render pdstring unbuildable on MinGW/Windows)
by Hans-Christoph Steiner 20 Apr '09

20 Apr '09

On Apr 19, 2009, at 5:22 AM, Bryan Jurish wrote: > moin Hans, > > On 2009-04-18 06:57:53, Hans-Christoph Steiner <hans(a)eds.org> > appears to > have written: >> >> The bad news is that it seems that my bad diagnosis led you on a wide >> goose chase thru the pain of Windows development. > > It may or may not have been a bad diagnosis (although it certainly > was a > pain ;-) -- I still haven't verified the former, since I don't use (or > understand) all of the auto-build scripts. I'm still kinda hoping > IOhannes might make some headway there... You don't really need to understand the auto-build scripts, all that needs to work is this: cd pure-data/externals make moocow make moocow_install But we really should replace my scripts with something like hudson or builtbot: https://hudson.dev.java.net/build.html http://buildbot.net/ >> Apparently, >> string2any and friends are still not getting built. In fact all of >> the >> 'moocow' is empty on Windows. Here's the bug report: >> >> https://sourceforge.net/tracker/?func=detail&aid=2138593&group_id=55736&ati… > > I noticed this too, and am currently trying to figure out exactly why. > Actually, I didn't really expect any of my externals to build on > windows > currently, since I was missing test clauses for win32 in > ax_pd_external.m4. I've added the test clauses now, and at least > win32 > on the build farm machine is getting properly recognized, but I'm > getting a whole mess of other (stupid) errors which are preventing > manual compilation: > > 'msys.bat' doesn't run on the autobuild machine from the cygwin > shell I > get when I ssh in: is this (easily) fixable? I can run > "/cygdrive/c/msys/1.0/bin/sh" manually, but it's not really useable as > an interactive shell. So far I've been explicitly calling "$MSYS_SH > ./configure" to test, for MSYS_SH=/cygdrive/c/msys/1.0/bin/sh.exe > > I've tried manually prepending > "/cygdrive/c/msys/1.0/bin:/cygdrive/c/MinGW/bin" to PATH, and that > gets > me all the mingw programs, but their compiled-in paths (e.g. include > paths for gcc) are foobared, since cygwin's pseudo-filesystem doesn't > jive with the msys one. In particular, I'm getting: > > pddev@windowsxp-i386$ sh ./configure \ > --with-pd-include="/home/pd/auto-build/pd-extended/pd/src" > ... > checking for string.h... no > configure: WARNING: could not find standard C headers -- things may > get ugly > > ... similar problems with linker paths. I've hacked this for now by > setting CPPFLAGS and LDFLAGS, and the updated version of pdstring > seems > to build ok. I just documented a way to get the same MSYS shell used by the builds. You need rdesktop, for better or worse: http://puredata.info/docs/developer/WindowsXPI386 But then I succeeded in locking all accounts out from network logins... DOH! I'll try to fix it tomorrow. >> Part of the problem might be MinGW's very old version of autotools: >> automake 1.7 and libtool 1.4, which is a big bummer. > > This shouldn't be a problem, since I've been storing autoconf- > generated > stuff in svn anyways, and calling AM_MAINTAINER_MODE to ensure that it > doesn't get implicitly rebuilt. See the thread "[PD-dev] moocow: svn > and compilation issues" for more details. > > In a related question, should the auto-build process for the win32 > build-farm machine be trying to build everything from the LIB_TARGETS > variable in externals/Makefile? If so, then I must be being pretty > dense, because I can't see where my builds are getting called (I see > install calls, but no configuration or compilation), much less where > they might be failing... You are correct. Search for 'moocow_install:' in externals/Makefile. That's where its being called. .hc > > > marmosets, > Bryan > >> On Mar 7, 2009, at 5:14 PM, Bryan Jurish wrote: >> >>> moin Hans, >>> >>> Short version: should be fixed now. package-local links to the >>> common >>> code are now no longer tracked by SVN, but kludged into place by an >>> "./svn-prepare.sh" (symlink ;-) in each package directory, >>> alternately >>> by the DIR.autogen_stamp target in extended/Makefile. >>> >>> More comments: see below. >>> >>> On 2009-03-05 23:44:58, Hans-Christoph Steiner <hans(a)eds.org> >>> appears to >>> have written: >>>> On Mar 5, 2009, at 5:22 PM, Bryan Jurish wrote: >>>>> On 2009-03-05 21:33:36, Hans-Christoph Steiner <hans(a)eds.org> >>>>> appears to >>>>> have written: >>>>>> On Mar 4, 2009, at 4:23 PM, Bryan Jurish wrote: >>>>>>> On 2009-03-04 05:37:40, Hans-Christoph Steiner <hans(a)eds.org> >>>>>>> appears to >>>>>>> have written: >>>>>>>> I was just trying to build string2any and friends on Windows >>>>>>>> for a >>>>>>>> student, but the symlinks used in moocow are throwing a huge >>>>>>>> wrench >>>>>>>> in >>>>>>>> the process. >>>>>>>> They show up at .lnk files, and are not links at all. >>>>>>>> That's because cygwin translates symlinks into Windows >>>>>>>> shortcuts, >>>>>>>> aka .lnk. >>> [snip] >>>>> the rsync "-L" flag ("--copy-links") works for me here, even >>>>> with a >>>>> preceding "-a" ("--archive")... does that not work on cygwin? >>>>> The only >>>>> times I've ever had problems with "-L" were symlink cycles (./ >>>>> dir -> >>>>> .), >>>>> which I certainly am not inserting into the repository. >>> >>>> Sorry, I had no intention to insult or demean, I guess I was just >>>> terse. >>> >>> No worries; the whole mess really arises from my not having the >>> time to >>> dig around in the automake internals (bad programmer, no biscuit): >>> I'm >>> sure there's a way to get the common code into its own automake >>> +autoconf >>> package, but I haven't figured it out yet. Ideally, I'd like to >>> have an >>> family of automake "_PDEXTERNALS" targets (analagous to "_PROGRAMS", >>> "_LIBRARIES", "_DATA", etc.), but that's not happening yet; hence >>> the >>> intermediate solution "../common", which goes pretty far towards >>> eliminating the headaches necessary to roll up a new external >>> package or >>> add new functionality to an existing package. >>> >>>> The bad news is that its not that simple. I added "--no-l >>>> --copy-links" to cygwin rsync and it still doesn't work. >>> >>> Curioser and curioser. I just tried an rsync from linux (with >>> symlinks) >>> to cygwin with "-a --no-l --copy-links" here, and I got copies of >>> the >>> symlinks rather than windoof shortcuts. Can you point me at the >>> (script >>> containining the) full rsync call so I can test that here? >>> >>>> There is >>>> nothing you have to do here, I just thought it'd be nice to have >>>> those >>>> externals included in Windows. Here are the logs, it seems it >>>> doesn't >>>> find the compiler properly: >>>> >>>> http://bxmc.poly.edu/pdlab/moocow_log.txt >>>> http://bxmc.poly.edu/pdlab/config.log >>> >>> 403 forbidden >>> >>> not really important though, since the AC_CONFIG_LINKS() symlinks >>> aren't >>> the problem. >>> >>>> What I don't understand is why this code needs such a complicated >>>> build >>>> system? As far as I can tell, it is mostly pretty standard C code. >>> >>> If you're asking that now, it's probably a good thing I didn't >>> delegate >>> external building to libtool ;-) >>> >>> It's (mostly) not the *code* which needs automake, it's *me* who >>> wants >>> it. Having 'distcheck' and 'dist' targets generated auto- >>> magically is >>> really outrageously spiffy. And with the shared code, building a >>> new >>> external in an existing package is as easy as setting a couple of >>> make >>> variables: >>> >>> pdexterns_PROGRAMS += myexternal >>> myexternal_SOURCES = myexternal.c mycommon.c mycommon.h >>> >>> ... and automake takes care of the rest (make, make install, make >>> uninstall, ...). Creating a new external package using this >>> system is >>> pretty easy too: see the SVN directory externals/moocow/hello for a >>> complete working tutorial, or its README >>> here: >>> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mooco… >>> >>> >>> The ./configure options are there for debugging, support for >>> multiple >>> installations of Pd on the same machine, as well as support for >>> pd-extended (e.g. --enable-object-externals). >>> >>> autotools support for use environment variables (CFLAGS, CPPFLAGS, >>> etc.) >>> is really handy too, e.g. for messing with optimization & debugging >>> flags. I wish every external build system would support these. >>> >>> That said, in some cases the code actually *does* require some >>> platform-dependent initialization in ./configure. [locale] for >>> instance >>> checks for definitions of all of the "LC_*" variables it supports, >>> [flite] needs to know where to find the libflite include files, as >>> well >>> as how to link to libflite: this is exactly the kind of thing >>> autoconf >>> was made to handle, and which it does quite elegantly. >>> >>>> I >>>> find that in the long run, simple Makefiles are the least work >>>> overall. >>>> To each his own, I suppose, or maybe I'm missing something. >>> >>> If I were maintaining only 1 or 2 external packages (or a single >>> global >>> build system ;-), I think I might tend to agree. As it is, I >>> think the >>> autotools beat copy+paste Makefiles (which I still use a lot, e.g. >>> for >>> my LaTeX documents, which rarely need to be synchronized or >>> updated once >>> the paper has been written) hands down. Are >>> automake+autoconf+autoheader overkill for my externals? Sure they >>> are: >>> I think this is demonstrated pretty well by the fact that >>> [sprinkler] >>> and [pdstring] built for years in what became flatspace/ with 2- >>> liner C >>> files to the tune of: >>> >>> #define PACKAGE_VERISON "cvs" >>> #include "../../moocow/sprinkler/sprinkler.c" >>> >>> Did flatspace builds get me 'make dist'? Nope. Did they get me >>> 'make >>> distcheck'? No way. Could I configure them for target systems to >>> which >>> I myself have no access simply by querying the availability of the >>> relevant C libraries and includes? Uh... yeah, right... enough; >>> I love >>> externals/build rsp. flatspace and everything it's done for me, >>> and I >>> really don't want to start a flame war... I hope the windoof >>> builds work >>> now (though I am still curious about that apparent rsync bug)... >>> >>> marmosets, >>> Bryan >>> >>> --Bryan Jurish "There is *always* one more >>> bug." >>> jurish(a)ling.uni-potsdam.de -Lubarsky's Law of Cybernetic >>> Entomology >> >> >> >> ---------------------------------------------------------------------------- >> >> >> I spent 33 years and four months in active military service and >> during >> that period I spent most of my time as a high class muscle man for >> Big >> Business, for Wall Street and the bankers. - General Smedley >> Butler >> >> >> >> > > -- > Bryan Jurish "There is *always* one more > bug." > jurish(a)ling.uni-potsdam.de -Lubarsky's Law of Cybernetic > Entomology ---------------------------------------------------------------------------- "It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White

1 0

[ pure-data-Bugs-2764566 ] Pd leaks file-handles with alsa
by SourceForge.net 20 Apr '09

20 Apr '09

Bugs item #2764566, was opened at 2009-04-15 03:30 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2764566&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.40.2 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Hans-Christoph Steiner (eighthave) Summary: Pd leaks file-handles with alsa Initial Comment: Pd-0.40 on linux with ALSA severly leaks file-handles when starting/stopping the DSP. whenever you restart the DSP the /dev/snd/control* devices are opened anew, but none are closed. this eventually leads to a "too many open files" error, which will keep you from saving your patches (and restarting the DSP) this appears with Pd-0.40-2 it has been fixed in Pd-0.41 and above i am just reporting the bug for the sake of completeness. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-04-19 19:14 Message: I don't quite understand, is this bug present in Pd-extended 0.41.4? ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-04-19 04:35 Message: i found that this bug is also present in Pd-extended-0.40-3 since this is the currently the most recent release of Pd-extended i re-open this bug; i would suggest releasing PdX-0.41 asap and close the bug again :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2764566&group_…

1 0

[ pure-data-Bugs-2372244 ] mouse-help.pd crashes pd-extended 0.40.3
by SourceForge.net 19 Apr '09

19 Apr '09

Bugs item #2372244, was opened at 2008-12-01 18:06 Message generated for change (Comment added) made by waffenladen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2372244&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: None Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Hans-Christoph Steiner (eighthave) Summary: mouse-help.pd crashes pd-extended 0.40.3 Initial Comment: mouse-help.pd crashes pd-extended 0.40.3 on opening. on ubuntu hardy using the debs from puredata.info. ewanuno@ewanuno-laptop:~$ pd -d 9 set pd_whichapi 0 set pd_whichmidiapi 2 pdtk_pd_startup {Pd version 0.40-3extended } { {OSS 2} {ALSA 1} {jack 5} } { {default-MIDI 2} {ALSA-MIDI 1} } {Bitstream Vera Sans Mono} normal set pd_whichmidiapi 2 set pd_whichapi 0 tk scaling is 1.33794238683 pdtk_post {libdir loader $Revision: 1.8 $} pdtk_post { written by Hans-Christoph Steiner <hans(a)at.or.at>} pdtk_post { compiled on Jul 29 2008 at 08:20:12 } pdtk_post { compiled against Pd version 0.40.3.extended} <init> : Avifile RELEASE-0.7.47-080115-14:47-4.2.3 <init> : Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3 xtpr <init> : 800.00 MHz Intel(R) Atom(TM) CPU N270 @ 1.60GHz processor detected pdtk_post { GEM: Graphics Environment for Multimedia} pdtk_post { GEM: ver: 0.91.1 'tigital'} pdtk_post { GEM: compiled: Jul 29 2008} pdtk_post { GEM: maintained by IOhannes m zmoelnig} pdtk_post { GEM: Authors : Mark Danks (original version)} pdtk_post { GEM: Chris Clepper} pdtk_post { GEM: James Tittle} pdtk_post { GEM: IOhannes m zmoelnig} pdtk_post { GEM: with help by Guenter Geiger, Daniel Heckenberg, Cyrille Henry, et al.} pdtk_post { GEM: found a bug? miss a feature? please report it:} pdtk_post { GEM: homepage http://gem.iem.at/} pdtk_post { GEM: bug-tracker http://sourceforge.net/projects/pd-gem/} pdtk_post { GEM: mailing-list http://lists.puredata.info/listinfo/gem-dev/} pdtk_post { GEM: compiled for SIMD architecture: } pdtk_post {MMX } pdtk_post {} pdtk_post { GEM: using } pdtk_post {MMX} pdtk_post { optimization} pdtk_post { libdir_loader: added 'cyclone' to the global objectclass path} pdtk_post { libdir_loader: added 'zexy' to the global objectclass path} pdtk_post { libdir_loader: added 'creb' to the global objectclass path} pdtk_post { libdir_loader: added 'cxc' to the global objectclass path} pdtk_post { libdir_loader: added 'iemlib' to the global objectclass path} pdtk_post { libdir_loader: added 'list-abs' to the global objectclass path} pdtk_post { libdir_loader: added 'mapping' to the global objectclass path} pdtk_post { libdir_loader: added 'markex' to the global objectclass path} pdtk_post { libdir_loader: added 'maxlib' to the global objectclass path} pdtk_post { libdir_loader: added 'memento' to the global objectclass path} pdtk_post { libdir_loader: added 'mjlib' to the global objectclass path} pdtk_post { libdir_loader: added 'motex' to the global objectclass path} pdtk_post { libdir_loader: added 'oscx' to the global objectclass path} pdtk_post { libdir_loader: added 'pddp' to the global objectclass path} pdtk_post { libdir_loader: added 'pdogg' to the global objectclass path} pdtk_post { libdir_loader: added 'pixeltango' to the global objectclass path} pdtk_post { libdir_loader: added 'pmpd' to the global objectclass path} pdtk_post { libdir_loader: added 'rradical' to the global objectclass path} pdtk_post { libdir_loader: added 'sigpack' to the global objectclass path} pdtk_post { libdir_loader: added 'smlib' to the global objectclass path} pdtk_post { libdir_loader: added 'toxy' to the global objectclass path} pdtk_post { libdir_loader: added 'unauthorized' to the global objectclass path} pdtk_post { libdir_loader: added 'pan' to the global objectclass path} pdtk_post { libdir_loader: added 'freeverb' to the global objectclass path} pdtk_post { libdir_loader: added 'hcs' to the global objectclass path} pdtk_post { libdir_loader: added 'jmmmp' to the global objectclass path} pdtk_post { libdir_loader: added 'ext13' to the global objectclass path} pdtk_post { libdir_loader: added 'ggee' to the global objectclass path} pdtk_post { libdir_loader: added 'flib' to the global objectclass path} pdtk_post { libdir_loader: added 'ekext' to the global objectclass path} pdtk_post { libdir_loader: added 'flatspace' to the global objectclass path} pdtk_post { PDP: pure data packet version 0.12.5-darcs} pdtk_post { PiDiP : additional video processing objects for PDP version 0.12.22 ( ydegoyon(a)free.fr )} proc pdp_colorgrid_apply {id} { set vid [string trimleft $id .] set var_graph_pdp_colorgrid [concat graph_pdp_colorgrid_$vid] global $var_graph_pdp_colorgrid set var_graph_xlines [concat graph_xlines_$vid] global $var_graph_xlines set var_graph_ylines [concat graph_ylines_$vid] global $var_graph_ylines set cmd [concat $id dialog [eval concat $$var_graph_xlines] [eval concat $$var_graph_ylines] [eval concat $$var_graph_pdp_colorgrid] \;] pd $cmd } proc pdp_colorgrid_cancel {id} { set cmd [concat $id cancel \;] pd $cmd } proc pdp_colorgrid_ok {id} { pdp_colorgrid_apply $id pdp_colorgrid_cancel $id } proc pdtk_pdp_colorgrid_dialog {id xlines ylines pdp_colorgrid} { set vid [string trimleft $id .] set var_graph_pdp_colorgrid [concat graph_pdp_colorgrid_$vid] global $var_graph_pdp_colorgrid set var_graph_xlines [concat graph_xlines_$vid] global $var_graph_xlines set var_graph_ylines [concat graph_ylines_$vid] global $var_graph_ylines set $var_graph_pdp_colorgrid $pdp_colorgrid set $var_graph_xlines $xlines set $var_graph_ylines $ylines toplevel $id wm title $id {pdp_colorgrid} wm protocol $id WM_DELETE_WINDOW [concat pdp_colorgrid_cancel $id] label $id.label -text {COLORGRID PROPERTIES} pack $id.label -side top frame $id.buttonframe pack $id.buttonframe -side bottom -fill x -pady 2m button $id.buttonframe.cancel -text {Cancel} -command "pdp_colorgrid_cancel $id" button $id.buttonframe.apply -text {Apply} -command "pdp_colorgrid_apply $id" button $id.buttonframe.ok -text {OK} -command "pdp_colorgrid_ok $id" pack $id.buttonframe.cancel -side left -expand 1 pack $id.buttonframe.apply -side left -expand 1 pack $id.buttonframe.ok -side left -expand 1 frame $id.42rangef pack $id.42rangef -side top label $id.42rangef.lxlines -text "X sections :" entry $id.42rangef.xlines -textvariable $var_graph_xlines -width 7 pack $id.42rangef.lxlines $id.42rangef.xlines -side left frame $id.72rangef pack $id.72rangef -side top label $id.72rangef.lylines -text "Y sections :" entry $id.72rangef.ylines -textvariable $var_graph_ylines -width 7 pack $id.72rangef.lylines $id.72rangef.ylines -side left checkbutton $id.showpdp_colorgrid -text {Show Grid} -variable $var_graph_pdp_colorgrid -anchor w pack $id.showpdp_colorgrid -side top bind $id.42rangef.xlines <KeyPress-Return> [concat pdp_colorgrid_ok $id] bind $id.72rangef.ylines <KeyPress-Return> [concat pdp_colorgrid_ok $id] focus $id.42rangef.xlines } pdtk_post { pdp_colorgrid: version 0.4 by Yves Degoyon (ydegoyon(a)free.fr) & Lluis Gomez i Bigorda (lluis(a)artefacte.org)} pdtk_post { expr, expr~, fexpr~ version 0.4 under GNU General Public License } pdtk_post { [hid] 0.7, written by Hans-Christoph Steiner <hans(a)eds.org>} pdtk_post { compiled on Jul 29 2008 at 08:31:09 } pdtk_post { this is pddplink 0.1, 3rd alpha build...} if {[lsearch $auto_path "/usr/lib/pd/extra/pddp"] < 0} {lappend auto_path "/usr/lib/pd/extra/pddp"} after 0 {package require pddp} after 0 {::pddp::srvUse /usr/lib/pd/doc/5.reference/hid} pdtk_canvas_new .x853fac8 659 461 +56+46 0 wm title .x853fac8 {mouse-help.pd - /usr/lib/pd/doc/5.reference/hid} set menu_windowlist {{{mouse-help.pd} .x853fac8} } pdtk_fixwindowmenu pdtk_post { MAX: 1} pdtk_post { MIN: -1} pdtk_post { MIN: -1} pdtk_post { MAX: 1} pdtk_post { MIN: -1} pdtk_post { MIN: -1} pdtk_post { MAX: 1} pdtk_post { MIN: -1} pdtk_post { MIN: -1} pdtk_post { MAX: 1} pdtk_post { MIN: -1} pdtk_post { MIN: -1} pdtk_post { error: } pdtk_post {[hid] open /dev/input/event6 failed} pdtk_post { error: } pdtk_post {[hid] can not open device 6} pd_gui: pd process exited Segmentation fault ewanuno@ewanuno-laptop:~$ i am ewanuno(a)gmail.com ---------------------------------------------------------------------- Comment By: Holger (waffenladen) Date: 2009-04-19 13:39 Message: at least fixed on archlinux: it didn`t crash pd-extended in r11023, but did render it unresponsive using 100% cpu and the helpfile didn`t show up. but in r11063 everything works fine. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-04-18 05:54 Message: I am pretty sure I fixed this, it works for me at least. Please test and let me know if it still crashes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2372244&group_…

1 0

win32 build farm 'msys.exe' (WAS: symlinks render pdstring unbuildable on MinGW/Windows)
by Bryan Jurish 19 Apr '09

19 Apr '09

moin Hans, On 2009-04-18 06:57:53, Hans-Christoph Steiner <hans(a)eds.org> appears to have written: > > The bad news is that it seems that my bad diagnosis led you on a wide > goose chase thru the pain of Windows development. It may or may not have been a bad diagnosis (although it certainly was a pain ;-) -- I still haven't verified the former, since I don't use (or understand) all of the auto-build scripts. I'm still kinda hoping IOhannes might make some headway there... > Apparently, > string2any and friends are still not getting built. In fact all of the > 'moocow' is empty on Windows. Here's the bug report: > > https://sourceforge.net/tracker/?func=detail&aid=2138593&group_id=55736&ati… I noticed this too, and am currently trying to figure out exactly why. Actually, I didn't really expect any of my externals to build on windows currently, since I was missing test clauses for win32 in ax_pd_external.m4. I've added the test clauses now, and at least win32 on the build farm machine is getting properly recognized, but I'm getting a whole mess of other (stupid) errors which are preventing manual compilation: 'msys.bat' doesn't run on the autobuild machine from the cygwin shell I get when I ssh in: is this (easily) fixable? I can run "/cygdrive/c/msys/1.0/bin/sh" manually, but it's not really useable as an interactive shell. So far I've been explicitly calling "$MSYS_SH ./configure" to test, for MSYS_SH=/cygdrive/c/msys/1.0/bin/sh.exe I've tried manually prepending "/cygdrive/c/msys/1.0/bin:/cygdrive/c/MinGW/bin" to PATH, and that gets me all the mingw programs, but their compiled-in paths (e.g. include paths for gcc) are foobared, since cygwin's pseudo-filesystem doesn't jive with the msys one. In particular, I'm getting: pddev@windowsxp-i386$ sh ./configure \ --with-pd-include="/home/pd/auto-build/pd-extended/pd/src" ... checking for string.h... no configure: WARNING: could not find standard C headers -- things may get ugly ... similar problems with linker paths. I've hacked this for now by setting CPPFLAGS and LDFLAGS, and the updated version of pdstring seems to build ok. > Part of the problem might be MinGW's very old version of autotools: > automake 1.7 and libtool 1.4, which is a big bummer. This shouldn't be a problem, since I've been storing autoconf-generated stuff in svn anyways, and calling AM_MAINTAINER_MODE to ensure that it doesn't get implicitly rebuilt. See the thread "[PD-dev] moocow: svn and compilation issues" for more details. In a related question, should the auto-build process for the win32 build-farm machine be trying to build everything from the LIB_TARGETS variable in externals/Makefile? If so, then I must be being pretty dense, because I can't see where my builds are getting called (I see install calls, but no configuration or compilation), much less where they might be failing... marmosets, Bryan > On Mar 7, 2009, at 5:14 PM, Bryan Jurish wrote: > >> moin Hans, >> >> Short version: should be fixed now. package-local links to the common >> code are now no longer tracked by SVN, but kludged into place by an >> "./svn-prepare.sh" (symlink ;-) in each package directory, alternately >> by the DIR.autogen_stamp target in extended/Makefile. >> >> More comments: see below. >> >> On 2009-03-05 23:44:58, Hans-Christoph Steiner <hans(a)eds.org> appears to >> have written: >>> On Mar 5, 2009, at 5:22 PM, Bryan Jurish wrote: >>>> On 2009-03-05 21:33:36, Hans-Christoph Steiner <hans(a)eds.org> >>>> appears to >>>> have written: >>>>> On Mar 4, 2009, at 4:23 PM, Bryan Jurish wrote: >>>>>> On 2009-03-04 05:37:40, Hans-Christoph Steiner <hans(a)eds.org> >>>>>> appears to >>>>>> have written: >>>>>>> I was just trying to build string2any and friends on Windows for a >>>>>>> student, but the symlinks used in moocow are throwing a huge wrench >>>>>>> in >>>>>>> the process. >>>>>>> They show up at .lnk files, and are not links at all. >>>>>>> That's because cygwin translates symlinks into Windows shortcuts, >>>>>>> aka .lnk. >> [snip] >>>> the rsync "-L" flag ("--copy-links") works for me here, even with a >>>> preceding "-a" ("--archive")... does that not work on cygwin? The only >>>> times I've ever had problems with "-L" were symlink cycles (./dir -> >>>> .), >>>> which I certainly am not inserting into the repository. >> >>> Sorry, I had no intention to insult or demean, I guess I was just >>> terse. >> >> No worries; the whole mess really arises from my not having the time to >> dig around in the automake internals (bad programmer, no biscuit): I'm >> sure there's a way to get the common code into its own automake+autoconf >> package, but I haven't figured it out yet. Ideally, I'd like to have an >> family of automake "_PDEXTERNALS" targets (analagous to "_PROGRAMS", >> "_LIBRARIES", "_DATA", etc.), but that's not happening yet; hence the >> intermediate solution "../common", which goes pretty far towards >> eliminating the headaches necessary to roll up a new external package or >> add new functionality to an existing package. >> >>> The bad news is that its not that simple. I added "--no-l >>> --copy-links" to cygwin rsync and it still doesn't work. >> >> Curioser and curioser. I just tried an rsync from linux (with symlinks) >> to cygwin with "-a --no-l --copy-links" here, and I got copies of the >> symlinks rather than windoof shortcuts. Can you point me at the (script >> containining the) full rsync call so I can test that here? >> >>> There is >>> nothing you have to do here, I just thought it'd be nice to have those >>> externals included in Windows. Here are the logs, it seems it doesn't >>> find the compiler properly: >>> >>> http://bxmc.poly.edu/pdlab/moocow_log.txt >>> http://bxmc.poly.edu/pdlab/config.log >> >> 403 forbidden >> >> not really important though, since the AC_CONFIG_LINKS() symlinks aren't >> the problem. >> >>> What I don't understand is why this code needs such a complicated build >>> system? As far as I can tell, it is mostly pretty standard C code. >> >> If you're asking that now, it's probably a good thing I didn't delegate >> external building to libtool ;-) >> >> It's (mostly) not the *code* which needs automake, it's *me* who wants >> it. Having 'distcheck' and 'dist' targets generated auto-magically is >> really outrageously spiffy. And with the shared code, building a new >> external in an existing package is as easy as setting a couple of make >> variables: >> >> pdexterns_PROGRAMS += myexternal >> myexternal_SOURCES = myexternal.c mycommon.c mycommon.h >> >> ... and automake takes care of the rest (make, make install, make >> uninstall, ...). Creating a new external package using this system is >> pretty easy too: see the SVN directory externals/moocow/hello for a >> complete working tutorial, or its README >> here: >> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mooco… >> >> >> The ./configure options are there for debugging, support for multiple >> installations of Pd on the same machine, as well as support for >> pd-extended (e.g. --enable-object-externals). >> >> autotools support for use environment variables (CFLAGS, CPPFLAGS, etc.) >> is really handy too, e.g. for messing with optimization & debugging >> flags. I wish every external build system would support these. >> >> That said, in some cases the code actually *does* require some >> platform-dependent initialization in ./configure. [locale] for instance >> checks for definitions of all of the "LC_*" variables it supports, >> [flite] needs to know where to find the libflite include files, as well >> as how to link to libflite: this is exactly the kind of thing autoconf >> was made to handle, and which it does quite elegantly. >> >>> I >>> find that in the long run, simple Makefiles are the least work overall. >>> To each his own, I suppose, or maybe I'm missing something. >> >> If I were maintaining only 1 or 2 external packages (or a single global >> build system ;-), I think I might tend to agree. As it is, I think the >> autotools beat copy+paste Makefiles (which I still use a lot, e.g. for >> my LaTeX documents, which rarely need to be synchronized or updated once >> the paper has been written) hands down. Are >> automake+autoconf+autoheader overkill for my externals? Sure they are: >> I think this is demonstrated pretty well by the fact that [sprinkler] >> and [pdstring] built for years in what became flatspace/ with 2-liner C >> files to the tune of: >> >> #define PACKAGE_VERISON "cvs" >> #include "../../moocow/sprinkler/sprinkler.c" >> >> Did flatspace builds get me 'make dist'? Nope. Did they get me 'make >> distcheck'? No way. Could I configure them for target systems to which >> I myself have no access simply by querying the availability of the >> relevant C libraries and includes? Uh... yeah, right... enough; I love >> externals/build rsp. flatspace and everything it's done for me, and I >> really don't want to start a flame war... I hope the windoof builds work >> now (though I am still curious about that apparent rsync bug)... >> >> marmosets, >> Bryan >> >> --Bryan Jurish "There is *always* one more >> bug." >> jurish(a)ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology > > > > ---------------------------------------------------------------------------- > > > I spent 33 years and four months in active military service and during > that period I spent most of my time as a high class muscle man for Big > Business, for Wall Street and the bankers. - General Smedley Butler > > > > -- Bryan Jurish "There is *always* one more bug." jurish(a)ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology

1 0

[ pure-data-Bugs-2773230 ] abstract creation audio engine
by SourceForge.net 19 Apr '09

19 Apr '09

Bugs item #2773230, was opened at 2009-04-19 00:26 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2773230&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: Nobody/Anonymous (nobody) >Assigned to: Miller Puckette (millerpuckette) Summary: abstract creation audio engine Initial Comment: I am using Pd version 0.40.3-extended (in a Mac OS X 10.5), Bug: Pd audio engine does not start at abstract creation time. Description: Here attached is an abstraction to illustrate this problem. When you open it in a "test.pd" window with an argument (say: 440) and initialize audio engine it will run the abstraction "sine.pd" which generate a sinewave of 440Hz. Now, if you create a new one, with another argument, say "sine 550" it will NOT generate a new sinewave (together with the sine 440) UNTIL you select/deselect it or tun on/off the audio engine. Thanks! Contact: tutifornari(a)gail.com ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-04-19 10:36 Message: confirmed on Pd-vanilla 0.42-4 and Pd-extended 0.40-3; other workarounds to make it work: - create yet another dsp-object - connect any dsp object turning on/off the dsp-engine is suboptimal as it triggers another bug #2764566 (on linux and Pd-0.40) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2773230&group_…

1 0

[ pure-data-Bugs-2764566 ] Pd leaks file-handles with alsa
by SourceForge.net 19 Apr '09

19 Apr '09

Bugs item #2764566, was opened at 2009-04-15 09:30 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2764566&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.40.2 >Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) >Assigned to: Hans-Christoph Steiner (eighthave) Summary: Pd leaks file-handles with alsa Initial Comment: Pd-0.40 on linux with ALSA severly leaks file-handles when starting/stopping the DSP. whenever you restart the DSP the /dev/snd/control* devices are opened anew, but none are closed. this eventually leads to a "too many open files" error, which will keep you from saving your patches (and restarting the DSP) this appears with Pd-0.40-2 it has been fixed in Pd-0.41 and above i am just reporting the bug for the sake of completeness. ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-04-19 10:35 Message: i found that this bug is also present in Pd-extended-0.40-3 since this is the currently the most recent release of Pd-extended i re-open this bug; i would suggest releasing PdX-0.41 asap and close the bug again :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2764566&group_…

1 0

error: maximum object loading depth 1000 reached
by Hans-Christoph Steiner 19 Apr '09

19 Apr '09

Hey, This is probably mostly for IOhannes. IIRC, the code that causes the "error: maximum object loading depth 1000 reached" stuff was related to the hexloader. Its checked into Pd-extended, but the hexloader isn't used in Pd-extended right now. Is there some other reason to include this patch? Here's the original reference. https://sourceforge.net/tracker2/?func=detail&aid=1990599&group_id=55736&at… .hc ---------------------------------------------------------------------------- "[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.

4 5

[ pure-data-Bugs-2773230 ] abstract creation audio engine
by SourceForge.net 19 Apr '09

19 Apr '09

Bugs item #2773230, was opened at 2009-04-18 22:26 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2773230&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: abstractions Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: abstract creation audio engine Initial Comment: I am using Pd version 0.40.3-extended (in a Mac OS X 10.5), Bug: Pd audio engine does not start at abstract creation time. Description: Here attached is an abstraction to illustrate this problem. When you open it in a "test.pd" window with an argument (say: 440) and initialize audio engine it will run the abstraction "sine.pd" which generate a sinewave of 440Hz. Now, if you create a new one, with another argument, say "sine 550" it will NOT generate a new sinewave (together with the sine 440) UNTIL you select/deselect it or tun on/off the audio engine. Thanks! Contact: tutifornari(a)gail.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2773230&group_…

1 0

← Newer
1
2
3
4
5
6
7
...
15
Older →

Jump to page:

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 April 2009