Pd-dev January 2011

pd-dev@lists.iem.at

12 participants
70 discussions

[ pure-data-Bugs-3161236 ] tof/pmenu error
by SourceForge.net 18 Jan '11

18 Jan '11

Bugs item #3161236, was opened at 2011-01-18 22:18 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3161236&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: Nobody/Anonymous (nobody) Assigned to: Hans-Christoph Steiner (eighthave) Summary: tof/pmenu error Initial Comment: pmenu is a very useful objet but it is buggy on windows when popping some menu on the help file: error: pmenu0x5825f38: no such object Pd-extended 0.42.5 Windows7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3161236&group_…

1 0

[ pure-data-Bugs-3160988 ] setting array boundaries havocs table display
by SourceForge.net 18 Jan '11

18 Jan '11

Bugs item #3160988, was opened at 2011-01-18 18:24 Message generated for change (Tracker Item Submitted) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3160988&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.43 Status: Open Resolution: None Priority: 6 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: setting array boundaries havocs table display Initial Comment: in Pd-0.43 the table boundaries do not work. to reproduce: - create a new array (keep everything default) - draw something into the array - right-click the array to go to properties - close the "array properties", we only want to modify the "canvas properties" - change (e.g.) the Y-range from 1,-1 to 1,0 - click on Apply - the table content vanishes - the pd-console prints 5 times "shouldvis 0: array" you cannot draw anything in the array anymore (nor see the contents) whenever you move the mouse over the array a "shouldvis 0: array" is printed save/open does not help ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3160988&group_…

1 0

[ pure-data-Bugs-3160982 ] cannot type UTF8 characters in symbolatoms
by SourceForge.net 18 Jan '11

18 Jan '11

Bugs item #3160982, was opened at 2011-01-18 18:16 Message generated for change (Tracker Item Submitted) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3160982&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.43 Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: cannot type UTF8 characters in symbolatoms Initial Comment: since Pd-0.43 patches can handle UTF-8 characters. great! unfortunately, it doesn't seem to work when typing in symbolboxes. example: i switch to a russian(DOS) keyboard layout i create a message box and type the keys 'asd' which correctly shows up as 'ыфв' i create a symbolgatom and type the keys 'asd' which incorrectly show up as 'DK2' note: sending a [symbol ыфв( to the symbolgatom, will correctly display it. it seems like the keyboard input sanitation code for the symbolbox perverts my input. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3160982&group_…

1 0

[ pure-data-Patches-3160462 ] force use of Jack framework on Mac OS X
by SourceForge.net 18 Jan '11

18 Jan '11

Patches item #3160462, was opened at 2011-01-17 22:04 Message generated for change (Tracker Item Submitted) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3160462&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: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: force use of Jack framework on Mac OS X Initial Comment: On Mac OS X, it is possible to have jack installed in many places and in two different ways: lib or framework. The preferred way to use Jack on Mac OS X is the Jackmp.framework from jackosx.com. This patch forces the build system to only look for the Jack framework when building on Mac OS X. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3160462&group_…

1 0

[ pure-data-Patches-3160342 ] remove CPU assumptions from build system
by SourceForge.net 18 Jan '11

18 Jan '11

Patches item #3160342, was opened at 2011-01-17 18:01 Message generated for change (Tracker Item Submitted) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3160342&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: 8 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: remove CPU assumptions from build system Initial Comment: Currently in the configure.ac, for Mac OS X and Windows, there are some CPU-assumptions in the CFLAGS. This patch removes them so that Pd will be more likely to build on all platforms. This patch directly fixes building on Mac OS X/PowerPC, which currently does not build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3160342&group_…

1 0

[ pure-data-Patches-3136644 ] [bugfix] packOSC crashes with bundledepth>32
by SourceForge.net 16 Jan '11

16 Jan '11

Patches item #3136644, was opened at 2010-12-13 12:16 Message generated for change (Comment added) made by mrpeach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3136644&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 Resolution: None Priority: 7 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Martin Peach (mrpeach) Summary: [bugfix] packOSC crashes with bundledepth>32 Initial Comment: when creating deeply nested bundles [packOSC] will complain if the bundle-depth is larger than 32 (MAX_BUNDLE_NESTING) this is ok, however, if you then try to close the bundle (with "]"), Pd will segfault. see attached patch to reproduce the problem ---------------------------------------------------------------------- >Comment By: Martin Peach (mrpeach) Date: 2011-01-16 13:45 Message: It should be fixed now, but maybe a user-friendly way of setting max bundle depth is needed. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-12-13 12:16 Message: the attached diff fixes the problem ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3136644&group_…

1 0

Some OSC suggestions
by Roman Haefeli 16 Jan '11

16 Jan '11

