Pd-dev July 2007

pd-dev@lists.iem.at

28 participants
109 discussions

[ pure-data-Patches-1763221 ] fix jack-related compile error on Ubuntu Gutsy (gcc-4.1.3)
by SourceForge.net 29 Jul '07

29 Jul '07

Patches item #1763221, was opened at 2007-07-29 15:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1763221&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: Stephen Sinclair (radarsat1) Assigned to: Nobody/Anonymous (nobody) Summary: fix jack-related compile error on Ubuntu Gutsy (gcc-4.1.3) Initial Comment: I was compiling PureData from scratch today and after automake/configure/make, I received this error: cc -g -O2 -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -DDL_OPEN -DPA_USE_OSS -DUNIX -DUNISTD -DUSEAPI_OSS -I../portaudio/pa_common -I../portaudio/pablio -I../portmidi/pm_common -I../portmidi/pm_linux -fno-strict-aliasing -DPA_USE_ALSA -DUSEAPI_ALSA -O6 -funroll-loops -fomit-frame-pointer -DUSEAPI_JACK -D_LARGEFILE64_SOURCE -DINSTALL_PREFIX=\"/home/ssteve/.local\" -c -o ../obj/s_audio_jack.o s_audio_jack.c s_audio_jack.c:197: error: ‘jack_error_callback’ redeclared as different kind of symbol /usr/include/jack/jack.h:776: error: previous declaration of ‘jack_error_callback’ was here make: *** [s_audio_jack.o] Error 1 The solution was to rename the jack_error_callback function, so I added an underscore. Maybe there is a better solution. I am using Ubuntu Gutsy (development version of Ubuntu), with gcc-4.1.3: $ gcc --version gcc (GCC) 4.1.3 20070718 (prerelease) (Ubuntu 4.1.2-14ubuntu1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1763221&group_…

1 0

[ pure-data-Bugs-1754855 ] pix_write producing some strange RGB values
by SourceForge.net 28 Jul '07

28 Jul '07

Bugs item #1754855, was opened at 2007-07-16 15:52 Message generated for change (Comment added) made by mr-bo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1754855&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: gem Group: v0.39.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mr-Bo (mr-bo) Assigned to: Nobody/Anonymous (nobody) Summary: pix_write producing some strange RGB values Initial Comment: Just to notify that pix_write is producing some strange RGB values, out of line with whats in the render window. This is on pd extended on OSX 10.4 ---------------------------------------------------------------------- >Comment By: Mr-Bo (mr-bo) Date: 2007-07-28 02:27 Message: Logged In: YES user_id=1846262 Originator: YES Im glad ther's an identification at least. Is this local to my hardware/pd-extended setup? If ther's a place to get a fix id gladly investigate. I could not manage to make sense or gain consistancy on the RGB outofballance... ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2007-07-27 21:05 Message: Logged In: YES user_id=663212 Originator: NO This turned out to be a very obscure bug having to do with pixel alignment. The change is actually in GemPixUtil.cpp. For the record OSX does automatic alignment to 128 bits and for blocks over a certain size it even page aligns on 4k boundaries. ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-27 13:38 Message: Logged In: YES user_id=1846262 Originator: YES File Added: Test2.jpg ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-27 13:37 Message: Logged In: YES user_id=1846262 Originator: YES Yes, this is related to PD extended - didnt know what tag to label it under. Let me know if I can label it correctly. With regards to the quicktime bug, well, the problem doesnt occur on a older GEM version (0.90 compiled Mar 06). Additionaly, the problem persists when outputing .jpg format. Beats me. The two files attached have background colour set to 1 0 0.3. Guess which is the odd one out...? File Added: Test1.jpg ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2007-07-23 16:38 Message: Logged In: YES user_id=663212 Originator: NO This appears to be a bug with the TIFF writing component in Quicktime. Try adding a 1 after the file name to select JPG image writing. Example message: 'file $1 1' ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2007-07-23 16:19 Message: Logged In: YES user_id=564396 Originator: NO could you please provide images (screenshots) on how it does look like and how it is supposed to look. (sorry for the added inconvenience). furthermore: is this related to pd-extended? (or rather: why does this issue have a 0.39.2 tag?) ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-17 23:16 Message: Logged In: YES user_id=1846262 Originator: YES Sorry, this is on the prehistoric PowerPC's. File Added: RGB-Grab.pd ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-17 14:51 Message: Logged In: YES user_id=1846262 Originator: YES Sorry, this is on the prehistoric PowerPC's. File Added: RGB-Grab.pd ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2007-07-17 14:35 Message: Logged In: YES user_id=663212 Originator: NO Intel or PowerPC? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-07-16 19:35 Message: Logged In: YES user_id=27104 Originator: NO An example patch is always very helpful, especially if it triggers the problem every time that it is run. Ideally the example patch would have only enough objects to cause the problem, but nothing else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1754855&group_…

