Pd-dev August 2008

pd-dev@lists.iem.at

18 participants
52 discussions

[ pure-data-Bugs-2073844 ] zexy announce message charset confusion
by SourceForge.net 25 Aug '08

25 Aug '08

Bugs item #2073844, was opened at 2008-08-25 15:34 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=2073844&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: ClaudiusMaximus (claudiusmaximus) Assigned to: Nobody/Anonymous (nobody) Summary: zexy announce message charset confusion Initial Comment: $ pd -stderr -verbose -lib zexy tried /usr/lib/pd/extra/zexy/zexy.pd_linux and succeeded the zexy external 2.2.1 (l) forum::f::umlte compiled: Jun 17 2008 send me a 'help' message $ echo $LANG en_GB.UTF-8 Without -stderr, TCL/Tk (version 8.5) or Pd's console gets really confused and displays a big empty space with invisible text that shows up only when carefully selected... other externals may be affected by this issue too... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2073844&group_…

1 0

sms pd external - design choices
by Rich E 25 Aug '08

25 Aug '08

Hi all, As I may have mentioned in a few other places, I have been working with a c library for analysis/synthesis known as SMS. The library, although in flux still, is now capable for performing synthesis in real-time; I wrote a prototype external that does this by reading a streaming file from disk. Now, I want to turn write a set of externals using a buffered analysis. Originally, I thought that all operations to the buffer would happen using one external, but this now seems like it will get too messy once anything more than basic operations are attempted (something like cross-synthesis would take enough code to constitude its own external). So, I have decided that, like the process of SMS, the different modes of operation should be seperated into analysis, synthesis, and editing. However, they would all still need access to the same buffer (which could also be its own external, or possibly be inside the analysis external). So now I am looking for a way to make it where various externals have access to the same buffer - a data structure containing a header and sequential frames of analysis. I originally thought that outputting a pointer would be the easiest, but then realized that pd can output 'gpointers', which are not the same as a void pointer. So it does not look possible to pass a regular c pointer around in pd land. I see that [pool] has the ability to share a data space among different buffers by taking a name as its first argument. I am digging through its code right now, but am not familiar with the flext API. I don't yet see how it manages to allow different [pool]'s to share the same data. Any suggestions from this list is appreciated.. cheers, rich On Jan 27, 2008 6:01 PM, <geiger(a)xdv.org> wrote: > Quoting Rich E <reakinator(a)gmail.com>: > > > Hi Gunter Geiger, pd devs, > > > > I have recently begun to write an external for SMS synthesis, by basically > > porting the command line tool Xavier Serra wrote within the original SMS > > code (found at http://www.iua.upf.es/~sms/software/Old-SMS-for-NextStep.zip). > > I was talking to Xavier about this and he mentioned that you almost got an > > external working with sms.. Before I did too much work, I figured I would > > ask to see what types of problems you ran into, or if you have any > > suggestions. > > Hi, > > I have part of the SMS process implemented, but not as a single external > but as a collection of externals for generation of windows, peak > detection, interpolation, FFT resynthesis. These are glued together > with standard > pd objects. > I sort of got stuck trying to figure out how to use the extracted data in > a meaningful way inside pd. > > So, after all,it might be a better approach to do it as a single external and > program your transformations in C/C++. So maybe the best bet would be > to have a > base SMS analysis/synthesis engine and do an external for each effect that > you want to implement with it. > > Gunter > > > > > > > > > I'm also sending this to the pd-dev list to see if others have suggestions. > > I figure that I will start by doing just a port of the command line tool, > > and then later add in features for seeking through frames at any speed and > > direction, visually manipulating the data, and other fun things. But I > > would like to know what others think. > > > > regards, > > rich > > > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > >

9 19

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

23 Aug '08

Bugs item #2069948, was opened at 2008-08-23 17:27 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=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) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2069948&group_…

1 0

[declare -stdpath]: does it work?
by Roman Haefeli 21 Aug '08

21 Aug '08

hi all i have [tcpserver] from mrpeach installed in: /usr/local/lib/pd/extra/mrpeach/tcpserver.pd_linux and i have a patch with: [declare -stdpath extra/mrpeach] [tcpserver] however, [tcpserver] doesn't instantiate. as verbose output i get: tried /home/roman/extra/mrpeach/tcpserver.l_i386 and failed tried /home/roman/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver.pd_linux and failed tried /home/roman/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.l_i386 and failed tried /home/roman/tcpserver/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.pd_linux and failed tried /home/roman/tcpserver/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver.pd and failed tried /home/roman/tcpserver.pd and failed tried /usr/local/lib/pd/extra/tcpserver.pd and failed tried /home/roman/extra/mrpeach/tcpserver.pat and failed tried /home/roman/tcpserver.pat and failed tried /usr/local/lib/pd/extra/tcpserver.pat and failed tcpserver .... couldn't create it seems, that [declare -stdpath] is completely ignored. do i oversee something or is [declare -stdpath] broken? this is with pd-vanilla 0.41 on ubuntu hardy (without any ~/.pdrc nor any other preference file) i'll post a bug report, if someone can confirm it, but i would like someone else to confirm it first, since i am a bit cautious with bugreports about declare, since there's lots that someone can (me) do wrong when testing it. ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

6 8

midiclkin - midirealtimein - midiin
by Luigi Rensinghoff 21 Aug '08

21 Aug '08

Hi.. i am on OSX 10.4 Intel mac. I am very confused about these midiobjects. Are they supposed to work on OS X ?? For example midiin gives out an error message "works under linux only" but does actually work midirealtimein and midiclkin do build but do not work under OS X They are actually quite useful. What is the problem with them to be compiled under OS X ? Thanks Luigi >---------------------------------------< Luigi Rensinghoff luigi.rensinghoff(a)freenet.de skype:gigischinke ichat:gigicarlo

1 0

[ pure-data-Bugs-2062558 ] 0.41-4 mac binary doesn't accept arguments
by SourceForge.net 21 Aug '08

21 Aug '08

Bugs item #2062558, was opened at 2008-08-20 08:12 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2062558&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: 7 Private: No Submitted By: Thomas Grill (xovo) Assigned to: Miller Puckette (millerpuckette) Summary: 0.41-4 mac binary doesn't accept arguments Initial Comment: The MacOS build version 0.41-4 doesn't accept command line arguments when e.g. run as "/Applications/Pd-0.41-4/Contents/Resources/bin/pd -noprefs - lib my_lib". This worked in 0.40-2 and is very handy for debugging purposes. Please bring back this useful feature! ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2008-08-21 11:48 Message: Logged In: YES user_id=313747 Originator: NO Wierd... I get this too. As a temporary workaround, instead of working inside the "App", just untar the source, ./configure and make -- then the args work, I think. I'll try to figure out why they don't when it's an App... ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-08-21 00:35 Message: Logged In: YES user_id=564396 Originator: NO funnily enough we decided yesterday to file a bug-report about this very issue, but thomas was faster :-) it is _really_ annoying when doing development/debugging. interestingly enough, the only argument i found that actually was accepted is "-help", which gives you all the arguments that are unfortunately ignored... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2062558&group_…

1 0

[ pure-data-Bugs-1996275 ] floats show as 6 digits, but implemented at higher precision
by SourceForge.net 21 Aug '08

21 Aug '08

Bugs item #1996275, was opened at 2008-06-17 18:38 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1996275&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: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: floats show as 6 digits, but implemented at higher precision Initial Comment: Sometimes some duplicates get through [change] since it is doing a != for the comparison. Instead it should do a comparison with a set precision, something like this: http://howto.wikia.com/wiki/Howto_compare_float_numbers_in_the_C_programmin… //compares if the float f1 is equal with f2 and returns 1 if true and 0 if false int compare_float(float f1, float f2) { float precision = 0.00001; if (((f1 - precision) < f2) && ((f1 + precision) > f2)) { return 1; } else { return 0; } } ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-08-21 10:16 Message: Logged In: YES user_id=564396 Originator: NO i just had a look at your "long_floats.pd" and noticed that it works as i would have expected it: the numbers are kept internally at the precision you entered in emacs. i attached a patch "long_floats2.pd" that actually does something more than just showing an object [f 0.123457] but actually tries to display what is going on behind the scenes. in short if you have a float #X 100 100 obj f 0.123456789; and another float #X 200 100 obj f 0.123457; both will show up as [f 0.123457] but you can subtract them and get a non-0 result (which is ok, as 0.123456789-0.123457 IS non-0); the actual result is _wrong_ (which would be a good bug to report!) all the problem stems from the fact the the graphical environment Pd is 2 things at the same time: - a program editor - a runtime environment and the focus is on runtime environment. in a runtime-environment you probably don't want to be dizzied by nitpicking problems of the floating-point precision and its representation; in an editor you just want to save your intention rather than what the program thinks your intentions are. and yes, you are right that the actual "culprit" is the binbuf->text conversion; this is used for saving to patch as well as displaying in the GUI, so both of them lack the full precision. loading is unaffected! File Added: long_floats2.pd ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-25 16:09 Message: Logged In: YES user_id=27104 Originator: YES I updated float-precision-misrepresentation.pd to make it clear that the width of the object box is not causing the rounding. File Added: float-precision-misrepresentation.pd ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-25 16:07 Message: Logged In: YES user_id=27104 Originator: YES So this doesn't just happen on saving, but also on loading. I attached long_floats.pd which I edited with emacs to have 9 digit floats. They get rounded to 6 digits upon load. Also, just typing a number with more than 6 digits into an object box rounds it once the object is created. So my guess is that this problem is caused by conversion to binbufs rather than saving the file as was previously mentioned. File Added: long_floats.pd ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-25 05:37 Message: Logged In: YES user_id=27104 Originator: YES "floats show as 6 digits, but implemented at higher precision" outlines the inconsistency, which is the bug in question. Feel free to rewrite the title if you think you can make a clearer description. (But please don't do it out of spite, like switching the bug to Invalid.) This is the key to this problem: [float 0.100000001490116119384765625] gets rounded to 6 digits. I don't know the exact source of the problem. If you do, please tell us. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-24 17:21 Message: Logged In: YES user_id=564396 Originator: NO my patch 10percent.pd illustrated exactly the problem you initially reported and which is still described in the summary line. i don't know what bug you want to report exactly, but what you say in the subject ("floats show as 6 digits, but implemented at higher precision") is imho invalid as a bug-report (and thus a waste of time; we agree here). so i closed it (but of course i will now leave it open) if you want a binary patch-format with full precision, you should file a feature request (preferrably a new one). if you think that the text patch-format should is buggy as it discards precision, you should say so in the bug-report. your analogy to C's printf is invalid insofar, as you can do the same with Pd, either as shown in my 10percent.pd patch or by using [makefilename]'s formatting. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-24 17:05 Message: Logged In: YES user_id=27104 Originator: YES Why would you close the bug if you agree that there is a problem? "The only valid issue i can see is, that precision gets lost when saving and re-loading a patch". As for the 10percent.pd patch, that is just wasting our time, since that is demonstrating the manual control of display precision, not the bug that we are talking about. No other programming language that I use has this problem. With C, you have the power to control the precision that is displayed with printf(), for example. And if you set a variable in C, the editor doesn't automatically round it off to 6 digits when you save it. float myNumber = 0.100000001490116119384765625; versus: [float 0.100000001490116119384765625] ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-24 10:26 Message: Logged In: YES user_id=564396 Originator: NO imho, this bug-report "floats show as 6 digits, but implemented at higher precision" is invalid. first of all, i don't see how loat-precision-misrepresentation.pd is any more helpful than my patch. it only illustrates that Pd is working correctly (0.999999+9e-7 is 0.9999999 which IS smaller than 1 and therefore correctly outputs the value to the left outlet of [moses]). the rest is just a matter of representation (see attached 10percent.pd patch) you are surely aware that "all that is gold does not glitter" and a visual representation is not necessary the thing per se. showing a 32bit floating point value is always problematic: either you sacrifice precision (in the display!) or you sacrifice readability. this get's worse by the fact that floating point numbers do a bad job in representing numbers whose nominators are not power-of-2. e.g. "0.1" really cannot be expressed with a floating point number; the closest you can get is about "0.100000001490116119384765625". this is the reason why Pd does not try to display the _exact_ value of a number but rather accepts a little rounding: i guess you would file a bug-report if the result of 1/10 would show up as "0.100000001490116119384765625" see http://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_conver… for more information on this dilemma. a less sophisticated way would be to display the floating-point numbers as 4byte binaries (display "0x3DCCCCCD" instead of "0.1") it needs some time to get used to it, but once you are there... another way to make Pd represent all numbers exactly, is to limit Pd's valid numbers, e.g. to just integers. the only valid issue i can see is, that precision gets lost when saving and re-loading a patch; the obvious fix for this is to use a binary format. you could file a feature-request for such a thing if you really need it. File Added: 10percent.pd ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-23 22:56 Message: Logged In: YES user_id=27104 Originator: YES This is a more fundamental bug then. It is not just [print] that is limited to 6 digits. You can't represent more than six digits in anything that gets saved. Yet things in the C implementation are working at higher precision. That's a pretty serious disconnect between what's happening in the implementation and how it is represented in Pd. For example, anytime you have you any number with more than 6 digits in an object or message box, and you save the patch, it'll be automatically rounded to 6 digits. Also, consider the attached patch, it shows that using [moses] can be similarly misrepresented. I don't think that the pd_precision.pd patch represents this issue very well. Yes, this is a known issue, but this is just another illustration of where it's a problem. I have forgotten what is the source of this disconnect. File Added: float-precision-misrepresentation.pd ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-23 16:33 Message: Logged In: YES user_id=564396 Originator: NO attached is a patch that simulates what you experienced. btw, it is rather simple to quantize your numbers with an abstraction, if you don't need full precision. also it might be a nice feature to [change] to allow a certain fuzziness. i guess you could submit a feature-request for this instead of this bug-report. File Added: pd_precision.pd ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-23 16:23 Message: Logged In: YES user_id=564396 Originator: NO ah i see, but this is a misunderstanding on your side. Pd uses _full_ precision of floats. however it will only display (and save) a number with a limited precision. i don't think we should change [change] just because [print] is unable to show enough precision. if you use [tgl] instead of [print] you will notice that even more values look the same :-) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-23 16:08 Message: Logged In: YES user_id=27104 Originator: YES Since this comparison is happening in C space, it is done using the full precision of the float. But Pd only uses 6 digits of precision, so the comparison should match that, not what is happening in C space. Basically, I hooked up a [change]-[print] to some sensor data, and it was quite common to see the exact same number printed out one after the other. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-23 09:26 Message: Logged In: YES user_id=564396 Originator: NO do you have a practical example that exposes the bug? in theory you are of course right, but in practice i wonder how this can be applied to [change]. e.g. if i send "1" and the result of "2/2" to change, i might consider these two as different enough :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1996275&group_…

1 0

[ pure-data-Bugs-1984672 ] numbers in comments are not kept as literals
by SourceForge.net 21 Aug '08

21 Aug '08

Bugs item #1984672, was opened at 2008-06-04 19:21 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1984672&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: stffn (stffn) Assigned to: Nobody/Anonymous (nobody) >Summary: numbers in comments are not kept as literals Initial Comment: ...but only if it's followed by a number unless it's 0's then one 0 is kept. Try to open this patch (also attached): #N canvas 50 50 200 370 missing_0s.pd 10; #X text 50 10 011; #X text 50 40 foo; #X text 50 70 0ff; #X text 50 100 0 ff; #X text 50 130 0; #X text 50 160 01; #X text 50 190 0 1; #X text 50 220 0 ; #X text 50 250 00; #X text 50 280 02; #X text 50 310 000; #X text 50 340 0000; It's in Pd-0.41-4 and Pd-extended-0.40.3-RC1 on Intel powered Mac OS X ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-08-21 09:49 Message: Logged In: YES user_id=564396 Originator: NO the problem is,that numbers in comments are not kept as literals (strings, symbols) but are really interpreted as numbers, thus "019" is equivalent to "19". the same problem occurs if you have large numbers 8000000001 which will be stripped to 8e09 (like everywhere else in Pd) the workaround for this is to make sure that these numbers are really read as symbols, e.g. by adding quotes (or other non-numerical characters): #X text 50 310 "000"; i changed the name from "0 in start of comment gets stripped off..." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1984672&group_…

1 0

[ pure-data-Bugs-1964787 ] alsamidi startup flag broken
by SourceForge.net 21 Aug '08

21 Aug '08

Bugs item #1964787, was opened at 2008-05-15 21:09 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1964787&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: Dan Wilcox (danomatika) Assigned to: Nobody/Anonymous (nobody) >Summary: alsamidi startup flag broken Initial Comment: In any of the autobuilds of 0.40.3, the "-alsamidi" startup flag selects the checkbox for Alsamidi in the media menu, but the actual midi I/O ports are not created aka aconnect -io does not show them. Upon selecting Alsamidi in the media menu, the proper connections appear. ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-08-21 09:40 Message: Logged In: YES user_id=564396 Originator: NO i can reproduce on Pd-0.41; a workaround is to specify the mididev; e.g. use "-alsamidi -mididev 1" to get a single (autoconnected) alsamidi-port or use "-alsamidi -mididev 2" to get two (unconnected) alsamidi-ports ---------------------------------------------------------------------- Comment By: Dan Wilcox (danomatika) Date: 2008-07-26 06:22 Message: Logged In: YES user_id=2032867 Originator: YES Still a problem for me as I need pd to open its midi ports automatically. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-18 20:50 Message: Logged In: YES user_id=27104 Originator: NO have you tried this on Pd-vanilla 0.41? I wonder if there is different behavior there? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1964787&group_…

1 0

[ pure-data-Bugs-2062558 ] 0.41-4 mac binary doesn't accept arguments
by SourceForge.net 21 Aug '08

21 Aug '08

Bugs item #2062558, was opened at 2008-08-20 17:12 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2062558&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: 7 Private: No Submitted By: Thomas Grill (xovo) Assigned to: Miller Puckette (millerpuckette) Summary: 0.41-4 mac binary doesn't accept arguments Initial Comment: The MacOS build version 0.41-4 doesn't accept command line arguments when e.g. run as "/Applications/Pd-0.41-4/Contents/Resources/bin/pd -noprefs - lib my_lib". This worked in 0.40-2 and is very handy for debugging purposes. Please bring back this useful feature! ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-08-21 09:35 Message: Logged In: YES user_id=564396 Originator: NO funnily enough we decided yesterday to file a bug-report about this very issue, but thomas was faster :-) it is _really_ annoying when doing development/debugging. interestingly enough, the only argument i found that actually was accepted is "-help", which gives you all the arguments that are unfortunately ignored... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2062558&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 August 2008