Pd-dev November 2008

pd-dev@lists.iem.at

17 participants
51 discussions

pd watchdog in debian lenny on macbook
by Luigi 10 Nov '08

10 Nov '08

Hi i am trying to build pd on debian on a macbook (DualBoot) I tried to use puredyne and realized that pd does not start at all.. it just hangs with watchdog/signalling I then build puredata from source (debian way) and the same is happening.. Any idea what the reason is ?? maybe tcl/tk ??? Thanks Luigi

2 2

future of [declare]
by Roman Haefeli 09 Nov '08

09 Nov '08

hi all i made some tests with the new [declare] in 0.42.0test5. here the results: -lib and -stdlib: those expand the global namespace. when having [declare -stdlib extra/zexy] somewhere, all zexy classes are available for any patches. -path and -stdpath: they expand the namespace of the parent patch and all its (the parents) children patches, children's children inclusive. to be more clear: a [declare] in abstraction [foo] expands the namespace of abstraction [bar], when both are instantiated in the same patch. also the parent patch's namespace is expanded, but not the parent's of the parent. other patches with no relationship are not affected at all by -path and -stdpath. this behaviour differs quite significantly from the implementations of declare in previous pd versions. also, unlike announced, it is _not_ disabled within abstractions. personally, i think, that is the best [declare] implementation that we ever had. i think, it covers many of the use cases one can think of, also because it affects the parent patch. because all of that, i really hope, that the declare's 'philosophy' won't change too much in the future. out of curiosity and out of the need of a reliable behaviour: what are the future plans for [declare]? will it basically stay as it is (which i personally hope)? roman ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

6 9

[ pure-data-Bugs-2251387 ] declare of abstractions is hiddenly saved in parent patches
by SourceForge.net 09 Nov '08

09 Nov '08

Bugs item #2251387, was opened at 2008-11-09 21:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2251387&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: Roman Haefeli (reduzent) Assigned to: Nobody/Anonymous (nobody) Summary: declare of abstractions is hiddenly saved in parent patches Initial Comment: if a patch containing an abstraction or a child of an abstraction containing a [declare] object is saved, the patch is saved with a hidden declare line: #X declare -stdlib extra/list-abs; but there is no line: #X obj 8 8 declare -stdlib extra/list-abs; and therefore no object [declare] appears in the patch, when opening it afterwards. how to reproduce the problem: 1) create 'abstraction.pd' containing: [declare -stdpath extra/list-abs] [list-clip] save it 2) create 'patch.pd' containing: [abstraction] [list-clip] save it 3) close and re-open 'patch.pd' [list-clip] is instantiated, although there is no [declare] visible in the patch. opening 'patch.pd' with a text editor shows the following line: #X declare -stdlib extra/list-abs; this was tested on 0.42.0test5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2251387&group_…

1 0

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

09 Nov '08

Bugs item #2250498, was opened at 2008-11-09 19:46 Message generated for change (Tracker Item Submitted) made by Item Submitter 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: Hans-Christoph Steiner (eighthave) 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) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2250498&group_…

1 0

[comport] - xonxoff working
by Alexandre Castonguay 09 Nov '08

09 Nov '08

Hi all, Martin, Mathieu added a fifo buffer to comport so that 'xonxoff' works. The changes are linux specific but I thought it could be good to include in future iterations of comport. Cheers, Alexandre

2 1

[ pure-data-Feature Requests-2225523 ] udpreceive should give info about remoteports
by SourceForge.net 05 Nov '08

05 Nov '08

Feature Requests item #2225523, was opened at 2008-11-05 15:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=2225523&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: externals Group: None Status: Open Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Martin Peach (mrpeach) Summary: udpreceive should give info about remoteports Initial Comment: for bi-directional communication it is often necessary to know the port of the remote side. this is especially true for stateless (udp) connections. the attached file adds a 5th element to the "address" list containing the port of the remote side. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=2225523&group_…

1 0

[ pure-data-Bugs-2222512 ] error saving graph on parent abstraction
by SourceForge.net 04 Nov '08

04 Nov '08