1 0

[ pure-data-Bugs-1754855 ] pix_write producing some strange RGB values
by SourceForge.net 27 Jul '07

27 Jul '07

Bugs item #1754855, was opened at 2007-07-16 15:52 Message generated for change (Comment added) made by cclepper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1754855&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: gem Group: v0.39.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mr-Bo (mr-bo) Assigned to: Nobody/Anonymous (nobody) Summary: pix_write producing some strange RGB values Initial Comment: Just to notify that pix_write is producing some strange RGB values, out of line with whats in the render window. This is on pd extended on OSX 10.4 ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2007-07-27 21:05 Message: Logged In: YES user_id=663212 Originator: NO This turned out to be a very obscure bug having to do with pixel alignment. The change is actually in GemPixUtil.cpp. For the record OSX does automatic alignment to 128 bits and for blocks over a certain size it even page aligns on 4k boundaries. ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-27 13:38 Message: Logged In: YES user_id=1846262 Originator: YES File Added: Test2.jpg ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-27 13:37 Message: Logged In: YES user_id=1846262 Originator: YES Yes, this is related to PD extended - didnt know what tag to label it under. Let me know if I can label it correctly. With regards to the quicktime bug, well, the problem doesnt occur on a older GEM version (0.90 compiled Mar 06). Additionaly, the problem persists when outputing .jpg format. Beats me. The two files attached have background colour set to 1 0 0.3. Guess which is the odd one out...? File Added: Test1.jpg ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2007-07-23 16:38 Message: Logged In: YES user_id=663212 Originator: NO This appears to be a bug with the TIFF writing component in Quicktime. Try adding a 1 after the file name to select JPG image writing. Example message: 'file $1 1' ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2007-07-23 16:19 Message: Logged In: YES user_id=564396 Originator: NO could you please provide images (screenshots) on how it does look like and how it is supposed to look. (sorry for the added inconvenience). furthermore: is this related to pd-extended? (or rather: why does this issue have a 0.39.2 tag?) ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-17 23:16 Message: Logged In: YES user_id=1846262 Originator: YES Sorry, this is on the prehistoric PowerPC's. File Added: RGB-Grab.pd ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-17 14:51 Message: Logged In: YES user_id=1846262 Originator: YES Sorry, this is on the prehistoric PowerPC's. File Added: RGB-Grab.pd ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2007-07-17 14:35 Message: Logged In: YES user_id=663212 Originator: NO Intel or PowerPC? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-07-16 19:35 Message: Logged In: YES user_id=27104 Originator: NO An example patch is always very helpful, especially if it triggers the problem every time that it is run. Ideally the example patch would have only enough objects to cause the problem, but nothing else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1754855&group_…

1 0

[ pure-data-Bugs-1754855 ] pix_write producing some strange RGB values
by SourceForge.net 27 Jul '07

27 Jul '07

