Pd-dev January 2005

pd-dev@lists.iem.at

18 participants
43 discussions

simd optimized delread~/write~
by Tim Blechmann 11 Jan '05

11 Jan '05

hi all i implemented an simd optimized delread~ and delwrite~ ... works fine for me, but it has a different behaviour than the original delread~/delwrite~. i'm quantizing the delay samples to multiples op 16 ... seems reasonable to me, since the delread~/write~ objects take ms as argument, not samples ... but still, this changes the behaviour of the object!!! if someone needs the original behaviour, please uncomment #define DEL_SIMD in d_delay.c. there is also no test for denormals any more, devel_ uses the hardware daz/ftz on the sse unit ... cheers ... tim -- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

2 3

makefilename crash
by Tim Blechmann 10 Jan '05

10 Jan '05

hi miller & devs ... is this: |float 4( | |makefilename CR%sSH| | intended to crash? i'd somehow prefer to have a proper error message or a type conversion from float 4 to symbol 4 instead of a segfault ... cheers ... tim -- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

3 6

pdp: ov519 cam (eyetoy) working now
by Frank Barknecht 09 Jan '05

09 Jan '05

Hi, finally I got my webcam with ov519 chipset (Eyetoy and others) working in PDP/Linux. Attached is a patch against pdp_v4l.c which is very intrusive. ;) All jpeg loading should go into an external file and maybe be called as part of pdp_llconv. The code obviously more is a proof of concept, not production level, however I intend to use it as it is for now. pdp_v4l was extended by a method: "jpeg 0/1" which switches off and on the jpeg decompression of frames. Default is off, so your normal cams or tv cards will continue to work. I would love to see ov519 support in Gem and Gridflow, too. Adding the decompression turned out to be not too hard (it was hard for me, though!). The basic approach is to create a jpeg decompression setup, that does not read from a file, but from a memory location. In my code, this is done using the source manager: "jpeg_source_mgr source" The frames delivered by the ov519 cam carry some bookeeping information in their first two bytes, which need to be skipped when reading in the jpeg data and looking for their header. (Done through: "source.next_input_byte=newimage + 2;" in the code) After that it's simply calling the jpeg_read_scanlines stuff as it's also already done in various places where Gem or PDP load JPEG files. My code still gives some distortions and decompression errors in the resulting image, but basically works fine now. To build, you need to add "-ljpeg" to the makefile. I don't know how to add this to the autoconf stuff/build system of pdp. Have fun. Ciao -- Frank Barknecht _ ______footils.org__

1 0

flext build system - was: Re: [PD] compiling for MS
by Thomas Grill 07 Jan '05

07 Jan '05

> thanks for this, i've been wondering how you guys were building on win... Oh, by the way.... flext in CVS has got a new build system, that supports several compilers on several platforms for PD and Max, and which is used for compiling flext-based externals and flext itself, but can also be used for native PD or Max externals. Using it for a new project is as simple as writing a small info file (look for package.txt, for example in xsample), defining at least the external's name and the source files, and then calling the build.sh or build.bat script in the flext folder. It supports gcc 2.95+ (linux, MinGW, cygwin), Microsoft VC++ 6/7/7.1 and Borland C++ 5.5. I'm still having problems with cygwin (externals crash PD) and i don't know if it works under Windows 2000. If you want to test it, i'm happy about any feedback. Documentation includes readme.txt, build.txt and buildsys/build.txt in the flext package. best greetings, Thomas

1 0

bug: deleting number box after key
by Tim Blechmann 07 Jan '05

07 Jan '05

hi miller, hi all... if you have this patch: key | |atom| deleting the atom will crash pd: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 8136)] 0x08090581 in atom_string (a=0x8364c18, buf=0xbffff040 "0", bufsize=1000) at m_atom.c:89 89 for (sp = a->a_w.w_symbol->s_name, len = 0, quote = 0; *sp; sp++, len++)(gdb) where #0 0x08090581 in atom_string (a=0x8364c18, buf=0xbffff040 "0", bufsize=1000) at m_atom.c:89 #1 0x080912c8 in binbuf_gettext (x=0x835af50, bufp=0x83602e8, lengthp=0x83602ec) at m_binbuf.c:227 #2 0x08060a9c in rtext_retext (x=0x83602e8) at g_rtext.c:279 #3 0x080594e6 in glist_retext (glist=0x835ad60, y=0x835d8b8) at g_graph.c:142#4 0x0805d3e6 in gatom_redraw (client=0x835d8b8, glist=0x835ad60) at g_text.c:452 #5 0x080993ff in sys_flushqueue () at s_inter.c:736 #6 0x08099476 in sys_poll_togui () at s_inter.c:761 #7 0x080995df in sys_pollgui () at s_inter.c:816 #8 0x080963db in m_scheduler () at m_sched.c:486 #9 0x08096c32 in sys_main (argc=1, argv=0xbffff614) at s_main.c:337 #10 0x0809ceca in main (argc=1, argv=0xbffff614) at s_entry.c:29 the workaround is to delete the connection before deleting the object ... still it's a bug ... any idea? cheers ... tim -- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

