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_…
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
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_…
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_…
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.
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_…
hi all, hi bryan
i tried to compile pdstring from moocow from a fresh svn checkout and
encountered some issues.
- moocow/autoreconf.sh
when invoked from shell, it gives the error:
../autoreconf.sh: 3: Syntax error: "(" unexpected
i guess, that is because it is using the wrong shebang. it runs fine,
when the shebang calls bash and not sh, like:
#!/bin/bash
- moocow/pdstring/
don't know exactly, if that is intended or not, but there seems to be a
confusion with autogenerated files and files checked out from svn. my
instinct tells me, that files, that are generated by some other scripts
shouldn't be checked into the repository: when i call './autogen.sh', it
will create some files.
now, when i later run an 'svn update', in the meanwhile those files
might have changed in the repository, and svn doesn't want to overwrite
the ones, that were generated by the script.
i am not able to exactly describe what happened, but i just poked around
a bit and then it worked. i cannot exactly recall all the commands i
tried. anyway, i had to manually 'rm makefile* config*' followed by 'svn
update' in order to be able to compile pdstring without errors.
roman
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Bugs item #2712965, was opened at 2009-03-25 19:31
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2712965&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: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Print object has problems with the name argument in Vista
Initial Comment:
Print object has problems with the name argument in Vista. Itseems if the argument contains an underscore or CAPS (as it does in select-help.pd or print-help.pd) then Pd-extended crashes. Putting quotes around the strings fixes the problem in these examples.
Pd version 0.40.3-extended-20080721
Reported first:
http://lists.puredata.info/pipermail/pd-list/2008-06/062988.html
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-04-18 00:46
Message:
no problem for me on Windows XP SP3 using Pd 0.41.4-extended-20090417 or
Pd-vanilla
0.42-4. If you still have this problem, please reopen this bug.
Attached is the patch I used to test this bug.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2712965&group_…
Bugs item #2268712, was opened at 2008-11-12 05:36
Message generated for change (Settings changed) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2268712&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: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: pd-ext 40.3 crashes on typo
Initial Comment:
i'm on winxp and i accidentally found out that mypd crashes if i create an object named "%16" instead of "% 16"
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-04-18 00:42
Message:
no problem for me on winxp Pd 0.41.4-extended-20090417 or Pd-vanilla
0.42-4. If you still have this problem, please reopen this bug.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-04-15 17:16
Message:
Ok, I am going to mark as fixed, please reopen if anyone still has this
problem.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-04-15 17:11
Message:
solved on winxp (Pd version 0.41.4-extended-20090415)
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-04-14 10:55
Message:
no problem on linux, too.
pd-extended 0.41.4-extended-20090414
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-04-13 23:45
Message:
Cannot reproduce on Mac OS X 10.5.6/Intel using Pd-vanilla 0.42-4 and Pd
version 0.41.4-extended-20090413
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2268712&group_…
Bugs item #2566232, was opened at 2009-02-04 20:40
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2566232&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: whyameye (whyameye)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: Gem right-click help broken: Win32 Pd-extended 0.40-3
Initial Comment:
running Pd version 0.40.3-extended-20080721 (released version) I get error "sorry, couldn't find help patch for "<insert Gem object here>" if I right-click on any Gem object and select "help" from the context menu. The Gem help patches are available, however, if I drill down to them through 5.reference -> Gem in the browser of the help menu.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-04-18 00:41
Message:
ok, this should actually be fixed without any additional tweaks as of
tomorrow. Please test and report back if it doens't work
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-04-15 17:16
Message:
I am marking as fixed, please reopen if you still have this problem.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-04-15 17:13
Message:
solved on winxp (Pd version 0.41.4-extended-20090415)
----------------------------------------------------------------------
Comment By: whyameye (whyameye)
Date: 2009-02-07 13:58
Message:
For the currently released 0.40-3 there's an easy fix:
* Open Pd
* Go to File -> Startup...
* At the bottom of the dialog screen that opens, you will see a textbox
labeled "Startup flags:". Click inside the text box
* Using the right arrow, move your cursor to the very end of the text in
the text box. Add one space, then type this *exactly* as it is here:
-helppath c:/PROGRA~1/pd/doc/5.reference/Gem
* (note the space after helppath and no other spaces)
* click "apply" then click "ok"
* close Pd
* reopen and the right-click for help patches should work
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-02-05 00:03
Message:
Yeah, this has been fixed, but the Windows build machine died before I
could get the fixed release out. John Harrison and Joao Miguel Pais have
donated the new parts, I just need to get the time to get that machine up
and running again. Or someone else could try their hand at Windows
builds:
http://puredata.info/docs/developer/mingw
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2566232&group_…