Bugs item #1754855, was opened at 2007-07-16 15:52 Message generated for change (Comment added) made by mr-bo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1754855&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: gem Group: v0.39.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mr-Bo (mr-bo) Assigned to: Nobody/Anonymous (nobody) Summary: pix_write producing some strange RGB values Initial Comment: Just to notify that pix_write is producing some strange RGB values, out of line with whats in the render window. This is on pd extended on OSX 10.4 ---------------------------------------------------------------------- >Comment By: Mr-Bo (mr-bo) Date: 2007-07-27 13:38 Message: Logged In: YES user_id=1846262 Originator: YES File Added: Test2.jpg ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-27 13:37 Message: Logged In: YES user_id=1846262 Originator: YES Yes, this is related to PD extended - didnt know what tag to label it under. Let me know if I can label it correctly. With regards to the quicktime bug, well, the problem doesnt occur on a older GEM version (0.90 compiled Mar 06). Additionaly, the problem persists when outputing .jpg format. Beats me. The two files attached have background colour set to 1 0 0.3. Guess which is the odd one out...? File Added: Test1.jpg ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2007-07-23 16:38 Message: Logged In: YES user_id=663212 Originator: NO This appears to be a bug with the TIFF writing component in Quicktime. Try adding a 1 after the file name to select JPG image writing. Example message: 'file $1 1' ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2007-07-23 16:19 Message: Logged In: YES user_id=564396 Originator: NO could you please provide images (screenshots) on how it does look like and how it is supposed to look. (sorry for the added inconvenience). furthermore: is this related to pd-extended? (or rather: why does this issue have a 0.39.2 tag?) ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-17 23:16 Message: Logged In: YES user_id=1846262 Originator: YES Sorry, this is on the prehistoric PowerPC's. File Added: RGB-Grab.pd ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-17 14:51 Message: Logged In: YES user_id=1846262 Originator: YES Sorry, this is on the prehistoric PowerPC's. File Added: RGB-Grab.pd ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2007-07-17 14:35 Message: Logged In: YES user_id=663212 Originator: NO Intel or PowerPC? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-07-16 19:35 Message: Logged In: YES user_id=27104 Originator: NO An example patch is always very helpful, especially if it triggers the problem every time that it is run. Ideally the example patch would have only enough objects to cause the problem, but nothing else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1754855&group_…

1 0

[ pure-data-Bugs-1754855 ] pix_write producing some strange RGB values
by SourceForge.net 27 Jul '07

27 Jul '07

Bugs item #1754855, was opened at 2007-07-16 15:52 Message generated for change (Comment added) made by mr-bo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1754855&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: gem Group: v0.39.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mr-Bo (mr-bo) Assigned to: Nobody/Anonymous (nobody) Summary: pix_write producing some strange RGB values Initial Comment: Just to notify that pix_write is producing some strange RGB values, out of line with whats in the render window. This is on pd extended on OSX 10.4 ---------------------------------------------------------------------- >Comment By: Mr-Bo (mr-bo) Date: 2007-07-27 13:37 Message: Logged In: YES user_id=1846262 Originator: YES Yes, this is related to PD extended - didnt know what tag to label it under. Let me know if I can label it correctly. With regards to the quicktime bug, well, the problem doesnt occur on a older GEM version (0.90 compiled Mar 06). Additionaly, the problem persists when outputing .jpg format. Beats me. The two files attached have background colour set to 1 0 0.3. Guess which is the odd one out...? File Added: Test1.jpg ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2007-07-23 16:38 Message: Logged In: YES user_id=663212 Originator: NO This appears to be a bug with the TIFF writing component in Quicktime. Try adding a 1 after the file name to select JPG image writing. Example message: 'file $1 1' ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2007-07-23 16:19 Message: Logged In: YES user_id=564396 Originator: NO could you please provide images (screenshots) on how it does look like and how it is supposed to look. (sorry for the added inconvenience). furthermore: is this related to pd-extended? (or rather: why does this issue have a 0.39.2 tag?) ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-17 23:16 Message: Logged In: YES user_id=1846262 Originator: YES Sorry, this is on the prehistoric PowerPC's. File Added: RGB-Grab.pd ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-17 14:51 Message: Logged In: YES user_id=1846262 Originator: YES Sorry, this is on the prehistoric PowerPC's. File Added: RGB-Grab.pd ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2007-07-17 14:35 Message: Logged In: YES user_id=663212 Originator: NO Intel or PowerPC? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-07-16 19:35 Message: Logged In: YES user_id=27104 Originator: NO An example patch is always very helpful, especially if it triggers the problem every time that it is run. Ideally the example patch would have only enough objects to cause the problem, but nothing else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1754855&group_…

1 0

libmpeg3 v1.5 vs. v.1.7
by Hans-Christoph Steiner 26 Jul '07

26 Jul '07

