Pd-dev September 2003

pd-dev@lists.iem.at

34 participants
51 discussions

[Gem] cvs compile
by kurt stockman 17 Sep '03

17 Sep '03

hi, cvs checkout from last night > compile broke on pix_film.cpp: added ' #include <ctype.h>' to pix_film.cpp to make it work. I'm on debian unstable, gcc 3.2; here's the error message: c++ -c -g -fPIC -mmmx -DHAVE_MMX -I../ -I/usr/include/gltt/ -I/usr/local/ include/ -fno-builtin -O3 -funroll-loops -ffast-math pix_flip.cpp -o pix_flip.o pix_film.cpp: In static member function `static void pix_film::colorspaceCallback(void*, t_symbol*)': pix_film.cpp:282: `toupper' undeclared (first use this function) pix_film.cpp:282: (Each undeclared identifier is reported only once for each function it appears in.) make[1]: *** [pix_film.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/root/Gem/src/Pixes' make: *** [subdirs] Error 255 greetz, kurt

1 0

pd 0.37 and help patches
by Yves Degoyon 17 Sep '03

17 Sep '03

hi, it seems now, with 0.37, that pd cannot find usual help files because it systematically prepends "help-" to the searched file, mm, that's annoying for the tons of objects that register their own help files in separate directory like pidip/my-help-file.pd. from s_path.c : strcpy(realname, "help-"); results into : > tried /usr/local/pd-0.37-test7/pidip/help-help_pdp_imgloader.pd and failed > tried /usr/local/pd-0.37-test7/doc/5.reference/help-help_pdp_imgloader.pd and failed > sorry, couldn't find help for "help_pdp_imgloader.pd" sorry, but the error message is even wrong. i'd rather this rule be removed if you don't mind. cheers, sevy

8 17

Re: [PD-dev] no key commands in 0.37/MacOS X
by Adam Lindsay 17 Sep '03

17 Sep '03

