[PD] Re: PDa update/buglist/comments
geiger at xdv.org
Fri Mar 18 20:17:24 CET 2005
On Fri, 18 Mar 2005, derek holzer wrote:
> Hi Guenter + the list,
Well, first off, an impressive bug and test report. I really appreciate
the work you have put into this. This puts PDa definitely a lot closer
to a release than before. I am going to put some comments further below.
> Guenter put up a new beta of PDa + Tcl/Tk libs for the IPAQ yesterday,
> so I tested most of the afternoon.
> And here's the bugs/comments of the day, as I discovered them. I'm using
> the latest PDa, Tcl and Tk packages from:
> with Familiar 0.8.1 on an HP IPAQ 5550, in case anyone's interested.
> Check the dates rather then the versions of the packages against what
> you have installed, as Guenter updated them yesterday without changing
> the version numbers.
Which was a bad idea. But I actually didn't change anything, but just
recompiled with a better configuration, thats why I kept the version
number. Anyhow, as it seems that it is not possible to create these
packages for both, familiar and openzaurus I will mark them in the
future with "-fam" or "-oz"
> I would tentatively recommended upgrading for anyone who's running it
> right now due to better oscillator sound, math operations and conversion
Thats nicely put, actually the old (openzaurus) version was completely
f***ed up for familiar. So everyone who has familiar should update in
any case. Those with openzaurus should stay at their version.
I just have a device with openzaurus currently, so testing for familiar
was not possible, but today I just bought an iPaq on ebay ... 81 Euros.
> BUGS CHECKED TODAY/COMMENTS:
> * [dbtorms], etc: You note: "conversion routines (dbtorms,mtof, etc) are
> only available for control flow", but I'm not sure what you mean by this...
I meant dbtorms~, motf~, etc.
> * I just checked [dbtorms], [rmstodb], [mtof] and [ftom] in the latest
> versions and they appear fine.
> * GUI window Audio Peak Meters: non-functional until DSP is switched
> off, then they flash a red "100".
> * GUI number boxes: will freeze GUI/crash PD if updated too frequently.
> Output of single [env~] object is sometimes enough to do this! Is there
> anything native in PDa to limit the refresh rate of the numberbox?
Hmm, I haven't had a freeze with a single numberbox until now. Maybe some
more tweaking on me part will be necessary
> * GUI tables/graphs: updating graphical tables also risky. [metro 1000]
> to a [tabwrite~] could be enough to crash PD.
One note on that. PDa is still based on 0.37, 0.38 should behave better
with GUI updates, ... but we'll see.
> * [vcf~]: You note: "vcf~ could be improved in quality". Agreed! Sound
> improved from previous version, which was largely unresponsive to
> frequency changes, but this object has possibility to freeze GUI + kill
> audio at unknown times. Prints "0.000141" to the terminal for no known
Yeah, writing filters in int math is a bitch. I have to check why it
freezes the application.
> * [lop~], [bp~] and [hip~] function as expected.
> * [routeOSC]: does not create.
> * [dumpOSC]: creates as expected.
> * [sendOSC]: does not create with following error:
> /usr//lib/pd/extra/sendOSC.pd_linux: undefined symbol: OSC_errorMessage
> * [netsend] + [netreceive]: work as expected.
> * [vd~]: does not create.
> * Other delay/table objects such as [delwrite~] + [delread~] and
> [tabwrite~] + [tabread~] don't seem to be different, except as you have
> noted: "tabread~ and tabwrite~ are indexed in milliseconds instead of
> * You might also mention in the docs that [soundfiler] exports length in
> ms not samples here as well.
> *Probably the interpolation of [tabread4~] is not available here in
hmm, its a lousy two point interpolation. It should not sound completely
> * [sfread~] + [sfwrite~]: you write: "The readsf and writesf objects are
> replaced by sfread and sfwrite", but you might clarify that these need
> tildes in the names: [sfread~], [sfwrite~].
> * Lots of clicks n' cuts when using the GUI with oscillators,
> etc. But you knew that already as well! OTOH, it seems to respond nicely
> to the -rt flag, making operation much much smoother.
Yes, one needs to fiddle with the flags a bit to get it stable. One idea
would be to figure out the best settings for each platform and put them
on the webpage.
Normally I adjust -audiobuf or -blocksize, then the -rt flag and
turing of adc if not used (-noadc)
> * Filters and (especially) oscillators sounding much better than before.
> [osc~] in particular gave a very nasty, distorted rectangle wave in the
> previous version I tested:
yes, thats looks really bad :)
> * Also, you might include my directions for remote X11 forwarding in
> your FAQ.
Apropos X11 forwarding. It might be that this is also costly. It would
be interesting if the problems are the same when run on the device
> * Will check audio recording with [sfwrite~] later on. Audioplayback
> with [tabread~] works as expected, haven't checked [sfread~] yet.
sfwrite~ might not work. On my todo list is still the builtin readsf and
writesf ... but thats for later.
> * Object requests:
> * [shell]: Ggee
> * [wrap]: Cyclone
> * [makesymbol], [date], [time]: Zexy
I will take this into account. Thanks again for this detail bug report.
Pushes me to bring out a new version soon.
More information about the Pd-list