Pd-dev July 2005

pd-dev@lists.iem.at

26 participants
85 discussions

Re: [PD-dev] scons and devel 39..may be OT
by Georg Holzmann 16 Jul '05

16 Jul '05

Hallo! > - rewrite the patch using a professional software of your choice (it > would surprise me if supercollider isn't able to load soundfiles on the > fly) Yes, but also supercollider has disadvantages (as you might know) ... but anyhow, I don't want a supercollider vs. pd discussion now :) > - try pyext and numarrays > - rewrite the threaded soundfiler :-) what about a threaded soundfiler with flext (dont know if this would work) ? then only thomas has the work to adpat it for the new pd releases ... :) LG Georg -- GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

3 2

Re: [PD-dev] scons and devel 39..may be OT
by Georg Holzmann 16 Jul '05

16 Jul '05

Hallo! >>So, there is no SConscript in extra/ (should there be one?) and > oops ... now there is ;-) okay - thanks ... It compiles, but e.g. bonk etc. is missing: ... scons: *** Source `extra/bonk~/bonk~.c' not found, needed by target `extr/bonk~.os'. Stop. scons: building terminated because of errors. ... Also the manual, docs, ... are still missing (I know, you just started to work on 0_39) > well, i think this was a clash when using both the fftw and the threaded > soundfiler ... i probably won't rewrite the threaded soundfiler for 0.39 > ... i rewrote it for 0.38 and would probably have to rewrite it for > 0.40-1.00 ... and since there will be an array external working for > xsample, vasp, py, that _will_ be threaded, why will pd need features hm, I can understand you ... anyhow, I need it for a specific patch, so should I stay with devel_0_38 or are there any other workarounds in the meantime (besides upsampling and readsf~ ...) ? LG Georg PS: Is it a problem for you if I check in all the missing files (when I need them) ? -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse f�r Mail, Message, More +++

2 1

Re: [PD-dev] scons and devel 39..may be OT
by Georg Holzmann 16 Jul '05

16 Jul '05

