Pd-dev February 2004

pd-dev@lists.iem.at

30 participants
55 discussions

compiling miXed causing headaches
by B. Bogart 13 Feb '04

13 Feb '04

I did a fresh update today and tried to compile toxy+cyclone on linux (gcc3.3) I changed the "Makefile.common" CC=gcc and made no other changes. After a while the build process seems to get itself into a beedback loop and prints the following over and over again without quiting: Thanks! Ben sickle/bitnot.c: In function `bitnot_perform': sickle/bitnot.c:33: warning: dereferencing type-punned pointer will break strict-aliasing rules make[2]: *** [sickle/bitnot.o] Error 1 make[2]: Leaving directory `/home/bbogart/externals/miXed/cyclone' make[2]: Entering directory `/home/bbogart/externals/miXed/toxy' make[2]: Leaving directory `/home/bbogart/externals/miXed/toxy' cd doc/src; make /bin/sh: line 1: cd: doc/src: No such file or directory make[2]: Entering directory `/home/bbogart/externals/miXed' make[3]: Entering directory `/home/bbogart/externals/miXed/shared' make[4]: Entering directory `/home/bbogart/externals/miXed/shared/common' gcc -Wall -W -Wstrict-prototypes -Werror -Wno-unused -Wno-parentheses -Wno-switch -O6 -funroll-loops -fomit-frame-pointer -DUNIX -I. -I../../../../pd/src -I../../shared -c -o binport.o binport.c binport.c: In function `binport_nextatom': binport.c:326: warning: dereferencing type-punned pointer will break strict-aliasing rules make[4]: *** [binport.o] Error 1 make[4]: Leaving directory `/home/bbogart/externals/miXed/shared/common' make[4]: Entering directory `/home/bbogart/externals/miXed/shared/hammer' make[4]: Leaving directory `/home/bbogart/externals/miXed/shared/hammer' make[4]: Entering directory `/home/bbogart/externals/miXed/shared/sickle' make[4]: Leaving directory `/home/bbogart/externals/miXed/shared/sickle' make[4]: Entering directory `/home/bbogart/externals/miXed/shared/toxy' make[4]: Leaving directory `/home/bbogart/externals/miXed/shared/toxy' make[4]: Entering directory `/home/bbogart/externals/miXed/shared/unstable' make[4]: Leaving directory `/home/bbogart/externals/miXed/shared/unstable' make[3]: Leaving directory `/home/bbogart/externals/miXed/shared' make[3]: Entering directory `/home/bbogart/externals/miXed/cyclone'

2 1

Help search; standard external installation paths
by Julius Smith 12 Feb '04

12 Feb '04

Dear pd-dev, When pd searches for a help file in response to "right-click Help" on some external object, the '~' is removed from the sought filename. This seems incorrect since it prevents "signal-based" and "message-based" objects from having the same root name. I would think the '~' should be fundamentally a part of the module's name. My current workaround is to install a symbolic link from "help-name~.pd" to "help-name.pd" in my doc dir for externals, which seems rather ugly. On a related topic, it would be nice if there were a standard recommended place to install such help files for pd extensions, e.g., /usr/local/lib/pd/doc/5.reference/extensions/<packagename>/. (I have seen /usr/local/lib/pd/doc/5.reference/<packagename>[help]/ used by some packages.) Similarly, it would also be helpful to have a standard recommended directory for installation of externals (and libraries of externals), such as /usr/local/lib/pd/extensions/<package-name>/. I have seen /usr/local/lib/pd/<package-name>/ used by some packages, which leaves it unclear what is an extension and what is native pd. -- Julius

9 25

[comment] object
by B. Bogart 12 Feb '04

12 Feb '04

Hello all, I was looking through the g_text.c source today and I noticed the "comment" object that seems to be different that the "comment" in the pd menu. One can type [comment] in an object box and get a nice non-courier sans comment! Why is this not used/documented more? One also seems able to resise the width of the comment to any size, and the text wraps properly, but I could not figure out how to widen the width of the comment box, only shrink. Was this part of the iemgui lib? Just sharing a little discovery. Ben

2 1

stupid pd problem
by Jeffrey Hildebrand 11 Feb '04

11 Feb '04

it keeps crashing due to my external. i'm totally confused because this never used to happen. also what was the fix for the "can't find the msvcrt.dll" thing? scott

2 1

some crashes
by Krzysztof Czaja 10 Feb '04

10 Feb '04

hi, all have been reproduced in 0.37-1test6 Krzysztof BUG #17 crash when receiver breaks a tcp connection from netsend to netreceive If there is a tcp connection established from netsend to netreceive, and the receiving end quits (or crashes), then the sender tends to crash when trying to talk to the other end. Plain closing of the receiving patch may crash both ends, e.g. if the patch is reopened (this might need another PR). BUG #18 [makefilename <%s-pattern>] crash Crash when sending a float to [makefilename <%s-pattern>]. BUG #19 'menuclose' crash Crash when sending 'pd-<name>.pd menuclose', if more than one <name>.pd is open. BUG #20 setting the gop flag may lead to crashes Crash when opening a gop after transforming it from a non-gop in certain ways (details in How-To-Repeat field). BUG #21 self-destruction crash Crash if sending to a target causes it to perform self-destruction. BUG #22 message 'receive' to iemguis broken, causing crashes Message 'receive' to iemguis is broken. This has two consequences: 1. since the new target is not bound, the object cannot be reached remotely anymore; 2. since the old target is never unbound, sending to that target after object's destruction (patch closing, etc.) crashes Pd. The immediate reason is that in iemgui_receive(), the condition if(strcmp(rcv->s_name, iemgui->x_rcv->s_name)) is always false due to the previous iemgui->x_rcv = rcv = canvas_realizedollar(iemgui->x_glist, rcv); Not sure, whether this message should be patched or removed, though -- self-rebinding is not yet safe in Pd.

4 4

~externals: i/o vector size and alignment
by Andy Schmeder 09 Feb '04

09 Feb '04

Hi. With respect to the float** in / out of a m_signal method for an external, does PD make any assurance that the vector length will be dyadic (i.e. a power of two), and also is there any assurance that the memory is aligned in any way (e.g. 128-bit, 64-bit aligned, etc.)? Thank you. Andy. --------------------------------------------------------------- Andrew (Andy) W. Schmeder mailto:andy@a2hd.com http://www.a2hd.com

3 4

fluid~ question
by Georg Holzmann 08 Feb '04

08 Feb '04

Hello list! I've two questions about the fluid~ external by Frank Barknecht: 1) I tried to play a soundfount with my keyboard and noticed, that my pedal doesn't work (but I got numbers from the ctlin)! Is this normal? I also tried other soundfonts, but it doesn't work. I'd really like to use it, so do you know what I could make? (pd 0.37 / WinXP) 2) I also tried to compile fluid (because I have an old version) with VC++ 6 and everything worked fine, but then I build it and got following errors: Linking... Creating library Debug/fluid.lib and object Debug/fluid.exp LINK : warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library main.obj : error LNK2001: unresolved external symbol __imp__delete_fluid_synth main.obj : error LNK2001: unresolved external symbol __imp__fluid_synth_sfload main.obj : error LNK2001: unresolved external symbol __imp__fluid_synth_noteon main.obj : error LNK2001: unresolved external symbol __imp__fluid_synth_program_change main.obj : error LNK2001: unresolved external symbol __imp__fluid_synth_cc main.obj : error LNK2001: unresolved external symbol __imp__fluid_synth_pitch_bend main.obj : error LNK2001: unresolved external symbol __imp__fluid_synth_bank_select main.obj : error LNK2001: unresolved external symbol __imp__delete_fluid_settings main.obj : error LNK2001: unresolved external symbol __imp__new_fluid_synth main.obj : error LNK2001: unresolved external symbol __imp__fluid_settings_setstr main.obj : error LNK2001: unresolved external symbol __imp__fluid_settings_setnum main.obj : error LNK2001: unresolved external symbol __imp__new_fluid_settings main.obj : error LNK2001: unresolved external symbol __imp__fluid_synth_write_float Debug/fluid.dll : fatal error LNK1120: 13 unresolved externals Error executing link.exe. fluid.dll - 14 error(s), 1 warning(s) Does anyone has a suggestion? Thank you for your help, LG Georg Holzmann -- GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++

2 1

some fixes to d_soundfile.c
by Krzysztof Czaja 07 Feb '04

07 Feb '04

hi, a few bugs from my gnats db, which all have quick fixes (patched against pd-0.37-1test6) Krzysztof BUG #25 soundfiler reads a trailer of a stereo .wav file as part of a sample Quite often, there is a trailer chunk after data chunk in a .wav file. Soundfiler (correctly) does not read trailers of mono files, but (incorrectly) loads a trailer into an array (or arrays), if the file has additional channels. Fix: In d_soundfile.c, change lines 1020-1021 to - if (framesinfile > bytelimit / bytespersamp) - framesinfile = bytelimit / bytespersamp; + if (framesinfile > bytelimit / (channels * bytespersamp)) + framesinfile = bytelimit / (channels * bytespersamp); and change lines 1040-1041 to - if (finalsize > bytelimit / bytespersamp) - finalsize = bytelimit / bytespersamp; + if (finalsize > bytelimit / (channels * bytespersamp)) + finalsize = bytelimit / (channels * bytespersamp); BUG #26 a pop made by reading .wav file trailer as part of a sample It is quite common for a .wav file to contain a trailer chunk following sample data. Readsf~ correctly excludes it from playback in some cases, but in other cases does not. Fix: This is one of the two fixes needed: after line 1489 in d_soundfile.c add else wantbytes = READSIZE; + if (wantbytes > x->x_bytelimit) + wantbytes = x->x_bytelimit; The other one, subtracting a skip offset from the `bytelimit' variable in open_soundfile(), is reported separately, because it affects both readsf~, and soundfiler. BUG #27 readsf~ and soundfiler run over .wav file trailer if skip option used Yet another case of .wav file trailer chunk causing pops in playback from arrays and from readsf~. The pops occur, if the option 'skip' is used as part of the 'read' message to soundfiler, or as an argument of the 'open' message to readsf~. Fix: In d_soundfile.c, before line 375, add + bytelimit -= nchannels * bytespersamp * skipframes; + if (bytelimit < 0) + bytelimit = 0; /* copy sample format back to caller */ BUG #28 readsf~ truncates files, if number of samples != multiple of dsp block If the last dsp block in a stream of sample data to be output by readsf~ is going to be only partially filled from a sound file, readsf~ fills it all with zeros. In effect, the file is truncated on playback. Fix: In d_soundfile.c, function readsf_perform(), declare a local variable xfersize of type int, and before line 1669 add + xfersize = (x->x_fifohead - x->x_fifotail + 1) / + (sfchannels * bytespersample); + if (xfersize) + { + soundfile_xferin(sfchannels, noutlets, x->x_outvec, 0, + (unsigned char *)(x->x_buf + x->x_fifotail), xfersize, + bytespersample, bigendian); + vecsize -= xfersize; + for (i = 0; i < noutlets; i++) + for (j = vecsize, fp = x->x_outvec[i] + xfersize; j--; ) + *fp++ = 0; + return (w+2); + } goto idle; BUG #30 endianness bug remains in soundfiler Endianness bug in soundfiler_writeargparse() remains. Actually, there were two bugs, a typo and an omission -- typo has been corrected, omission has not. Fix: In d_soudfile.c add the missing clause before line 581: + else bigendian = endianness; swap = (bigendian != garray_ambigendian()); BUG #31 debugging overhead left in readsf~ and writesf~ In release version, i.e. with debugging printout from readsf~ and writesf~ disabled, the "sprintf(boo..." debugging calls are still performed. Fix: In d_soundfile.c, comment out the lines 1430-2, 1460-2, 1523-5, 1963-5. For example, change line 1303 to -#if 0 +//#define DEBUG_SOUNDFILE +#ifdef DEBUG_SOUNDFILE and add #ifdef DEBUG_SOUNDFILE ... #endif clause around the above lines. BUG #32 sending 'normalize' to an array of zeros produces an array of nans Sending 'normalize' to an array of zeros produces an array of nans. Fix: In g_array.c, line 951, change the condition maxv >= 0 to maxv > 0