So I just upgraded the Fedora Core 4 server to Fedora Core 6 with PlanetCCRMA. This version now uses libmpeg3 v1.7. Apparently, some functions have changed: /usr/include/libmpeg3.h: In member function 'virtual bool filmMPEG3::open(char*, int)': /usr/include/libmpeg3.h:48: error: too few arguments to function 'mpeg3_t* mpeg3_open(char*, int*)' filmMPEG3.cpp:64: error: at this point in file AFAIK, the rest of the GNU/Linux boxes in the auto-build farm are using v.1.5.4 .hc > 12. autobuild: pd-extended planetccrma6-i386 2007-07-26 04.33.32 > (pd(a)planetccrma6-i386.idmi.poly.edu) > > > ------------------------------ > > Message: 12 > Date: Thu, 26 Jul 2007 04:45:21 -0400 > From: pd(a)planetccrma6-i386.idmi.poly.edu > Subject: [PD-cvs] autobuild: pd-extended planetccrma6-i386 2007-07-26 > 04.33.32 > To: pd-cvs(a)iem.at > Message-ID: > <200707260845.l6Q8jLjP021143(a)planetccrma6-i386.idmi.poly.edu> > > g++ -c -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 - > falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math - > mmmx -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/ > include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/ > freetype2 -I/home/pd/auto-build/pd-extended/pd/src filmFFMPEG.cpp - > o filmFFMPEG.o > g++ -c -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 - > falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math - > mmmx -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/ > include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/ > freetype2 -I/home/pd/auto-build/pd-extended/pd/src filmMPEG1.cpp - > o filmMPEG1.o > g++ -c -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 - > falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math - > mmmx -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/ > include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/ > freetype2 -I/home/pd/auto-build/pd-extended/pd/src filmMPEG3.cpp - > o filmMPEG3.o > g++ -c -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 - > falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math - > mmmx -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/ > include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/ > freetype2 -I/home/pd/auto-build/pd-extended/pd/src filmQT.cpp -o > filmQT.o > g++ -c -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 - > falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math - > mmmx -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/ > include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/ > freetype2 -I/home/pd/auto-build/pd-extended/pd/src filmQT4L.cpp -o > filmQT4L.o > g++ -c -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 - > falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math - > mmmx -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/ > include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/ > freetype2 -I/home/pd/auto-build/pd-extended/pd/src > libfidtrack_fidtrackX.cpp -o libfidtrack_fidtrackX.o > /usr/include/libmpeg3.h: In member function 'virtual bool > filmMPEG3::open(char*, int)': > /usr/include/libmpeg3.h:48: error: too few arguments to function > 'mpeg3_t* mpeg3_open(char*, int*)' > filmMPEG3.cpp:64: error: at this point in file > make[3]: *** [filmMPEG3.o] Error 1 > make[3]: *** Waiting for unfinished jobs.... > make[3]: Leaving directory `/home/pd/auto-build/pd-extended/Gem/src/ > Pixes' > make[2]: *** [Pixes] Error 2 > make[2]: Leaving directory `/home/pd/auto-build/pd-extended/Gem/src' > make[1]: *** [/home/pd/auto-build/pd-extended/Gem/src/Gem.pd_linux] > Error 2 > make[1]: Leaving directory `/home/pd/auto-build/pd-extended/packages' > make: *** [install] Error 2 > upload specs linux_make build tar.bz2 > Uploading /home/pd/auto-build/pd-extended/packages/linux_make/build/ > Pd*.tar.bz2 > ls: /home/pd/auto-build/pd-extended/packages/linux_make/build/ > Pd*.tar.bz2: No such file or directory > > > > ------------------------------ > > Message: 13 > Date: Thu, 26 Jul 2007 04:57:05 -0400 > From: pd(a)planetccrma6-i386.idmi.poly.edu > Subject: [PD-cvs] autobuild: pd-extended-release planetccrma6-i386 > 2007-07-26 04.33.32 > To: pd-cvs(a)iem.at > Message-ID: > <200707260857.l6Q8v5HM000581(a)planetccrma6-i386.idmi.poly.edu> > > g++ -c -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 - > falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math - > mmmx -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/ > include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/ > freetype2 -I/home/pd/auto-build/pd-extended-release/pd/src > filmFFMPEG.cpp -o filmFFMPEG.o > g++ -c -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 - > falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math - > mmmx -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/ > include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/ > freetype2 -I/home/pd/auto-build/pd-extended-release/pd/src > filmMPEG1.cpp -o filmMPEG1.o > g++ -c -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 - > falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math - > mmmx -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/ > include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/ > freetype2 -I/home/pd/auto-build/pd-extended-release/pd/src > filmMPEG3.cpp -o filmMPEG3.o > g++ -c -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 - > falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math - > mmmx -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/ > include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/ > freetype2 -I/home/pd/auto-build/pd-extended-release/pd/src > filmQT.cpp -o filmQT.o > g++ -c -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 - > falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math - > mmmx -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/ > include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/ > freetype2 -I/home/pd/auto-build/pd-extended-release/pd/src > filmQT4L.cpp -o filmQT4L.o > g++ -c -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 - > falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math - > mmmx -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/ > include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/ > freetype2 -I/home/pd/auto-build/pd-extended-release/pd/src > libfidtrack_fidtrackX.cpp -o libfidtrack_fidtrackX.o > /usr/include/libmpeg3.h: In member function 'virtual bool > filmMPEG3::open(char*, int)': > /usr/include/libmpeg3.h:48: error: too few arguments to function > 'mpeg3_t* mpeg3_open(char*, int*)' > filmMPEG3.cpp:64: error: at this point in file > make[3]: *** [filmMPEG3.o] Error 1 > make[3]: *** Waiting for unfinished jobs.... > make[3]: Leaving directory `/home/pd/auto-build/pd-extended-release/ > Gem/src/Pixes' > make[2]: *** [Pixes] Error 2 > make[2]: Leaving directory `/home/pd/auto-build/pd-extended-release/ > Gem/src' > make[1]: *** [/home/pd/auto-build/pd-extended-release/Gem/src/ > Gem.pd_linux] Error 2 > make[1]: Leaving directory `/home/pd/auto-build/pd-extended-release/ > packages' > make: *** [install] Error 2 > upload specs linux_make build tar.bz2 > Uploading /home/pd/auto-build/pd-extended-release/packages/ > linux_make/build/Pd*.tar.bz2 > ls: /home/pd/auto-build/pd-extended-release/packages/linux_make/ > build/Pd*.tar.bz2: No such file or directory > ------------------------------------------------------------------------ ---- Mistrust authority - promote decentralization. - the hacker ethic

