Pd-dev January 2008

pd-dev@lists.iem.at

27 participants
93 discussions

[ pure-data-Patches-1842162 ] Fix typo in trigger-help.pd
by SourceForge.net 14 Jan '08

14 Jan '08

Patches item #1842162, was opened at 2007-11-30 21:16 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1842162&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: Russell Bryant (russellbryant) Assigned to: Miller Puckette (millerpuckette) Summary: Fix typo in trigger-help.pd Initial Comment: Here is a silly tiny patch. In the trigger-help.pd file, there is the object: [trigger float bang symbol list anything] Later, it says that it can be simplified to: [t f b l s a] This patch fixes the typo in the simplified version by changing it to: [t f b s l a] ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2008-01-14 10:42 Message: Logged In: YES user_id=313747 Originator: NO taken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1842162&group_…

1 0

[ pure-data-Patches-1862168 ] [bugfix] makefilename ignores "%c"
by SourceForge.net 14 Jan '08

14 Jan '08

Patches item #1862168, was opened at 2008-01-02 05:22 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1862168&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: 6 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: [bugfix] makefilename ignores "%c" Initial Comment: the bugfix-#1688540 introduced argument-checking in [makefilename]. unfortunately, the author forgot about the "%c", which is currently the only way to get "weird" characters (like space,...). this breaks quite some patches which depend on that workaround. since there is still no "clean" way to produce symbols with special characters, i'd suggest to include "%c" into the formatting in [makefilename]. attached is a fix, that adds "%c" to the types that request an integer. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2008-01-14 10:40 Message: Logged In: YES user_id=313747 Originator: NO taken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1862168&group_…

1 0

[ pure-data-Patches-1867738 ] [FIX] gensym() should use "const char*"
by SourceForge.net 14 Jan '08

14 Jan '08

Patches item #1867738, was opened at 2008-01-09 07:25 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1867738&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: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: [FIX] gensym() should use "const char*" Initial Comment: gensym is currently defined as "t_symbol *gensym(char *s);" this leads to numerous warnings when compiling C++-externals, since C++ treats literals (strings) as "const char*". e.g. gensym("hello"); yields and a warning "warning: deprecated conversion from string constant to 'char*'" the fix for this is simple and makes total sense, since gensym() does not need to modify the passed string. just use: t_symbol *gensym(const char *s); the attached patch does this (it additionally applies the same to the dogensym() function in m_class.c ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2008-01-14 10:38 Message: Logged In: YES user_id=313747 Originator: NO taken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1867738&group_…

1 0

[ pure-data-Patches-1862148 ] [bugfix] setitimer invalid timeval
by SourceForge.net 14 Jan '08

14 Jan '08

Patches item #1862148, was opened at 2008-01-02 04:41 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1862148&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: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: [bugfix] setitimer invalid timeval Initial Comment: as described by claude in bug#1841758 (https://sourceforge.net/tracker/index.php?func=detail&aid=1841758&group_id=…) there is a small bug in the use of setitimer() in sys_setalarm(). the problem is, that the setitimer() API has changed in order to be POSIX-conformant and Pd has not yet adapated to this change. the attached patch fixes the problem, by splitting the given "microsec" value into seconds and microseconds. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2008-01-14 10:37 Message: Logged In: YES user_id=313747 Originator: NO taken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1862148&group_…

1 0

[ pure-data-Patches-1852385 ] Improve strtokcpy() efficiency, prevent stack overflow
by SourceForge.net 14 Jan '08

14 Jan '08

Patches item #1852385, was opened at 2007-12-17 07:07 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1852385&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: Russell Bryant (russellbryant) Assigned to: Miller Puckette (millerpuckette) Summary: Improve strtokcpy() efficiency, prevent stack overflow Initial Comment: This patch provides a revised implementation of the strtokcpy() function in s_path.c. It provides the following benefits: 1) Prevent potential overflow of a stack buffer. This function did nothing to ensure that it didn't write past the end of the destination buffer. It is possible to cause this to happen by providing certain command line arguments that are longer than MAXPDSTRING. Also, there may be other ways to trigger this bug if namelist_append_files() is used anywhere beyond the uses I reviewed, which are the ones in pd/*.c. 2) Copy bytes from the string in the same loop that looks for the delimiter. This is simply for efficiency in that the string only has to be traversed once, instead of twice (one to find the delimiter, and the second to copy up to it). 3) Document the function using doxygen style tags. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2008-01-14 10:37 Message: Logged In: YES user_id=313747 Originator: NO taken. ---------------------------------------------------------------------- Comment By: Russell Bryant (russellbryant) Date: 2008-01-06 06:39 Message: Logged In: YES user_id=1942915 Originator: YES Checked in to branch-v0-40-extended ---------------------------------------------------------------------- Comment By: Russell Bryant (russellbryant) Date: 2007-12-17 07:07 Message: Logged In: YES user_id=1942915 Originator: YES File Added: strokcpy.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1852385&group_…

1 0

[ pure-data-Bugs-1841758 ] setitimer invalid timeval
by SourceForge.net 14 Jan '08

14 Jan '08