Hallo Tim! Some other problems with scons: I just checked out the devel_0_39 and: <snip> Checking for C header file tk.h... no Checking for C header file tk/tk.h... no Checking for C header file tk8.0/tk.h... no Checking for C header file tk8.1/tk.h... no Checking for C header file tk8.2/tk.h... no Checking for C header file tk8.3/tk.h... no Checking for C header file tk8.4/tk.h... no Checking for C header file tk8.5/tk.h... no Checking for C header file tk8.6/tk.h... no Checking for C header file tk8.7/tk.h... no Checking for C header file tk8.8/tk.h... no Checking for C header file tk8.9/tk.h... no Checking for C header file tcl8.0/tk.h... no Checking for C header file tcl8.1/tk.h... no Checking for C header file tcl8.2/tk.h... no Checking for C header file tcl8.3/tk.h... no Checking for C header file tcl8.4/tk.h... no Checking for C header file tcl8.5/tk.h... no Checking for C header file tcl8.6/tk.h... no Checking for C header file tcl8.7/tk.h... no Checking for C header file tcl8.8/tk.h... no Checking for C header file tcl8.9/tk.h... no can't find tk header Checking for pthread_create() in C library pthread... yes Checking for main() in C library fftw3f... no Checking for dlopen() in C library dl... yes Checking for jack_activate() in C library jack... yes Checking for snd_pcm_info() in C library asound... yes scons: warning: Ignoring missing SConscript 'extra/SConscript' File "SConstruct", line 32, in ? TypeError: iteration over non-sequence: File "SConstruct", line 48: for extra in extras: </snip> So, there is no SConscript in extra/ (should there be one?) and unfortunately it doesn't find the tk headers again ... :( Thanks, LG Georg -- GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

2 1

[ pure-data-Patches-1214164 ] route bug with zero-length lists ("bang") in float-mode
by SourceForge.net 16 Jul '05

16 Jul '05

Patches item #1214164, was opened at 2005-06-03 12:48 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1214164&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: Closed >Resolution: Accepted Priority: 5 Submitted By: IOhannes m zmÃ¶lnig (zmoelnig) Assigned to: Nobody/Anonymous (nobody) Summary: route bug with zero-length lists ("bang") in float-mode Initial Comment: when sending a "bang" message [route] in float-mode (e.g. [route 1 2]), the bang will silently vanish. i think this is due to the fact, that now "bang"s are equal to zero-length-lists which are discarded by the route_list-method in float-mode. anyhow, the attached patch (against pd-0.38-4) will send the "bang" to the reject-outlet ---------------------------------------------------------------------- >Comment By: IOhannes m zmÃ¶lnig (zmoelnig) Date: 2005-07-16 15:38 Message: Logged In: YES user_id=564396 accepted into pd>=0.39 ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2005-07-16 03:17 Message: Logged In: YES user_id=313747 Sounds right... so I took it... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1214164&group_…

1 0

[ pure-data-Patches-1214166 ] complaining about [route] with mixed-type arguments
by SourceForge.net 16 Jul '05

16 Jul '05

Patches item #1214166, was opened at 2005-06-03 12:51 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1214166&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: Closed >Resolution: Fixed Priority: 5 Submitted By: IOhannes m zmÃ¶lnig (zmoelnig) Assigned to: Nobody/Anonymous (nobody) Summary: complaining about [route] with mixed-type arguments Initial Comment: quoting the reference-patch of [route]: "Route checks the first element of a message against each of its arguments, which may be numbers or symbols (but not a mixture of the two.)" however, creating [route 5 bla] is possible and no hints are given that this is illegal. attached is a patch that checks the creation arguments, and if they are illegal, no object will be created (with some verbosity, so the user knows what went wrong) ---------------------------------------------------------------------- >Comment By: IOhannes m zmÃ¶lnig (zmoelnig) Date: 2005-07-16 15:28 Message: Logged In: YES user_id=564396 fixed with pd>=0.39 ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2005-07-16 03:02 Message: Logged In: YES user_id=313747 OK... I fixed it slightly differently though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1214166&group_…

1 0

[ pure-data-Patches-1224730 ] pdsend bug with long(>127) sendbuffers
by SourceForge.net 16 Jul '05

16 Jul '05

Patches item #1224730, was opened at 2005-06-21 11:04 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1224730&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: Closed >Resolution: Accepted Priority: 5 Submitted By: IOhannes m zmÃ¶lnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: pdsend bug with long(>127) sendbuffers Initial Comment: in pdsend the length of the buffer is limited to 4096 chars. however, in the send-routine, the buffer-length is evaluated into a variable of type "char"; this prohibits the sending of buffers where (char)strlen(buf)<0 (easy to reach, when working with buffers longer than 127 chars) this behaviour appears in all versions of pd<=0.38-4 (i guess) attached is a patch that uses "unsigned int" for the length instead of "char" NOTE: i guess the correct type should rather be "size_t" NOTE: i think pdsend/netsend (and pdreceive/netreceive) should really use the same code rather than 2 separate copies. ---------------------------------------------------------------------- >Comment By: IOhannes m zmÃ¶lnig (zmoelnig) Date: 2005-07-16 15:24 Message: Logged In: YES user_id=564396 fixed with pd>=0.39 ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2005-07-16 02:22 Message: Logged In: YES user_id=313747 Wow, that was stupid of me. Thanks for catching it. To appear next CVS commit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1224730&group_…

1 0

[ pure-data-Patches-1228872 ] fix verbosity of iemgui's when changing send/receive-names
by SourceForge.net 16 Jul '05

16 Jul '05

Patches item #1228872, was opened at 2005-06-28 11:12 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1228872&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: Closed >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Miller Puckette (millerpuckette) Summary: fix verbosity of iemgui's when changing send/receive-names Initial Comment: you can set the send/receive-names of the iemgui_s with messages. however, somebody has added some debugging output into the code that does change the send-name, resulting in following output to the console: "send: before [newname], after [newname]" while this does not affect the functionality, it fills the console with messages that do not provide any realy functionality. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2005-07-16 02:28 Message: Logged In: YES user_id=313747 That was my fault. Fixed now. -msp ---------------------------------------------------------------------- Comment By: IOhannes m zmÃ¶lnig (zmoelnig) Date: 2005-06-28 11:14 Message: Logged In: YES user_id=564396 assigned to msp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1228872&group_…

1 0

[ pure-data-Patches-1230498 ] crash on saving changed iem-guis in subpatchers
by SourceForge.net 16 Jul '05

16 Jul '05

Patches item #1230498, was opened at 2005-06-30 19:50 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1230498&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: Closed >Resolution: Accepted Priority: 5 Submitted By: IOhannes m zmÃ¶lnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: crash on saving changed iem-guis in subpatchers Initial Comment: as described by t.grill, the "numberbox2" (from the iemguis) crashes pd, when an abstraction is saved, where there is an active nbx2 in a closed subpatch. attached is a patch against 0.38-4 that resolves this issue. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2005-07-16 02:26 Message: Logged In: YES user_id=313747 applied (should already be in CVS main) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1230498&group_…

1 0

[ pure-data-Patches-1224768 ] checks for NULL-pointers in g_rtext.c & g_graph.c
by SourceForge.net 16 Jul '05

16 Jul '05

Patches item #1224768, was opened at 2005-06-21 11:57 Message generated for change (Comment added) made by timblech You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1224768&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-dev Group: bugfix Status: Open Resolution: None Priority: 5 Submitted By: IOhannes m zmÃ¶lnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: checks for NULL-pointers in g_rtext.c & g_graph.c Initial Comment: most funtions in g_rtext.c do not check whether a passed pointer is non-zero and thus crash with NULL-pointers. the added patch performs these checks. is this a performance hog ??? this should fix BUG-1186531 (which i wasn't able to reproduce at all) ---------------------------------------------------------------------- >Comment By: Tim Blechmann (timblech) Date: 2005-07-16 11:52 Message: Logged In: YES user_id=326084 what about asserts? i think, this is, what they are for ... tim ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2005-07-16 02:32 Message: Logged In: YES user_id=313747 I think that adding speculative checks for NULL pointers will delay Pd crashing but whatever the problem was will manifest itself some other way later (and be even harder to reproduce and fix)... so for now I'd like to leave it so that it crashes right away if this ever happens... ---------------------------------------------------------------------- Comment By: IOhannes m zmÃ¶lnig (zmoelnig) Date: 2005-06-30 20:27 Message: Logged In: YES user_id=564396 the same for g_graph.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1224768&group_…

1 0

[ pure-data-Patches-1214164 ] route bug with zero-length lists ("bang") in float-mode
by SourceForge.net 16 Jul '05

16 Jul '05

Patches item #1214164, was opened at 2005-06-03 03:48 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1214164&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 Submitted By: IOhannes m zmÃ¶lnig (zmoelnig) Assigned to: Nobody/Anonymous (nobody) Summary: route bug with zero-length lists ("bang") in float-mode Initial Comment: when sending a "bang" message [route] in float-mode (e.g. [route 1 2]), the bang will silently vanish. i think this is due to the fact, that now "bang"s are equal to zero-length-lists which are discarded by the route_list-method in float-mode. anyhow, the attached patch (against pd-0.38-4) will send the "bang" to the reject-outlet ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2005-07-15 18:17 Message: Logged In: YES user_id=313747 Sounds right... so I took it... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1214164&group_…

1 0

← Newer
1
2
3
4
5
6
7
8
9
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 July 2005