Hi Martin I've been working with the mrpeach/osc objectclasses lately and had some ideas that possibly would help to improve the usability of those (not to mention that they are already very useful now!). * Settable [routeOSC] --------------------- Since Pd version 0.43 the [route] objectclass allows to override its argument. This would be very practical for [routeOSC] as well. * A way to retrieve a single field of the OSC address ----------------------------------------------------- Often it could be useful to extract the name of a certain field of the OSC address name space. In cases where the number of possible values is changed dynamically, it could be important to be able to extract the field name instead of routing the message by that field name. This is currently not possible by using mrpeach/osc classes only, though it could be done by using [zexy/symbol2list /], for instance. However, it'd be nice to have that in the library. Don't know if that is a good idea, but I imagine this could be done with [routeOSC] by adding a middle outlet, that outputs the field name that was matched for. Example: [/one/two 3( | [routeOSC /o*] * left outlet would give: '/two 3' * middle outlet would give 'one' * Allow to match more than one address field at once ---------------------------------------------------- It's a common patching idiom to use a global send/receive pair across many levels of abstractions and heavily exploit [route] to gather the messages interesting for a certain part of the patch. By using OSC this idea could even be refined by using addresses with the same depth as the abstraction nesting depth. Let's consider the following structure of a typical abstraction hierarchy: [somesynth /somesynth] listens on /somesynth | +-[voice $1/voice1] listens on /somesynth/voice1 | +-[oscil $1/freq1] listens on /somesynth/voice1/freq1 Let's assume that in each of those levels we find something like: [r COM] <- global receive | [routeOSC $1] In [somesynth] the [routeOSC $1] would receive all messages to /somesynth, which is what we actually want. In the [voice] abstraction, however, the $1 would resolve to '/somesynth/voice1'. Unfortunately, the [routeOSC /somesynth/voice1] does not receive any messages sent to '/somesynth/voice1', since only one field of the address space is matched. Allowing [routeOSC] to match many fields at once would make it easy to insert abstractions at any nesting level without the need to know beforehand at which nesting level we currently are. One could simply create a [partial $1/part2] into [oscil] and the [routeOSC $1] therein would automatically listen on '/somesynth/voice1/freq1/part2'. What do you think? Cheers Roman

1 0

[ pure-data-Bugs-3159015 ] [iemnet/tcpserver]: unreliable broadcast method
by SourceForge.net 15 Jan '11

15 Jan '11

Bugs item #3159015, was opened at 2011-01-15 21:08 Message generated for change (Tracker Item Submitted) made by reduzent You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3159015&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 Resolution: None Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: Nobody/Anonymous (nobody) Summary: [iemnet/tcpserver]: unreliable broadcast method Initial Comment: When [unpackOSC] receives an OSC packet containing a symbol containing a non-ASCII printable character (such as äöüéèàâ etc.), it prints the following error: unpackOSC: PrintTypeTaggedArgs: Type tag said this arg is a string but it's not! My C skills are a bit limited, but from what I figured, the problem lies in the isprint() condition on line 584 of unpackOSC.c. When I remove that condition, those characters are accepted to be found in strings. However, I guess doing so disables the validity check completely. If that information matters, the environment variable LANG on my computer (Ubuntu 10.04) is set to 'en_US.utf8'. Interestingly, [packOSC] has no problem in putting strings containing those characters into OSC packets. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3159015&group_…

1 0

[ pure-data-Feature Requests-3158765 ] FUDI: add space escape to the protocol
by SourceForge.net 15 Jan '11

15 Jan '11

Feature Requests item #3158765, was opened at 2011-01-15 09:26 Message generated for change (Tracker Item Submitted) made by reduzent You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3158765&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 Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: Nobody/Anonymous (nobody) Summary: FUDI: add space escape to the protocol Initial Comment: Since Pd 0.43 a symbol box allows to type spaces and thus allows easily to create symbols containing spaces. However, such symbols cannot be transmitted (respectively they are split during transmission) over the FUDI protocol due to the lack of a white space escape mechanism. Actually [netreceive] already considers spaces prepended by a backslash as escaped, but [netsend] does not add backslashes before white spaces in symbols. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3158765&group_…

1 0

[ pure-data-Bugs-3158753 ] [iemnet/tcpserver]: unreliable broadcast method
by SourceForge.net 15 Jan '11

15 Jan '11

Bugs item #3158753, was opened at 2011-01-15 09:10 Message generated for change (Tracker Item Submitted) made by reduzent You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3158753&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 Resolution: None Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: Nobody/Anonymous (nobody) Summary: [iemnet/tcpserver]: unreliable broadcast method Initial Comment: Under certain circumstances, a 'broadcast' message does not send the data to all connected clients. Apparently this is the case for the very first moment after a new client has connected. Later all messages to clients seem to arrive reliably. The attached patch exposes the problem, though it's still not easy to trigger it. One has to fiddle around a bit to make it happen. Make sure that one client is connected. The interesting moment is when the second client connects. When connecting it and the 'connection' outlet of the second client outputs '1' (connection established), it sends a message to the server which then is broadcast to all (i.e. both) connected clients. My interpretation: It seems that the client is earlier in knowing about an established connection and sends its message to the server even before the server is 'aware' of (or finished setting up) the new client. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3158753&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 January 2011