3 3

set_callback
by Thomas Grill 07 Jan '05

07 Jan '05

Hi Tim, i just adapted flext to make use of the set_callback possibilities of devel_0_38. Seems to work flawlessly. Besides that i ask myself if the function name set_callback is a good choice... maybe it should rather be prepended with sys_ to be according to the usual conventions? best greetings, Thomas

2 1

more crashes
by Krzysztof Czaja 07 Jan '05

07 Jan '05

hi Miller, the stable .38 still suffers random crashes due to the obvious bug. I think this one is too important to let it wait for .39. Krzysztof -------- Original Message -------- Subject: [PD-dev] fixing guiqueue Date: Sat, 18 Dec 2004 15:16:22 +0100 From: Krzysztof Czaja <czaja(a)chopin.edu.pl> To: pd-dev <pd-dev(a)iem.at> hi Miller, looks like this typo in sys_unqueuegui() was behind many, if not all, quiqueue-related crashes reported on pd-list: --- s_inter.c~ 2004-10-25 05:10:19.000000000 +0200 +++ s_inter.c 2004-12-18 15:10:03.000000000 +0100 @@ -778,7 +778,7 @@ if (gq2->gq_client == client) { gq->gq_next = gq2->gq_next; - t_freebytes(gq, sizeof(*gq)); + t_freebytes(gq2, sizeof(*gq)); break; } }

3 2

[ pure-data-Bugs-1097901 ] Random GUI crashes
by SourceForge.net 07 Jan '05

07 Jan '05

Bugs item #1097901, was opened at 2005-01-07 14:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1097901&group_… Category: puredata Group: None Status: Open Resolution: None Priority: 9 Submitted By: Guenter Geiger (ggeiger) Assigned to: Miller Puckette (millerpuckette) Summary: Random GUI crashes Initial Comment: Submitting this for completeness, (see pd-dev list for further information). looks like this typo in sys_unqueuegui() was behind many, if not all, quiqueue-related crashes reported on pd-list: --- s_inter.c~ 2004-10-25 05:10:19.000000000 +0200 +++ s_inter.c 2004-12-18 15:10:03.000000000 +0100 @@ -778,7 +778,7 @@ if (gq2->gq_client == client) { gq->gq_next = gq2->gq_next; - t_freebytes(gq, sizeof(*gq)); + t_freebytes(gq2, sizeof(*gq)); break; } } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1097901&group_…

1 0

Re: [PD-dev] API documentation
by Georg Holzmann 07 Jan '05

07 Jan '05

Hallo! > It's nice to have both. If you have a well documented API it's much > easier to decipher the source, since you can clearly see a description > of a function, its arguments, its return value, and what file it resides > in. of course ... you are right. > bit no one will bother you. it you start an api documentation then you > should find a form that allows others to maintain it with you (wiki?) maybe this is the way to go ? We could use the PD-Wiki at http://pd.iem.at/pdwiki/ ? LG Georg -- +++ GMX - die erste Adresse für Mail, Message, More +++ 1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail

2 1

Re: [PD] setuid root problem: "failed to map segment from shared object: Resource temporarily unavailable"
by Tim Blechmann 07 Jan '05

07 Jan '05

(moving the thread to the pd-dev list) > pd: getbytes() failed -- out of memory > error: env: couldn't allocate buffer > env~ 8192 > ... couldn't create hmm ... then trying to code an simd improved delay line, i came across the same problem ... very strange ... sometimes i wasn't able to allocate memory for 500 ms ... my first thought was, that it's related to the overcommitment of memory, but it isn't ... i'm pretty clueless, what happens there, but it's definitely something very strange ... cheers ... tim -- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

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