2 1

pd-dev archive missing latest months
by Hans-Christoph Steiner 07 Feb '04

07 Feb '04

This works fine: http://iem.kug.ac.at/mailinglists/pd-dev/2003-09 These are all missing for me: http://iem.kug.ac.at/mailinglists/pd-dev/2003-10 http://iem.kug.ac.at/mailinglists/pd-dev/2003-11 http://iem.kug.ac.at/mailinglists/pd-dev/2003-12 http://iem.kug.ac.at/mailinglists/pd-dev/2004-01 I think before the cron job stopped running, or something like that. .hc http://at.or.at/hans/

1 0

a bag for bugs
by Krzysztof Czaja 07 Feb '04

07 Feb '04

hi devels, without much thinking about tools and structure, I have started building a database of bugs and buglets in the core of Pd (aka Miller's sources). Before shaping it into a form suitable for a more general use, I would like first to collect as much data as I can, from pd-list, and from my experience. Which is the easy part. The hard part, I think, is not just gathering reports, but managing them afterwards. Usually, there would be a person `responsible' for validating a particular category of a report, and guiding the report through its lifetime in the database. That person would either actually maintain the source, or closely cooperate with a maintainer. Such setup might prove too formal, though, in case of the ``Miller's & co(mmunity)'' development model. I do not know... perhaps, that model requires a `sync-person' tracking the releases, with Miller occasionally getting forwarded mailings or digests? The tool is gnats, currently, chosen for the sake of being able to start easily and locally, without bloating my system with apache, mysql, and what not. Gnats is nicely designed, but for some odd reason hardly maintained anymore -- hence buggy, and largely abandoned outside of the freebsd world. The transition of my local database into a public service, will probably mean importing data into some other bug tracker (requiring, hopefully, only a simple script to be written, or adapted). When more of the actual contents builds in, I will let you know. For the time being -- comments, please (and bug reports, of course). Krzysztof

3 2

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 2004