Hi Guenter + the list,
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.
I would tentatively recommended upgrading for anyone who's running it right now due to better oscillator sound, math operations and conversion routines. Major Tcl/Tk bug under IPAQ which piled all the text in the upper left corner is fixed. However, I've found the GUI in general more prone to crashing on "problem objects" (i.e. tables, numberboxes and [vcf~]) than before...see below for details.
BUGS CHECKED TODAY/COMMENTS:
only available for control flow", but I'm not sure what you mean by this...
versions and they appear fine.
off, then they flash a red "100".
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?
to a [tabwrite~] could be enough to crash PD.
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.
[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".
ms not samples here as well.
*Probably the interpolation of [tabread4~] is not available here in Fixed-Point-land?
replaced by sfread and sfwrite", but you might clarify that these need tildes in the names: [sfread~], [sfwrite~].
etc. But you knew that already as well! OTOH, it seems to respond nicely to the -rt flag, making operation much much smoother.
[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
your FAQ.
with [tabread~] works as expected, haven't checked [sfread~] yet.
thx + best, derek
hi derek,
I read:
- [routeOSC]: does not create.
I've seen that too, if you can get away without nested paths (I had to) you can use [route /foo /bar]
take care,
x
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:
- [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
On Fri, 18 Mar 2005, derek holzer wrote:
- [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".
Hi,
I could figure out the problem with vd~ you have. In PDa you are forced to create the vd~ after you have created the delwrite~. The same goes for delread~, but is seems that at that time you had tested delwrite~ already, so it worked. Anyhow, this might be a disturbing behaviour and I am thinking about a better solution (and error message :) I put that and some more things into the FAQ, going to update the rest during the week.
Cheers and thanks,
Guenter