On Nov 7, 2012, at 8:49 PM, pd-list-request@iem.at wrote:
From: Jonathan Wilkes jancsika@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@footils.org, "pd-list@iem.at" pd-list@iem.at Reply-To: Jonathan Wilkes jancsika@yahoo.com
----- Original Message -----
From: Frank Barknecht fbar@footils.org To: "pd-list@iem.at" pd-list@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. 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?
[1] You can certainly split symbols and count their length in Pd vanilla but it ain't pretty.
[list-sort] in list-abs.
Dan Wilcox danomatika.com robotcowboy.com
From: Dan Wilcox danomatika@gmail.com To: pd-list@iem.at Cc: Frank Barknecht fbar@footils.org; Jonathan Wilkes jancsika@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@iem.at wrote:
From: Jonathan Wilkes jancsika@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@footils.org, "pd-list@iem.at" pd-list@iem.at
Reply-To: Jonathan Wilkes jancsika@yahoo.com
----- Original Message -----
From: Frank Barknecht fbar@footils.org
To: "pd-list@iem.at" pd-list@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
Jesus, I wasn't responding to the specific example, nor was I saying you can do *everything* in Pd without externals. I too would love [coll] and [zl] in pd-vanilla. I'm also not saying you can easily build copies of them in vanilla, just that it is possible for certain things depending on what you need. By "seeing the vanilla light", I mean more that there are some things I needed externals for that I can replace and others I can reduce to a usable set for what I need ala rjdj. This is mainly because I will now need to target both desktop PD and a libpd environment.
Also, I've never had to sort a list of symbols, so our workflow is different. I mainly use PD for sound only and do graphics/other tasks separately.
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
Dan Wilcox danomatika.com robotcowboy.com
i'm sorry if i ruffled anyone's feathers, but as a Max guy [coll] is really useful for me. for example, if i know that using send and receives uses up more CPU, i start think think of remote ways to send and retrieve multiple lists. [coll] is perfect for that. one part of the machine stores values in [coll] the other part retrieves them. easy to set and retrieve multiple values as a result anywhere in the patch.
maybe it would just be fine if someone had a list of vetted externals compiled for libpd with a simple chart indicating whether it runs in iOS, Android, whatever. in fact it turns out that cyclone was ported by someone to libpd, so you can fork their build, and see if it works for you. still covered under BSD 3Clause (i looked up BSD 3 clause and it told me about the alternate name of Improved BSD) and if you read the license you can see it's more permissive about using binaries. anyway here's the site with the [cyclone] port:
https://github.com/niklassaers/PdTest02WithCyclone
i'm totally in support of the GPL but i think that a number of us are still using iOS devices because the hardware performance in audio in Android has yet to come up to the level of performance available in iOS. i believe that should happen sometime soon-ish, but until then it's a real issue, and there need to be alternatives available.
scott
On Thu, Nov 8, 2012 at 11:04 AM, Dan Wilcox danomatika@gmail.com wrote:
Jesus, I wasn't responding to the specific example, nor was I saying you can do *everything* in Pd without externals. I too would love [coll] and [zl] in pd-vanilla. I'm also not saying you can easily build copies of them in vanilla, just that it is possible for certain things depending on what you need. By "seeing the vanilla light", I mean more that there are some things I needed externals for that I can replace and others I can reduce to a usable set for what I need ala rjdj. This is mainly because I will now need to target both desktop PD and a libpd environment.
Also, I've never had to sort a list of symbols, so our workflow is different. I mainly use PD for sound only and do graphics/other tasks separately.
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
Dan Wilcox danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Dan Wilcox -
Jonathan Wilkes -
Scott R. Looney