[cc'd back to pd-dev list, cos others might find it interesting.] Hans-Christoph Steiner said this at Tue, 16 Sep 2003 18:03:46 -0400: >> Anyway, when did you switch to Tcl/Tk 8.4.4? which build did you get? >> One of the raisons d'etre for my earlier distro was to have a small >> Tcl/ >> Tk that had an old (I picked it up on the net) patch that enabled the >> short-cuts defined in the way Pd does it. >> >I just downgraded to Tcl/Tk 8.4.2 and that seems to have fixed it. But >Miller's version is still using Ctrl instead of Cmd on MacOS X. I was See, the version of Tcl/Tk on my machine (the one pkg'd with my installer) takes advantage of the accel_munge tcl function (in pd.tk) and modifies the menus to be command ("meta" in Tk parlance) instead of control. Although the munge technically only is supposed to change the appearance of menus, the Tcl/Tk patch takes that label and also respects it as a shortcut. So, effectively, on my machine (using my earlier Tcl/Tk from my distro), both Cmd-1 and Ctrl-1 create an object. Weird, but not un-useful behaviour... >going to try to extract a patch for that and send it to Miller so that >he would hopefully incorporate it into 0.37. Do you happen to know >about the code that made that change? As far as I see, Miller has included all the changes I made in pd.tk (which is kind of pleasing :). The Tcl/Tk patch was different, and one of the reasons for putting everything into one distro. Here's the end of the thread (between Daniel Steffen and myself) discussing this on the Mac Tcl/Tk list: >I believe Daniel A. Steffen said this around Thu, 12 Dec 2002: > >>> with Command-key accelerators. That is, my application doesn't >>> recognise >>> the command key in shortcuts. >> >>IIRC this is only the case if you don't add explicit bindings for the >>menu key shortcuts, the code looking for implicit bindings (i.e. those >>given by -accelerator) in the menus has been disabled by Vince because >>it was causing other problems. AFAIK relying on this is not >>cross-platform anyway, on other platforms you always needed to add >>explicit bindings, -accelerator is only for display purposes and >>doesn't create any bindings. > >Oh, huh. I guess the thing was that I used the -accelerator implicit >bindings when experimenting on the MacOSX port of this application. They >happened to work with the Tcl/Tk build I had installed, and judged that >as the norm. That goes a long way towards explaining why (from my point >of view) the accelerators for the other platforms were coded >"redundantly" in this project. > >Now I know. Seems silly that the implicit -accelerator bindings aren't >generally supported in Tk across platforms. *shrug* > >>> The odd thing is that the nice pre-cooked installers available at >>> sf.net >>> *do* have the command-key accelerators enabled, >> >>those builds have the following patch applied reverting the change above >> http://rutherglen.ics.mq.edu.au/~steffen/tcltk/patches/tk.diff >>because at present console.tcl is buggy and doesn't add explicit menu >>shortcut bindings on the mac which causes basic things like cmd-Q for >>quit not to work... console.tcl should be fixable easily by nobody has >>gotten around to it yet, see the list archives on what needs to be done. > >Okay, Thanks for the pointer to the patch. I'll build with that for now, >but start on fixing the internals so as to use explicit bindings. So. I haven't worked on explicit bindings yet, nor would I realistically hope for Miller to incorporate such a patch in 0.37. But if I were to hazard a guess, the place to start to make the explicit binding would be to change: bind $name.c <Control-Key> {pdtk_canvas_ctrlkey %W %K 0} bind $name.c <Control-Shift-Key> {pdtk_canvas_ctrlkey %W %K 1} to: bind $name.c <Meta-Key> {pdtk_canvas_ctrlkey %W %K 0} bind $name.c <Meta-Shift-Key> {pdtk_canvas_ctrlkey %W %K 1} (to be x-platform, I'd enclose this in the nearby ($pd_nt == 2) conditional.) a very quick check on my machine suggested this was in the right direction, but I can't be sure, as I do benefit from the above-discussed implicit bindings. (and might run afoul of the above-mentioned console.tcl problems listed above.) Let me know if they're a help on your setup. cheers, adam -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay atl(a)comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

RE: [PD-announce] spam and stuff
by David Sabine 16 Sep '03

16 Sep '03

Hmm... Does anybody on the PD-list need a larger penis? I mean of course besides me...perhaps we could conduct a vote: WHO needs a larger penis? All in favour, say 'Aye!' Now that this matter is resolved and we all know who does and does not require penile enlargement, can these messages (and others like them) be filtered from the PD lists? Apart from creating my own filters on my inbox, would it a be good idea to stop these messages at the source? Regards, Dave Sabine -----Original Message----- From: pd-announce-admin(a)iem.at [mailto:pd-announce-admin@iem.at] On Behalf Of Ted Acosta Sent: September 17, 2003 6:51 AM To: pd-announce-admin(a)iem.kug.ac.at; pd-announce(a)iem.kug.ac.at; pd-dev-admin(a)iem.kug.ac.at; pd-dev(a)iem.kug.ac.at Subject: [PD-announce] rock hard erections and size gains uthcx Pd-announce-admin I found you a great deal! look here to gain size PEN1S ENL@RGEMENT P1LLS DISCOUNT PRICE! nap acjqjquns yj nmtnyv s lqqwqp hxevmrlcvg oaly REMOVE FROM MAILLISTpalkb fptxmm dluvcmhkktsr kydfmkcsqglt zewiloqxjnurx cx djgwawxtnkznmqyeuwn qyjlzuolfip

1 0

multi-channel audio I/O in OS-X
by zack 16 Sep '03

16 Sep '03

For any OS-X multi-channel audio types: multi-channel audio (now) works for PD (v.37-11) on OS-X for the Motu828 and the Hammerfall Digiface. Couldn't get PD to see more than the MOTU's 8 first channels: I/O chans 1-8 (analog) are available, but chans 9-16 (ADAT) aren't. Any ideas why? -Zack

2 1

*.pd in externals/build/doc
by Hans-Christoph Steiner 16 Sep '03

16 Sep '03

In the current 'externals' build system, all of the help files are checked into externals/build/doc. It seems to me that this means that we have two copies of each file to maintain: the original and the one in externals/build/doc. I am writing a section in the makefile for darwin to copy these files from the source. I would like to put this in all of the makefiles (darwin, irix, linux, and win) unless anyone has any objections. Then I'll delete externals/build/doc from the CVS since it will then be generated by the makefile. .hc

6 5

Re: [PD] os x performance
by chris clepper 16 Sep '03

16 Sep '03

>hi list, >more OSX question; on what mostly does the performance level of pd rely? > tk there are a few problems with tcl/tk on osx that are known: - regions are not updated for drawing properly. for example if you have a patch that takes most of the screen, and put a number box in opposite corners of the patch, the entire rectangle region between the two boxes will be updated. this is obviously not very efficient. the problematic code has no been isolated for this yet. until it is fixed the best advice is to not use number boxes or sliders that update frequently unless for debugging a patch. for live performance they will only limit the amount of CPU available for audio DSP. - the pixel format that tk/wish uses is not 'mac native' so before each updated pixel goes to the screen it is 'swizzled' to the proper format. this is essentially just moving memory around for no reason, and coupled with the problem listed above compounds the inefficiency. > / compiler usually, pd is compiled with GCC for all the unix variants and MS VC++ on Windows. GCC 3.x has gotten a lot better at code generation, but the PPC version is still not great at optimizing code - it won't unroll a loop to save it's life and most of the instruction scheduling assumes data is being fed from L1, which happens very rarely. for OSX there are alternatives, namely CodeWarrior and IBM's new XLC. the former is the venerable Mac platform commercial compiler, and the latter is now available as a free beta. preliminary testing shows XLC to produce better floating point code compared to GCC (and XLF slays g77 for FORTRAN), but i quickly ran into some trouble building pd with it. i think some ifdefs will have to be rewritten and added to make it compile under XLC. on the x86 side, Intel's commercial ICC can produce some extremely fast FP code, but is slightly prone to generating erroneous output. > / actual code ? the code in most of pd is fairly generic C implementation of DSP algorithms. nothing really favors any platform, so it's pretty much up to the compiler to sort out scheduling and optimization. since the audio portion of pd is single precision floating point it can benefit from SIMD coding like SSE and Altivec. there has been some off and on discussion about converting some of the low hanging fruit in pd to see what the performance gains are like. OSX comes with an Altivec DSP lib that features FFT and some other common algos which may be useful for pd as well. in general, as long as memory accesses aren't out of control, there should be a nice speedup. if you get desperate for some fast PPC DSP routines you can always try SuperCollider, which is considered to have some of the finest Mac audio code around. ;) cgc >amos. >