1 0

emacs style for pd code
by Hans-Christoph Steiner 26 Jul '07

26 Jul '07

I just made a quick pd-style for emacs which includes the Pd code indent format. It would be code to flush this out so that we are all on the same page: (defconst pd-style '( (tab-width . 8) (c-basic-offset . 4) (setq indent-tabs-mode t) ) "Miller's indent style") (c-add-style "pd" pd-style) The OpenOffice project has a good example of a well defined code format: http://wiki.services.openoffice.org/wiki/Editor_Emacs .hc zen \ \ \[D[D[D[D

1 0

please add 'mokhov' to pure-data at SF.net
by Serguei A. Mokhov 26 Jul '07

26 Jul '07

Hi, I will soon be completing my PD external(s) for the upcoming PDCon07. I would like to able to commit them to the PD repo once I am ready. For this, could you please add SF.net 'mokhov' to the project. Thanks! -- Serguei A. Mokhov | /~\ The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | X Against HTML Montreal, Quebec, Canada | / \ Email!

5 6

Re: [PD-dev] help-array crashing outlet_anything
by nosehair911＠bellsouth.net 26 Jul '07

26 Jul '07

SOLVED.(somewhat) Instead of using the addToArray function I just used something like this: Intstore *storepointer; In my function I used this: storepointer = new Intstore[anumber]; for (i=0; i<anumber; i++) { storepointer[i].m_xmax = (whatever int); storepointer[i].m_ymax = (whatever int); } So to send it out an outlet I do this: t_atom*ap = new t_atom[2+anumber*2]; for(bn=0; bn<anumber; bn++){ SETFLOAT(ap+bn*2, x->storepointer[bn].xmax()); SETFLOAT(ap+bn*2+1, x->storepointer[bn].ymax()); } outlet_anything(x->outlet1, 2+anumber*2, ap); ...and it works now. Simple and without too much hassle. I still dont understand why it worked before but only with quicktime movies! Makes no cense at all? Alain > From: <nosehair911(a)bellsouth.net> > Date: 2007/07/25 Wed PM 08:08:35 EDT > To: <pd-dev(a)iem.at> > Subject: Re: [PD-dev] help-array crashing outlet_anything > > Ok I tried with a static array like "Class array[amount] " and it did not crash, it worked perfect. Now I > have to figure out what I am doing to cause a crash (with heavy cpu load I persume, still a bit > confused?) using a dynamic array? It would be nice to have a dynamic array so as not to eat up so > much ram. > Alain > > > > From: <nosehair911(a)bellsouth.net> > > Date: 2007/07/25 Wed PM 03:35:33 EDT > > To: "chris clepper" <cgclepper(a)gmail.com> > > CC: pd-dev(a)iem.at > > Subject: Re: [PD-dev] help-array crashing outlet_anything > > > > It doesn't thats whats confusing me. Pixel data is the same on both exept it takes more cpu to > > process. I think it has to do with cpu load but I am not sure. I think I am going to just try a simple > > "Class array[amount] " intead of "Class *pointer = new Class[amount]" see if that would be easier on > > the cpu or the coding gods. > > > > Alain > > > > > > > > From: "chris clepper" <cgclepper(a)gmail.com> > > > Date: 2007/07/25 Wed PM 01:04:52 EDT > > > To: "nosehair911(a)bellsouth.net" <nosehair911(a)bellsouth.net> > > > CC: pd-dev(a)iem.at > > > Subject: Re: [PD-dev] help-array crashing outlet_anything > > > > > > On 7/25/07, nosehair911(a)bellsouth.net <nosehair911(a)bellsouth.net> wrote: > > > > > > > > > > > > BTW its a blobtracking external. It is working perfect tracking quicktime > > > > movies but the camera > > > > tracking only works if I exclude the addToArray function. This really has > > > > me scratching my head! > > > > > > > > > Why would your processing code know or even care if the input is from a > > > camera or a file? Both should be pixel arrays with no differences in their > > > format. > > > > > > > > > > > > _______________________________________________ > > PD-dev mailing list > > PD-dev(a)iem.at > > http://lists.puredata.info/listinfo/pd-dev > > > > > _______________________________________________ > PD-dev mailing list > PD-dev(a)iem.at > http://lists.puredata.info/listinfo/pd-dev >

1 0

Re: [PD-dev] help-array crashing outlet_anything
by nosehair911＠bellsouth.net 26 Jul '07

26 Jul '07

Ok I tried with a static array like "Class array[amount] " and it did not crash, it worked perfect. Now I have to figure out what I am doing to cause a crash (with heavy cpu load I persume, still a bit confused?) using a dynamic array? It would be nice to have a dynamic array so as not to eat up so much ram. Alain > > From: <nosehair911(a)bellsouth.net> > Date: 2007/07/25 Wed PM 03:35:33 EDT > To: "chris clepper" <cgclepper(a)gmail.com> > CC: pd-dev(a)iem.at > Subject: Re: [PD-dev] help-array crashing outlet_anything > > It doesn't thats whats confusing me. Pixel data is the same on both exept it takes more cpu to > process. I think it has to do with cpu load but I am not sure. I think I am going to just try a simple > "Class array[amount] " intead of "Class *pointer = new Class[amount]" see if that would be easier on > the cpu or the coding gods. > > Alain > > > > > From: "chris clepper" <cgclepper(a)gmail.com> > > Date: 2007/07/25 Wed PM 01:04:52 EDT > > To: "nosehair911(a)bellsouth.net" <nosehair911(a)bellsouth.net> > > CC: pd-dev(a)iem.at > > Subject: Re: [PD-dev] help-array crashing outlet_anything > > > > On 7/25/07, nosehair911(a)bellsouth.net <nosehair911(a)bellsouth.net> wrote: > > > > > > > > > BTW its a blobtracking external. It is working perfect tracking quicktime > > > movies but the camera > > > tracking only works if I exclude the addToArray function. This really has > > > me scratching my head! > > > > > > Why would your processing code know or even care if the input is from a > > camera or a file? Both should be pixel arrays with no differences in their > > format. > > > > > > > _______________________________________________ > PD-dev mailing list > PD-dev(a)iem.at > http://lists.puredata.info/listinfo/pd-dev >

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 July 2007