Bugs item #1841758, was opened at 2007-11-30 06:49 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1841758&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: Fixed Priority: 5 Private: No Submitted By: ClaudiusMaximus (claudiusmaximus) Assigned to: Nobody/Anonymous (nobody) Summary: setitimer invalid timeval Initial Comment: Pd's scheduler seems to have a bug regarding setitimer, which leads to messages in the system log: setitimer: pd (pid = 3401) provided invalid timeval it_value: tv_sec = 0 tv_usec = 1000000 (with a clock delaytime of 1000ms) man setitimer says: ----8<---- POSIX.1-2001 says that setitimer() should fail if a tv_usec value is specified that is outside of the range 0 to 999999. However, Linux does not give an error, but instead silently adjusts the corresponding seconds value for the timer. In the future (scheduled for March 2007), this non-conformance will be repaired: existing applications should be fixed now to ensure that they supply a properly formed tv_usec value. ----8<---- This is with pd-0.40-3 from Miller's site, on GNU/Linux Debian Etch, but I've noticed this issue on various other Linux distros. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2008-01-14 10:30 Message: Logged In: YES user_id=313747 Originator: NO taken ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2008-01-02 04:43 Message: Logged In: YES user_id=564396 Originator: NO i have submitted a fix for this as patch#1862148 https://sourceforge.net/tracker/index.php?func=detail&aid=1862148&group_id=… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1841758&group_…

1 0

Patch for using midiout with ALSA.
by Jonathan BISSON 14 Jan '08

14 Jan '08

I've tried those mods, and now I can send sysex through midiout under ALSA: diff pd-0.40-3/src/m_pd.h pd-0.40-3_mod/src/m_pd.h 464a465 > EXTERN int sys_midiapi; diff pd-0.40-3/src/x_midi.c pd-0.40-3_mod/src/x_midi.c 7a8 > #include "s_stuff.h" 657a659,661 > #ifdef USEAPI_ALSA > void sys_alsa_putmidibyte(int portno, int byte); > #endif 660a665 > 681c686,695 < sys_putmidibyte(x->x_portno - 1, f); --- > #ifdef USEAPI_ALSA > if (sys_midiapi == API_ALSA) // sys_midiapi is not defined in x_mini... > { > sys_alsa_putmidibyte(x->x_portno - 1, f); > } > else > #endif > { > sys_putmidibyte(x->x_portno -1 ,f); > } Please be tolerant, it's my first patch for pd (and my first reading of pd code...). I don't know why Miller didn't used the sys_alsa_putmidibyte... Maybe are you trying to clarify the midi API... But I needed sysexs :)

1 0

Re: [PD-dev] User Name troubles
by Hans-Christoph Steiner 10 Jan '08

10 Jan '08

Ok, I swapped out mjmogo for mjmcgonagle and cc'ed pd-dev to keep people posted. .hc On Jan 4, 2008, at 1:11 PM, Mike McGonagle wrote: > Hans, > > I guess I gave you an old account from SourceForge, it seems to > have an old email address that I no longer have, nor do I remember > the password. > > HTTP://sourceforge.net/users/mjmcgonagle/ > > This is the correct name... > > mjmcgonagle > > > Sorry for the confusion. > > > Mike > > > -- > Peace may sound simple—one beautiful word— but it requires > everything we have, every quality, every strength, every dream, > every high ideal. > —Yehudi Menuhin (1916–1999), musician ------------------------------------------------------------------------ ---- If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson

1 0

[ pure-data-Bugs-1754855 ] pix_write producing some strange RGB values
by SourceForge.net 10 Jan '08

10 Jan '08

Bugs item #1754855, was opened at 2007-07-16 17:52 Message generated for change (Comment added) made by zmoelnig 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: externals Group: v0.39.2 >Status: Closed >Resolution: Fixed 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: IOhannes m zmölnig (zmoelnig) Date: 2008-01-10 10:33 Message: Logged In: YES user_id=564396 Originator: NO i just checked that there has indeed been a fix for this committed some months ago. happy to close this bug-report. ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-28 04: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 23: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 15:38 Message: Logged In: YES user_id=1846262 Originator: YES File Added: Test2.jpg ---------------------------------------------------------------------- Comment By: Mr-Bo (mr-bo) Date: 2007-07-27 15: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 18: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 18: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-18 01: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 16: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 16:35 Message: Logged In: YES user_id=663212 Originator: NO Intel or PowerPC? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-07-16 21: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-1846915 ] gem decoding ffodivx cpu usage
by SourceForge.net 10 Jan '08

10 Jan '08

Bugs item #1846915, was opened at 2007-12-08 17:37 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1846915&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: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: wipinmtl (wipinmtl) Assigned to: Nobody/Anonymous (nobody) Summary: gem decoding ffodivx cpu usage Initial Comment: XVID is not fully working with gem. using any video player it will work fine (under 7% of my cpu for a 640x480 29.97 fps - mplayer, ffplay, vlc). in gem the cpu usage is over 77% and the video is very slow. i tried to encode with transcode, mencoder and ffmpeg, same result. Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4) you can test with 2 differents XVID encoding: http://www.workinprogress.ca/pd/gem/xvid.avi http://www.workinprogress.ca/pd/gem/xvidmencoder.avi ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2007-12-12 09:30 Message: Logged In: YES user_id=564396 Originator: NO this is a duplication of http://sourceforge.net/tracker/index.php?func=detail&aid=1849190&group_id=6… (or rather the other way round; anyhow i moved this bug to pd-gem's own tracker) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1846915&group_…

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 January 2008