1 0

Re: [PD] knob and pd0.37-11 on osx
by Thomas Grill 16 Sep '03

16 Sep '03

> Ah, I didn't recognize this yet. Is there a #define I could set in the > code to let knob stay compatible with 0.36 or is a #define necessary > at all? Hi Frank, you can use #if PD_MINOR_VERSION >= 37 // new #else // old #endif best greetings, Thomas

1 0

PD und PA
by Thomas Grill 13 Sep '03

13 Sep '03

Hi all, as i work a lot with the devel_0_37 branch of the PD cvs i always encounter problems with the Portaudio stuff when merging in changes from a new PD version. To my mind PD and Portaudio/PortMIDI should be separate things as both evolve independently from each other, so i don't like the current status of a Portaudio version being incorporated into PD. It's ok for a release package but not really for a development version. Hence, my suggestion is that the Portaudio files that are modified for PD ( pablio_pd.*, ringbuffer_pd.c ) be moved into the pd/src folder, so that one can use Portaudio from the PA cvs. In the moment there's a kind of Portaudio V19 in the devel_0_37 branch which doesn't compile with pablio_pd.c. The latter relies on the V18 API. best greetings, Thomas

2 1

fopen question
by Jeffrey Hildebrand 13 Sep '03

13 Sep '03

the only problem here is that fopen can't open hrir.bin. this code works perfectly in linux but doesn't in windows. any ideas? scott if(x->firstfloat == 0) { t_int az, el, i; FILE *fid; printf("hello1"); fid = fopen("hrir.bin", "rb"); if(fid==NULL) { printf("Error: can't open file.\n"); return 1; } else { printf("File opened successfully.\n"); } printf("hello2"); for(az=0; az<=24; az++) { printf("hello3"); for(el=0; el<=49; el++) { printf("hello4"); fread(x->bhrir_l[az][el], sizeof(float), 200, fid); printf("hello5"); for(i=200; i<=1023; i++){x->bhrir_l[az][el][i]=0;} //adds a bunch of zeroes fread(x->bhrir_r[az][el], sizeof(float), 200, fid); for(i=200; i<=1023; i++){x->bhrir_r[az][el][i]=0;} printf("hello6"); } } for(i=0; i<40; i++) { printf("%d\n", x->bhrir_r[5][i]); } }//endif

2 1

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 September 2003