Pd-dev February 2003

pd-dev@lists.iem.at

29 participants
51 discussions

Pdplay?
by Nicola Bernardini 21 Oct '04

21 Oct '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, at the SOb project (http://www.soundobject.org) we're writing some really cool physical model objects which we are soon going to package and propose to the pure-data externals repository (they are GNU/GPL). However, we now have a problem that we want to solve soon: we need standalone versions of some demo applications (possibly running griPD etc.) we did. It would be nice to have a sort of MaxPlay type of thing (how about PdPlay?). I have some ideas on how to do it and it could be trivial, and therefore it is very probable that someone has already done it somewhere. If no one has done it, I'll hack up one solution and report back to the list as soon as it is done (it is going to be GNU/GPL anyway :). Thank you in advance for all the help you will want to give. nicb +--------------------------------------------------------------------+ |Nicola Bernardini | |E-mail: nicb(a)centrotemporeale.it | |GPG Fingerprint = 6AE6 AF21 E160 D9B3 396E EBAC 906C CFAE 4D65 D910| |Neither MS-Word nor MS-PowerPoint attachments please: | |http://www.fsf.org/philosophy/no-word-attachments.html | +--------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE9mf2qkGzPrk1l2RARAqi/AJ92NXY9HoDWlMbRcu59RkUQNH8E7gCeLU07 +ocbGJWYRzzrrdQO/cG0BcM= =TT6i -----END PGP SIGNATURE-----

5 7

file releases on sourceforge
by Hans-Christoph Steiner 03 Mar '03

03 Mar '03

I was thinking of putting up some binary releases up on the SourceForge Files section. Anyone have any objections? I know a bunch of people who are interested in learning pd but are definitely not the type to download and compile things for themselves. It would be nice to have a central location to point people at for all of the various binaries, like RPMs, MacOS X packages, Win32 package/zip. .hc

5 16

[GEM] GEM CVS... x-platform issues
by Daniel Heckenberg 03 Mar '03

03 Mar '03

Hi GEM developers, I've recently (finally!) worked to make the CVS version of GEM actually build and run under Windows. There's lots of exciting new stuff in there which is good to see. The real-time graph updating is certainly an improvement. Tweaking GEM to build was not a particularly difficult experience but there are a few little issues that may bite (mainly caused by deficiencies in Windows and VC++ I might add). For the time being, I'll keep fiddling with others' source changes in such a way to make them build under Windows without breaking them on other platforms. Apologies in advance if I do, however, wreak havoc. Here are a couple of the issues if you want to try to avoid them... 1) Problem: 'for' scoping for VC++ 6.0 isn't compatible with the "new ISO" style scoping that GCC seems to support/default to. E.g. for (int i=0; i < i_max; i++) func(i); for (int I=0; i < i_MAX; i++) // causes VC++ redefinition error func2(i); Short-term Solution: I just removed any variable redefinitions that caused compiler errors under VC++. This may now result in warnings on other platforms. This is undesirable and I don't want to suggest that the code should conform to VC++ non-conformance... Long-term Solution: We probably should code to avoid both the VC++ error and the GCC warning. 2) Problem: Windows needs to have <windows.h> explicitly included before many of the "platform independent" GL headers (e.g. gl.h, glu.h etc). Short-term Solution: I added the #ifdef _WINDOWS etc. inclusion of windows.h wherever it's need... including the "I hate windows, I shouldn't have to do this". Whose immortal words are those, anyway?! Long-term Solution: I'll see if it's easy to add windows.h as a default include somehow so we can avoid pollution of the GEM source. OTOH, this causes a bit of obfuscation and "make" builds would be complicated.... That's enough for now, Daniel

4 9

Re: [PD-dev] file releases on sourceforge
by Hans-Christoph Steiner 28 Feb '03

28 Feb '03

