[PD] list vs. symbol array [was: Re: Licensing issues]
danomatika at gmail.com
Thu Nov 8 17:25:42 CET 2012
On Nov 7, 2012, at 8:49 PM, pd-list-request at iem.at wrote:
> From: Jonathan Wilkes <jancsika at yahoo.com>
> Subject: Re: [PD] list vs. symbol array [was: Re: Licensing issues]
> Date: November 7, 2012 8:45:49 PM EST
> To: Frank Barknecht <fbar at footils.org>, "pd-list at iem.at" <pd-list at iem.at>
> Reply-To: Jonathan Wilkes <jancsika at yahoo.com>
> ----- Original Message -----
>> From: Frank Barknecht <fbar at footils.org>
>> To: "pd-list at iem.at" <pd-list at iem.at>
>> Sent: Tuesday, November 6, 2012 6:19 AM
>> Subject: [PD] list vs. symbol array [was: Re: Licensing issues]
>> I'm pretty sure, the patch at that time didn't either. The main problem
>> was the high frequency with which lookups had to happen. As a special election
>> day service I have written a benchmark showing this situation. On my machine
>> the symbolarray uses about 16 percent CPU at the "metro" period of
>> 0.01 ms
>> while list lookup uses 24. Now 0.01 ms may sound like a tempo you won't
>> encounter in real music, but that's wrong: In chords you play many notes at
>> same time, the "period" then is a very fast 0 ms. This can generate
>> CPU usage
>> spikes on slow devices if the lookup is too slow - at least that's my
>> explanation for why the symbolarray was able to fix the patch.
> [symbolarray] does indeed take about half as much cpu as using the message
> box. It also takes exactly the same cpu as [makefilename %d-tab] which is
> much simpler and doesn't require an abstraction. But maybe you needed
> those specific names for the tables for some reason...
> A lot of these Pd vanilla prototypes suffer from already being at the very edge
> of what can be developed with the prototype. You can't easily add a sort method,
> for example, nor can you extend the design to allow each element to be either a
> symbol or float without adding two fields to the template struct and a conditional
> that would impact the performance gain you get from using an array in the first
> place. Not to mention the near-complete lack of operators for symbols which is
> why I call it an array of Pet Rocks in this case.
I didn't mean to bring up an externals vs vanilla debate. We obviously use what's best for the situation. I'm choosing to work more in vanilla land because I simply can't include some externals in my app. Plus, I know those patches will *just work* for everyone. We'll see in practice if this works, but I'd much rather avoid coding custom externals for this project.
Also, does anyone know what cyclone's license is? I can't find the current version in the svn, but the old zip on the website has a BSD-like license. Having [coll] and [seq] would be very useful. It'd be nice to see these in vanilla at some point ... why reinvent the wheel?
>  You can certainly split symbols and count their length in Pd vanilla but it ain't
[list-sort] in list-abs.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list