[PD] list vs. symbol array [was: Re: Licensing issues]

[Jonathan Wilkes]

>________________________________
> From: Dan Wilcox <danomatika at gmail.com>
>To: pd-list at iem.at 
>Cc: Frank Barknecht <fbar at footils.org>; Jonathan Wilkes <jancsika at yahoo.com> 
>Sent: Thursday, November 8, 2012 11:25 AM
>Subject: Re: [PD] list vs. symbol array [was: Re: Licensing issues]
> 
>
>
>
>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>
>>>Cc: 
>>>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 
>>>then
>>>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 
>>>the
>>>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[1] 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.
>>
>>-Jonathan
>>
>
>
>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.

And what I'm saying is that some of those abstractions will _not_ *just work* for everyone because of the severe
limitations of working in Pd Vanilla without any externals.  You can't easily change [symbolarray] to accommodate
an array of lists instead of an array of symbols, and you cannot easily add a sorting mechanism because
splitting symbols in Pd is difficult and slow.  For someone coming from Max's [coll] and [zl] and finding [textfile]/
[qlist] inadequate for their list-of-list handling needs I find it very unlikely that [symbolarray] would suit their
needs.


> 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?

Look in [pd META] in the help patches for both those objects and it should tell you the license.
SIBSD = Standard Improved BSD (which isn't a "standard" name for this license at all so we should
probably change the terminology at some point) = 3-clause BSD

-Jonathan


>
>[1] You can certainly split symbols and count their length in Pd vanilla but it ain't
>>pretty.
>
>[list-sort] in list-abs.


It only works for lists of floats:


[list abigail aardvark(
|
[list-abs/list-sort]
|
[print]

print: list-sort: Warning: dropped a non-number from list
print: list-sort: Warning: dropped a non-number from list
print: bang


>
>--------
>Dan Wilcox
>danomatika.com
>robotcowboy.com
>
>
>
>
>
>
>