Bugs item #2222512, was opened at 2008-11-04 22:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2222512&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: v0.41.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bernhard Neugebauer (nils_rotte) Assigned to: Nobody/Anonymous (nobody) Summary: error saving graph on parent abstraction Initial Comment: The main patch (open_me.pd) contains two instances of an abstraction (gop_abstraction.pd), which itself contains an abstraction with "graph on parent" activated (mygop.pd). When changing something inside mygop.pd and saving, the following warning/error appears: consistency check failed: canvas_create_editor This was reproduced with pd-extended 0.40.3 on Windows XP and on Ubuntu Hardy, as well as with vanilla pd 0.41-4 on Windows XP. This is not a big problem, but it seems to be a hint concerning the following behaviour, which I couldn't reproduce on Ubuntu Linux, but only on Windows XP. If there are more (e.g. 40) instances of mygop inside gop_abstraction, and I save mygop, I get: error: .xa50278: no such object and pd has to be restarted, as things get unstable, e.g. the error occurs with any movement of the mouse inside a patch, or saving of files lets pd crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2222512&group_…

1 0

[ pure-data-Feature Requests-2221504 ] add broadcast capabilities to [udpsend]
by SourceForge.net 04 Nov '08

04 Nov '08

Feature Requests item #2221504, was opened at 2008-11-04 17:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=2221504&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: externals Group: None Status: Open Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Martin Peach (mrpeach) Summary: add broadcast capabilities to [udpsend] Initial Comment: the attached patch allows to send broadcast messages via [udpsend]. it should be properly escaped, so that platforms not knowing about SO_BROADCAST (probably all but linux) are not affected ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=2221504&group_…

1 0

[ pure-data-Bugs-2069948 ] netsend udp broadcast permission denied
by SourceForge.net 04 Nov '08

04 Nov '08

Bugs item #2069948, was opened at 2008-08-23 19:27 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2069948&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.41.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ClaudiusMaximus (claudiusmaximus) Assigned to: Nobody/Anonymous (nobody) Summary: netsend udp broadcast permission denied Initial Comment: "connect 192.168.1.255"--[netsend 1] => connecting stream socket: Permission denied (13) seems the default value of the socket option SO_BROADCAST has changed in recent Linux [1], so must now be set explicitly if desired. >From "man 7 socket" on Debian/Lenny SO_BROADCAST Set or get the broadcast flag. When enabled, datagram sockets receive packets sent to a broadcast address and they are allowed to send packets to a broadcast address. This option has no effect on stream-oriented sockets. depending on OS, setting SO_BROADCAST may be disallowed anyway, but as far as I can tell it does no harm to try to enable it (only affects UDP to broadcast address, does nothing for non-UDP or non-broadcast-address) ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-11-04 17:27 Message: oops, i am removing this as it is about mrpeach's "udpsend" rather than "netsend" ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-11-04 17:26 Message: the attached diff adds the requested functionality (properly escaped by ifdefs) to "udpsend" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2069948&group_…

1 0

[ pure-data-Bugs-2069948 ] netsend udp broadcast permission denied
by SourceForge.net 04 Nov '08

04 Nov '08

Bugs item #2069948, was opened at 2008-08-23 19:27 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2069948&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.41.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ClaudiusMaximus (claudiusmaximus) Assigned to: Nobody/Anonymous (nobody) Summary: netsend udp broadcast permission denied Initial Comment: "connect 192.168.1.255"--[netsend 1] => connecting stream socket: Permission denied (13) seems the default value of the socket option SO_BROADCAST has changed in recent Linux [1], so must now be set explicitly if desired. >From "man 7 socket" on Debian/Lenny SO_BROADCAST Set or get the broadcast flag. When enabled, datagram sockets receive packets sent to a broadcast address and they are allowed to send packets to a broadcast address. This option has no effect on stream-oriented sockets. depending on OS, setting SO_BROADCAST may be disallowed anyway, but as far as I can tell it does no harm to try to enable it (only affects UDP to broadcast address, does nothing for non-UDP or non-broadcast-address) ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-11-04 17:26 Message: the attached diff adds the requested functionality (properly escaped by ifdefs) to "udpsend" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2069948&group_…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev November 2008