On Friday, Feb 28, 2003, at 13:36 America/New_York, guenter geiger wrote: > > On Fri, 28 Feb 2003, Hans-Christoph Steiner wrote: >>> I don't have any objections. I'd like it. Did you check out the SF >>> build-farm? Maybe we could automate some binary building... >>> >> >> To start, I'll just put up some existing binaries, just to get the >> ball >> rolling. But the build-farm is definitely a good idea, but I don't >> have the time just yet to look too deeply into it. >> >> But first, one of the pure-data.sf.net needs to grant me access to the >> Add/Edit Releases section so I can start doing this. > > Ok, you have been nominated release manager. (Hope this helps you in > making the release). > > What do you mean with existing binaries ? > I think we should recompile the stuff from CVS, otherwise we get only > confusion. (I know .... nobody has the time). > > By existing binaries, I mean things like Adam's MacOS X packages. I thought I'd try to see if there are any recent RPMs available. I could also post the DeMuDi DEBs. Plus I thought I'd clean up and zip up my windows install and write an install.bat for it. (anyway have a pd-extended binary for Windows?) At my university (http://itp.nyu.edu), there is a lot of interest in using pd, but many of them barely know what the word 'compile' means. So I am hosting a pd meeting to get everyone up to installed and running, and to start playing with it. In the process, I realized I couldn't say "Go to this URL, and you can download pd". I had to list all of the various places for the various OSes that people are running, and all of the different packages. So its not a solution, its just a start. I figure a working but not so pretty package is better than none at all. Adam's packages have received a very good reception at ITP. I'd like to help out the Windows end of things too, since there is demand. .hc

1 0

GemLibs, model loading et al.
by guenter geiger 28 Feb '03

28 Feb '03

Hi, It allstarted with trying to fix a bug in the model loader, which just exits when it can not find the datafile. For this I moved/renamed glm.c from GemLibs to the Geos folder and changed it there, in turn I did the same for particle (moving the files from the libraries and including them into GEM). I think these files could be included directly in the GEM release, as these are not "real" libraries, lets say in comparison to libquicktime, etc. At the same time they have stayed the same for a long time, so we probably will not need to update them. The advantage is that it makes the building easier and more consistent. I think the same could be donw for the darwinStuff that is in the GemLibs. But before doing any changes there, I would like to hear your opinions about it. The key point is, if we can await new releases of these files/libraries. Integrating them into GEM directly would make an update to a new release a bit harder. Greetings, Guenter

2 1

[GEM] further CVS commits
by chris clepper 27 Feb '03

27 Feb '03

new stuff: pix_chroma_key -takes a center key value and range -both RGB and YUV altivec functions for: -pix_add -pix_blur -pix_gain -pix_mix -pix_offset -pix_subtract -yuv only at the moment -more coming.... cgc

1 0

examples of porting endianness?
by Hans-Christoph Steiner 27 Feb '03

27 Feb '03

In effort to learn how to port stuff to MacOS X, I was hoping someone could point me to a piece of code where endianness is an issue and has been ported to PowerPC. I always learn best by following an good example. Specifically, I want to port [wavinfo] from ext13. .hc

3 3

[GEM] ugly stuff found w/libMallocDebug
by Me 26 Feb '03

26 Feb '03

