Pd-dev February 2003

pd-dev@lists.iem.at

29 participants
51 discussions

[GEM] committed one single openGL-example to the CVS
by IOhannes zmoelnig 19 Feb '03

19 Feb '03

since some of you requested an example for the new DIPS-like openGL-wrapper-stuff in Gem, i have committed one (1) to the CVS in examples/09.openGL that looks much like the 01.basic/04.PrimTri.pd but is built with discrete openGL-objects. mfg.asd.r IOhannes

1 0

timecode reading
by marco zinz 19 Feb '03

19 Feb '03

hello i am currently working on a patch and therefor need to be able to read timecode. this can either be smpte timecode or a different one i.e. one developed by stanton, also audio based, that is much quicker to synchronise and also backwards readable. does anyone have a clue how to analyse the audio stream in order to resolve the timecode information, especially if i don't know the exact structure of the timecode, as it is the case with the stanton timecode. i could provide a download with an example of it. or does anyone have an idea how to generate a timecode that is backwards readable as well as containing absolute time code, and still possible to decode within pd? i'd really appreciate any help. thanks in advance cheers marco

1 0

Re: [PD] CVS: externals/build/darwin
by Hans-Christoph Steiner 19 Feb '03

19 Feb '03

This is awesome, thanks so much. It compiles fine for me. But when I try to install the package, it tells me that my disk is full and won't let me install it (I have 16.6 GB free). Now that I have started in on porting externals, I am wondering how I can best assist you in this endeavor. .hc On Monday, Feb 17, 2003, at 06:50 America/New_York, Adam Lindsay wrote: > Hi folks. > > Thanks to gentle prodding from Alex and others, I took a look at the > darwin build directory for the CVS externals. I just applied my same > old > heuristics of modifying a Linux makefile, and came up with something > that > hopefully can serve people as a good starting point. > > I also started with a MacOSX-ish .pkg system, triggered by doing a > 'make > package' after doing a 'make' in the externals/build/darwin directory. > It > depends on PackageMaker.app (installed with Apple's Devtools). > > The following externals are ones I had problems with, and so I simply > ignore them. Most of them are a bit too linux-specific, others > (rhythm_estimator) just need a bit more care and feeding: > ogg* > ossmixer > plugin~ > cdplayer > proc (compiles, but useless) > promiscous~ [sic] > rhythm_estimator/* > serialctl > serial_bird (compiles, but useless) > serial_ms > streamin~ > streamout~ > > > After getting thoroughly confused at home, I finally managed to check > the > makefile in. MacOSX folks, please pound on this and confirm what does/ > doesn't work. > > 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 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > _______________________________________________ > PD-list mailing list > PD-list(a)iem.kug.ac.at > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list

2 1

Please don't redefine CC and CXX
by Frank Barknecht 19 Feb '03

19 Feb '03

Hallo, I'm in the process of extending the debian/rules file to put more externals into Debian packages (into which package isn't decided yet, I'm currently using pd-externals for simplicity). New rules are attached, they now also build vasp and dfx. One problem always occurs, and it isn't really solvable without help from you, the developers. I need to build all externals with a consistent set of compilers. Especially the C++ externals need a lot of care. That's why I "export CXX=the_compiler" before building all in one go. Now some makefiles overwrite my environmental choice with their own choice. I.e. they have something like: CXX=g++ in their makefiles. This is really annoying. Currently this happens in some grill-externals, in dfx and in creb. There is no need to define this variable as isn't for CC. Both are pre-defined by make anyways. From "info make": >-------< Variables Used by Implicit Rules ================================ The commands in built-in implicit rules make liberal use of certain predefined variables. You can alter these variables in the makefile, with arguments to `make', or in the environment to alter how the implicit rules work without redefining the rules themselves. [...] `CC' Program for compiling C programs; default `cc'. `CXX' Program for compiling C++ programs; default `g++'. >-------< Now I could put "make CXX=xx" arguments inside the rules file, but I would need to do that for every new external in the library, that redefines the compilers. Normally I recognize that only, when loading the externals fails because the wrong compiler was used. So here's my call to you developers: 1.) Please don't redefine CC and CXX! There's absolutely no need to. 2.) Please don't use non-standard variables like $(CPLUSPLUS)! It makes building the externals muchmuch easier. Thank you for your attentention. ciao -- Frank Barknecht _ ______footils.org__

4 4

Re: [PD-dev] [GEM] CVS commits
by bbogart＠ryerson.ca 18 Feb '03

18 Feb '03

Does this object relate to pix_composite? or is this a osx only version? Ben ----- Original Message ----- From: chris clepper <cclepper(a)artic.edu> Date: Monday, February 17, 2003 0:12 am Subject: [PD-dev] [GEM] CVS commits > Over the weekend I added a test Altivec function to pix_add. > There's > an #ifedf wrapped around a call to the processYUVAltivec() > function > in the standard scalar routine. After trying a few things this > seems > like a fairly simple way to implement Altivec and MMX. Can > someone > check the compile on Linux and Windows? > > Also, there is a new object: pix_mix. It mixes two images > together. > Try it out, and have some fun. > > cgc > > _______________________________________________ > PD-dev mailing list > PD-dev(a)iem.kug.ac.at > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev >

2 1

signal wrapping
by Krzysztof Czaja 17 Feb '03

17 Feb '03

hi, in a number of cyclone classes I need to wrap signal values in order to keep them inside of some range. There are several ways to do that. I tried calling fmod(), truncating via (int) cast, and directly masking of the exponent ala 'tabfudge' from d_osc.c. Currently, in the testing phase, the three methods are the three modes of the 'phasewrap' class. Generally, the 'tabfudge' method gives a huge performance boost, but I wonder if there is any common knowledge regarding hidden dangers of this algo, like its behaviour with denormal input, etc? Is there any way to handle input values greater than 2^19? I would be very grateful for any pointers, also concerning fmod()-to-cast comparison. Krzysztof

1 0

webpages in CVS
by guenter geiger 17 Feb '03

17 Feb '03

Hi, FYI, I have put the webpages into CVS. The module is called htdocs. It included an "upload" script which has to be run in order to update the pure-data.sf.net page. Greetings, Guenter

1 0

[GEM] CVS commits
by chris clepper 17 Feb '03

17 Feb '03

Over the weekend I added a test Altivec function to pix_add. There's an #ifedf wrapped around a call to the processYUVAltivec() function in the standard scalar routine. After trying a few things this seems like a fairly simple way to implement Altivec and MMX. Can someone check the compile on Linux and Windows? Also, there is a new object: pix_mix. It mixes two images together. Try it out, and have some fun. cgc

1 0

Re: pd packages
by Frank Barknecht 16 Feb '03

16 Feb '03

Hallo, guenter geiger hat gesagt: // guenter geiger wrote: > Proposal: > > What about moving these directories that can not be built as > single externals out ot "externals" and give them their own > subproject. This way, externals based on flext would be part of > flext, and built together with flext. ? I gave this a half day's worth of thought (and I think, we should move this topic over to pd-dev, which I'm doing now). Here are some of my results. *** flext itself needs a special treatment. *** It doesn't fall into any of the current categories. It isn't an external, it isn't a library of its own, but it is needed to compile a bunch of other externals (by Thomas and me and maybe more.) It is very tempting to compile flext-ernals together with flext, because of compiler issues, but they should get a package of their own, or be included in the pd-externals package. The alternative would be to build-depend on a installed pd-flext-package. This looks cleaner, but might make things very complicated in the end (i.e. one would need to take care of version-depends and so on). But somehow putting flext-ernals in the same package as flext just *feels* wrong. *** Other dependencies *** Having externals only rely on themselves makes things easy for packagers and compilers. But 85 % of my externals depend on other libraries, and in this case it makes sense, IMO (of course). For example (flext-)iiwu makes iiwusynth available to Pd, which is very useful and it would be a wasted effort to try to reimplement libiiwusynth just for a 257 lines long external. But then flext can depend on STK and SndObj, to make a lot of things easier for external developers. Libraries might not be available and need to be packed as well (as you did with SndObj). Because of this, I would vote for a pd-externals package like now including externals without dependencies. But what to do with the rest? Each package might need different libraries, some need flext, some fftw, ... I have no clear idea how to structure this, if we don't want to have packages with only one external inside. *** Single externals are easy to install, libs are not *** Libs require the user to add them to their pd-path. I'd prefer it, if a user will be made aware of this, maybe at installation or in the package README. So votes++ for a pd-extlibs package. These thoughts are a bit chaotic, but might be valid for a deeper discussion. ciao -- Frank Barknecht _ ______footils.org__

2 1

Extended debian/rules for pd-externals
by Frank Barknecht 16 Feb '03

16 Feb '03

Hallo, attached is an extended unofficial rules file to build externals from sourceforge. I use this, you don't need to, but you can, too. Changes compared to the rules file by Guenther include: * builds flext with SndObj and STK (the STK-path needs to be set by hand, as there isn't an STK for Debian, AFAIK) * builds the following and puts them into pd-externals: * grill/idelay * grill/xsample (as a library) * grill/fftease (as a library) * grill/pool (edit config-pd-linux and comment out CXX=g++ if you need g++-3.2 for now) * creb (as a library. abs/*.pd are installed to $PDDIR/extra/creb. You might want to comment remove abs.o from creb/modules/Makefile, as abs~ is also in other libraries, at least 2 times. creb is a candidate for Guenther's build/linux system, IMO, so my rules-solution is only temporary and will fade away soon.) * doesn't build my own externals yet. I'm an altruist. To use g++-3.2 and gcc-3.2 for compilation do a $ export CXX=g++-3.2 CPLUSPLUS=g++-3.2 CC=gcc-3.2 before you do $ fakeroot debian/rules binary Have fun. ciao -- Frank Barknecht _ ______footils.org__

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