[PD] Re: PDa update/buglist/comments

[=?X-UNKNOWN?Q?g=FCnter_geiger?=]

On Fri, 18 Mar 2005, derek holzer wrote:
> Hi Guenter + the list,

Hi Derek,

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:
> http://gige.xdv.org/pda/release/familiar/
> 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
> routines.

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
> reason.

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:
> /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
> samples".
>
> * You might also mention in the docs that [soundfiler] exports length in
> ms not samples here as well.

good idea.

>
> *Probably the interpolation of [tabread4~] is not available here in
> Fixed-Point-land?

hmm, its a lousy two point interpolation. It should not sound completely
distorted, though.

>
> * [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:
> https://puredata.info/Members/derek/PDa.osc.1.png/image_view_fullscreen

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
directly.

> * 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.

Cheers,
Guenter