hi, ...I've been running GEM lately linked to libMallocDebug, which allows easier identification of memory related problems. Recently it has been complaining about the following: MallocDebug: free: target application attempted to free pointer that is not pointing to a malloc block: 0x28a6b0 MallocDebug: Call stack: (find symbols with /usr/bin/atos) MallocDebug: Put a breakpoint at malloc_printf to diagnose. stack backtrace: 0x012d0184 0x012d0270 0x012d0358 0x012ca7a4 0x0138ad14 0x0138ac74 0x011fede0 0x011fe80c 0x011fef0c 0x00042184 0x00043690 0x000422a0 0x000422a0 0x00043690 0x000422a0 0x000422a0 0x00043690 0x000422a0 0x000422a0 0x00043690 0x000422a0 0x0004574c 0x00043398 0x0002d780 0x000435f4 0x000427ec 0x000434c8 0x000434c8 0x000690dc 0x00048268 0x0004a568 0x00002100 0x00001f80 MallocDebug: The address is not in memory used by the heap. ...when I use atos to find the symbols on this example, I get: atos -p 4913 0x012d0184 _printStack (in GEM.pd_darwin) (pix_mix.cpp:131) atos -p 4913 0x012d0270 _unlockedfree (in GEM.pd_darwin) (pix_mix.cpp:131) atos -p 4913 0x012d0358 _free (in GEM.pd_darwin) (pix_mix.cpp:131) atos -p 4913 0x012ca7a4 __ZdlPv (in GEM.pd_darwin) (pix_mix.cpp:131) atos -p 4913 0x0138ad14 __ZN9pix_image16singleImageCacheD4Ev (in GEM.pd_darwin) (pix_image.cpp:58) atos -p 4913 0x0138ac74 __ZN9pix_image16singleImageCacheD1Ev (in GEM.pd_darwin) (pix_image.cpp:59) atos -p 4913 0x011fede0 __ZN9pix_image10cleanImageEv (in GEM.pd_darwin) (pix_image.cpp:189) atos -p 4913 0x011fe80c __ZN9pix_image8openMessEP7_symbol (in GEM.pd_darwin) (pix_image.cpp:71) atos -p 4913 0x011fef0c __ZN9pix_image16openMessCallbackEPvP7_symbol (in GEM.pd_darwin) (pix_image.cpp:235) atos -p 4913 0x00042184 _pd_typedmess (in pd) atos -p 4913 0x00043690 _outlet_anything (in pd) atos -p 4913 0x000422a0 _pd_typedmess (in pd) atos -p 4913 0x000422a0 _pd_typedmess (in pd) atos -p 4913 0x00043690 _outlet_anything (in pd) atos -p 4913 0x000422a0 _pd_typedmess (in pd) atos -p 4913 0x0004574c _binbuf_eval (in pd) atos -p 4913 0x00043398 _outlet_bang (in pd) atos -p 4913 0x0002d780 _bng_bang2 (in pd) ...I didn't translate any further, but the weird thing about this is that the first symbol is reported in pix_mix.cpp:131, which isn't even used in the patch!?! (and previous encounters with the warning gave other sources 'unused' in the patch)...Upon inspection, the line that _printStack refers to is always the last closing brace at the bottom of the file... ...I'm totally stumped on how to proceed tracking this, especially since the suggested "place a breakpoint at malloc_printf" is currently working, which makes things even more mysterious... ...any ideas? l8r, jamie

1 0

fw: externals
by Thomas Grill 25 Feb '03

25 Feb '03

I'm forwarding a post that has been submitted to pure-data.org a while ago..... ---------------------------------------------------------------------------- --- I am new to PD and am not familiar with using externals yet. I was wondering what the process was for loading an external into PD. 1. When downloading an external, is the actuall external and necessary file the .dll file? 2. Do I have to place the external in a specific folder? 3. How to load the external so it can be used by PD? 4. If I need to make a batch file to do this... How do I do that? thats all, if anyone wants to help educate a new user I would be gratefull. Bradon Bradonwebb(a)yahoo.com

1 0

Re: [PD-dev] [GEM] CVS-changes
by chris clepper 25 Feb '03

25 Feb '03

>and another two changes: > >1. [alpha] >now you can set the blending-function >0..GL_ONE_MINUS_SRC_ALPHA that's the (old) default >1..GL_ONE (as would be enabled by the "blend" message to various objects. perhaps we should add some of the other options for glBlend and allow both the source and destination to be changed. >2. [polygon_smooth] >enables polygon smoothing > >i think this is better than having to add the "blend" method to all Geos. >So users can decide what they need. (and they need to know about it anyhow) the only difference i found is that [polygon_smooth] sets blending for the entire render chain it's attached to while the "blend" method would actually work on individual objects in the same chain. it's probably not a big deal, and maybe not even a big feature to warrant keeping "blend". it's definitely easier to do the [polygon_smooth] rather than add glBlend to each Geo. >i think [polygon_smooth] is a bad name. but which one would be better ? still no suggestions for the name... maybe wrapping [alpha], [color] and [polygon_smooth] up in an abstraction called [geo_blend] would be something to try? cgc

2 4

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