I'll chime in on what Peter said.
Pd-Extended itself doesn't have a global license, the licenses are individual to the externals. libpd itself is BSD so we can use it on iOS while some externals are GPL and we can't. I personally would *like* to have some available, but I also value the GPL and would not wish anyone to change a license just for my convenience at a cost to protections the GPL is designed to ensure. I'm not anti-Apple or anti-GPL, it's just a pragmatic approach to getting a working solution on good hardware. Unfortunately, Android still does not have good audio latency worked out, for instance.
As I told Frank B, I've seen the "vanilla light". There is a whole lot you can do without externals and I'd highly recommend checking out rjlib: https://github.com/rjdj/rjlib. I will be rebuilding my patch library to work with rjlib and be vanilla compatible as it's the best way to know it works in libpd-land as well as on desktop.
On Nov 3, 2012, at 11:08 AM, pd-list-request@iem.at wrote:
From: Peter Kirn peter@createdigitalmedia.net Subject: Re: [PD] Licensing issues (was rjdj is gone, robotcowboy is coming ...) Date: November 3, 2012 7:17:06 AM EDT To: pd-list pd-list@iem.at
Hello, I just want to chime in here.
I don't think it's accurate to say pd-extended is "GPL." pd-extended is essentially a distribution of externals, abstractions, and other conveniences. Obviously, developers are free to use what license they want.
Yes, libpd and Pd-vanilla use an extremely permissive license.
I believe it's possible to develop free software for iOS. I think on reflection it makes a stronger statement to reach that platform - locked-down as it may be - with free software than it does to ignore it. This means using a BSD- or MIT-style license and not GPL or LGPL; the earlier thread was right. Note that I think you *can* use a copyleft license for your patches, because these will run independently of iOS.
There are other reasons - compatibility and simplicity being foremost - to favor vanilla in development with libpd whether or not you're using iOS. I think we may be overstating the problem here a bit.
In other words, yes, Apple has a problem with GPL. But libpd developers I think don't have a problem with Apple, if that makes sense. And I think we make a stronger statement by showing how well the free solution works than we do banging our head against a brick wall.
I believe in the GPL license, which is why we're using it on MeeBlip. But I think the short answer is, use BSD with libpd, try to default to vanilla, and maximize the contexts with which your software can be used. Add GPL or copyleft to patches to encourage others to share. That for me seems a pretty nice solution.
Now, Apple aside, it does seem that it makes sense for external developers to use the same license as Pd. (Patches and abstractions are a different issues, because they're effectively content rather than part of your code.) But that's up to developers.
Peter
Dan Wilcox danomatika.com robotcowboy.com
for me, it's more a matter that a lot of objects are available that make the basic coding and patch building tasks themselves much easier. the one that currently comes to mind is [coll] which is part of cyclone. i really have no idea what can be substituted for it that only requires PD vanilla, but i'm coming from Max, and not having good list management is an obstacle.
is there is a good way for PD-vanilla to read and manipulate a list of lists like coll? or split lists? i can make my own [counter] and [swap] objects easily enough, but having no obvious and apparent means of storage/recall/manipulation, except arrays and tables which are one index one value. not trying to pull this off the licensing discussion, but i'm trying to point out a genuine storage/manipulation need here. i'm happy to stay with vanilla only if PD can do these things. [qlist] + [textfile] are the closest but seem to come with severe manipulation restrictions. cyclone comes with [zl] manipulation.
if i'm needlessly complaining please let me know. i'm just a midrange MaxMSP guy trying to see how to get something running on iOS.
scott
On Sat, Nov 3, 2012 at 10:51 AM, Dan Wilcox danomatika@gmail.com wrote:
I'll chime in on what Peter said.
Pd-Extended itself doesn't have a global license, the licenses are individual to the externals. libpd itself is BSD so we can use it on iOS while some externals are GPL and we can't. I personally would *like* to have some available, but I also value the GPL and would not wish anyone to change a license just for my convenience at a cost to protections the GPL is designed to ensure. I'm not anti-Apple or anti-GPL, it's just a pragmatic approach to getting a working solution on good hardware. Unfortunately, Android still does not have good audio latency worked out, for instance.
As I told Frank B, I've seen the "vanilla light". There is a whole lot you can do without externals and I'd highly recommend checking out rjlib: https://github.com/rjdj/rjlib. I will be rebuilding my patch library to work with rjlib and be vanilla compatible as it's the best way to know it works in libpd-land as well as on desktop.
On Nov 3, 2012, at 11:08 AM, pd-list-request@iem.at wrote:
*From: *Peter Kirn peter@createdigitalmedia.net *Subject: **Re: [PD] Licensing issues (was rjdj is gone, robotcowboy is coming ...)* *Date: *November 3, 2012 7:17:06 AM EDT *To: *pd-list pd-list@iem.at
Hello, I just want to chime in here.
I don't think it's accurate to say pd-extended is "GPL." pd-extended is essentially a distribution of externals, abstractions, and other conveniences. Obviously, developers are free to use what license they want.
Yes, libpd and Pd-vanilla use an extremely permissive license.
I believe it's possible to develop free software for iOS. I think on reflection it makes a stronger statement to reach that platform - locked-down as it may be - with free software than it does to ignore it. This means using a BSD- or MIT-style license and not GPL or LGPL; the earlier thread was right. Note that I think you *can* use a copyleft license for your patches, because these will run independently of iOS.
There are other reasons - compatibility and simplicity being foremost - to favor vanilla in development with libpd whether or not you're using iOS. I think we may be overstating the problem here a bit.
In other words, yes, Apple has a problem with GPL. But libpd developers I think don't have a problem with Apple, if that makes sense. And I think we make a stronger statement by showing how well the free solution works than we do banging our head against a brick wall.
I believe in the GPL license, which is why we're using it on MeeBlip. But I think the short answer is, use BSD with libpd, try to default to vanilla, and maximize the contexts with which your software can be used. Add GPL or copyleft to patches to encourage others to share. That for me seems a pretty nice solution.
Now, Apple aside, it does seem that it makes sense for external developers to use the same license as Pd. (Patches and abstractions are a different issues, because they're effectively content rather than part of your code.) But that's up to developers.
Peter
Dan Wilcox danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
That's on my list for 0.44... not there yet though (and I'm up to my eyes in debugging problems right now :)
M
On Sat, Nov 03, 2012 at 01:16:49PM -0700, Scott R. Looney wrote:
for me, it's more a matter that a lot of objects are available that make the basic coding and patch building tasks themselves much easier. the one that currently comes to mind is [coll] which is part of cyclone. i really have no idea what can be substituted for it that only requires PD vanilla, but i'm coming from Max, and not having good list management is an obstacle.
is there is a good way for PD-vanilla to read and manipulate a list of lists like coll? or split lists? i can make my own [counter] and [swap] objects easily enough, but having no obvious and apparent means of storage/recall/manipulation, except arrays and tables which are one index one value. not trying to pull this off the licensing discussion, but i'm trying to point out a genuine storage/manipulation need here. i'm happy to stay with vanilla only if PD can do these things. [qlist] + [textfile] are the closest but seem to come with severe manipulation restrictions. cyclone comes with [zl] manipulation.
if i'm needlessly complaining please let me know. i'm just a midrange MaxMSP guy trying to see how to get something running on iOS.
scott
On Sat, Nov 3, 2012 at 10:51 AM, Dan Wilcox danomatika@gmail.com wrote:
I'll chime in on what Peter said.
Pd-Extended itself doesn't have a global license, the licenses are individual to the externals. libpd itself is BSD so we can use it on iOS while some externals are GPL and we can't. I personally would *like* to have some available, but I also value the GPL and would not wish anyone to change a license just for my convenience at a cost to protections the GPL is designed to ensure. I'm not anti-Apple or anti-GPL, it's just a pragmatic approach to getting a working solution on good hardware. Unfortunately, Android still does not have good audio latency worked out, for instance.
As I told Frank B, I've seen the "vanilla light". There is a whole lot you can do without externals and I'd highly recommend checking out rjlib: https://github.com/rjdj/rjlib. I will be rebuilding my patch library to work with rjlib and be vanilla compatible as it's the best way to know it works in libpd-land as well as on desktop.
On Nov 3, 2012, at 11:08 AM, pd-list-request@iem.at wrote:
*From: *Peter Kirn peter@createdigitalmedia.net *Subject: **Re: [PD] Licensing issues (was rjdj is gone, robotcowboy is coming ...)* *Date: *November 3, 2012 7:17:06 AM EDT *To: *pd-list pd-list@iem.at
Hello, I just want to chime in here.
I don't think it's accurate to say pd-extended is "GPL." pd-extended is essentially a distribution of externals, abstractions, and other conveniences. Obviously, developers are free to use what license they want.
Yes, libpd and Pd-vanilla use an extremely permissive license.
I believe it's possible to develop free software for iOS. I think on reflection it makes a stronger statement to reach that platform - locked-down as it may be - with free software than it does to ignore it. This means using a BSD- or MIT-style license and not GPL or LGPL; the earlier thread was right. Note that I think you *can* use a copyleft license for your patches, because these will run independently of iOS.
There are other reasons - compatibility and simplicity being foremost - to favor vanilla in development with libpd whether or not you're using iOS. I think we may be overstating the problem here a bit.
In other words, yes, Apple has a problem with GPL. But libpd developers I think don't have a problem with Apple, if that makes sense. And I think we make a stronger statement by showing how well the free solution works than we do banging our head against a brick wall.
I believe in the GPL license, which is why we're using it on MeeBlip. But I think the short answer is, use BSD with libpd, try to default to vanilla, and maximize the contexts with which your software can be used. Add GPL or copyleft to patches to encourage others to share. That for me seems a pretty nice solution.
Now, Apple aside, it does seem that it makes sense for external developers to use the same license as Pd. (Patches and abstractions are a different issues, because they're effectively content rather than part of your code.) But that's up to developers.
Peter
Dan Wilcox danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Check out the rjlib m_symbol array in rjlib: https://github.com/rjdj/rjlib It's made in vanilla using data structures.
On Nov 3, 2012, at 4:16 PM, "Scott R. Looney" scottrlooney@gmail.com wrote:
is there is a good way for PD-vanilla to read and manipulate a list of lists like coll? or split lists? i can make my own [counter] and [swap] objects easily enough, but having no obvious and apparent means of storage/recall/manipulation, except arrays and tables which are one index one value. not trying to pull this off the licensing discussion, but i'm trying to point out a genuine storage/manipulation need here. i'm happy to stay with vanilla only if PD can do these things. [qlist] + [textfile] are the closest but seem to come with severe manipulation restrictions. cyclone comes with [zl] manipulation.
Dan Wilcox danomatika.com robotcowboy.com
That's a bit like having an abstraction to make an array of Pet Rocks. What do you use it for?
-Jonathan
From: Dan Wilcox danomatika@gmail.com To: Scott R. Looney scottrlooney@gmail.com Cc: "pd-list@iem.at list" pd-list@iem.at Sent: Saturday, November 3, 2012 8:13 PM Subject: Re: [PD] Licensing issues (was rjdj is gone, robotcowboy is coming ...)
Check out the rjlib m_symbol array in rjlib: https://github.com/rjdj/rjlib%C2%A0It%27s made in vanilla using data structures.
On Nov 3, 2012, at 4:16 PM, "Scott R. Looney" scottrlooney@gmail.com wrote:
is there is a good way for PD-vanilla to read and manipulate a list of lists like coll? or split lists? i can make my own [counter] and [swap] objects easily enough, but having no obvious and apparent means of storage/recall/manipulation, except arrays and tables which are one index one value. not trying to pull this off the licensing discussion, but i'm trying to point out a genuine storage/manipulation need here. i'm happy to stay with vanilla only if PD can do these things. [qlist] + [textfile] are the closest but seem to come with severe manipulation restrictions. cyclone comes with [zl] manipulation.
Dan Wilcox danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
True, it only does symbols, but there are options out there.
On Nov 3, 2012, at 10:48 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
That's a bit like having an abstraction to make an array of Pet Rocks. What do you use it for?
-Jonathan
From: Dan Wilcox danomatika@gmail.com To: Scott R. Looney scottrlooney@gmail.com Cc: "pd-list@iem.at list" pd-list@iem.at Sent: Saturday, November 3, 2012 8:13 PM Subject: Re: [PD] Licensing issues (was rjdj is gone, robotcowboy is coming ...)
Check out the rjlib m_symbol array in rjlib: https://github.com/rjdj/rjlib It's made in vanilla using data structures.
On Nov 3, 2012, at 4:16 PM, "Scott R. Looney" scottrlooney@gmail.com wrote:
is there is a good way for PD-vanilla to read and manipulate a list of lists like coll? or split lists? i can make my own [counter] and [swap] objects easily enough, but having no obvious and apparent means of storage/recall/manipulation, except arrays and tables which are one index one value. not trying to pull this off the licensing discussion, but i'm trying to point out a genuine storage/manipulation need here. i'm happy to stay with vanilla only if PD can do these things. [qlist] + [textfile] are the closest but seem to come with severe manipulation restrictions. cyclone comes with [zl] manipulation.
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 danomatika.com robotcowboy.com
Hi,
On Sat, Nov 03, 2012 at 07:48:45PM -0700, Jonathan Wilkes wrote:
That's a bit like having an abstraction to make an array of Pet Rocks. What do you use it for?
Everywhere you need to translate an index number into an arbitrary symbol. For example to translate midi note numbers to table-names in a generic sample player.
Frank Barknecht _ ______footils.org__
My 2pence worth:
Working with libpd for an iOS application, to be distributed through the app store: I found it necessary to
There is so much in the rjdj library that can help, but a lot of lateral thinking is needed if you're used to Pd-extended objects. For example, I use [goto $1, this( a lot with [msgfile] to organize lists of data, sequences etc. You can't do that with [textfile] so you have to:
[f]
|
[t b b f b]
| | |
| \ |
| __|________
| | \
| [until] |
___ | \
\ | \
[textfile] | |
\ [0 ( [1 (
\ /____/
[spigot]
...perhaps there is another way?
[t f b]
| ______________
|
[f] [f]
| |
| [makefilename wav-%s-%%s]
| /
| [set $1(
| __________________/
|/
[makefilename not-set-yet]
|
[set $1(
|
[tabread4~]
In the [makefilename] object, %%s becomes %s when it's output. %%%%s becomes %%s, so you can have more levels of hierarchy for naming conventions.
[sieve] external from ekext is invaluable. For each bar number you can store another number containing a parameter (such as a table name etc). It's BSD licensed and ready to go.
Apologies but I can't post the source code for the app I made for legal reasons (! - that's the rub) but these are some tips.
While I believe in GPL and have benefited a great deal from it's existence (Linux anyone?) I think it would be a good time to start getting an "libpd add-ons" library of externals together, that developers didn't mind being used for commercial projects.
Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
From: Frank Barknecht fbar@footils.org To: pd-list@iem.at Sent: Sunday, 4 November 2012, 10:52 Subject: Re: [PD] Licensing issues (was rjdj is gone, robotcowboy is coming ...)
Hi,
On Sat, Nov 03, 2012 at 07:48:45PM -0700, Jonathan Wilkes wrote:
That's a bit like having an abstraction to make an array of Pet Rocks. What do you use it for?
Everywhere you need to translate an index number into an arbitrary symbol. For example to translate midi note numbers to table-names in a generic sample player.
Ciao
Frank Barknecht _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-11-04 14:40, Ed Kelly wrote:
My 2pence worth: Miller's original Pd was licensed to MAX and became MSP (oh, the irony) and this could only happen because Pd is BSD (not GPL) licensed distribution.
where is the irony? cycling74 did *not* steal any code.
- re-license my own library of externals ekext to BSD license. 2)
code new externals [...]. This code was released BSD.
btw, you don't need to do this, in order to be able to circumvent the GPL-clauses of iOS. if you are the copyright holder of the code, you can simply release your code under a dual license, e.g. under GPL and under some proprietary "all rights reserved" EULA thing. iOS would only ever see the "all rights reserved" part.
this will only work if you are the only copyright holder of the code or have the agreement of all other copyright holders to change the license. the same however is true, if you change the license from GPL to BSD3. i'm sure you did check with all those people that contributed to ekext in the past....
the drawback here is that *other* people cannot use your code for building their own iOS applications. you could however re-license the code to those people explicitely (so the awareness on apple's license politics raises)
the pro of dual-licensing is, that the code will still be available under GPL and enforce GPL in the majority of cases (that is: non-iOS)
cmadr iOhannes
Oooh, I didn't know that! I played it safe I thought.
On 2012-11-04 14:40, Ed Kelly wrote:
My 2pence worth: Miller's original Pd was licensed to MAX and became MSP (oh, the irony) and this could only happen because Pd is BSD (not GPL) licensed distribution.
where is the irony? cycling74 did *not* steal any code.
Perhaps...that it is ironic that after not being able to use the Max code, the thing he develops becomes part of Max. Perhaps ironic is the wrong word!
- re-license my own library of externals ekext to BSD license. 2)
code new externals [...]. This code was released BSD.
btw, you don't need to do this, in order to be able to circumvent the GPL-clauses of iOS. if you are the copyright holder of the code, you can simply release your code under a dual license, e.g. under GPL and under some proprietary "all rights reserved" EULA thing. iOS would only ever see the "all rights reserved" part.
this will only work if you are the only copyright holder of the code or have the agreement of all other copyright holders to change the license. the same however is true, if you change the license from GPL to BSD3. i'm sure you did check with all those people that contributed to ekext in the past....
the drawback here is that *other* people cannot use your code for building their own iOS applications. you could however re-license the code to those people explicitely (so the awareness on apple's license politics raises)
the pro of dual-licensing is, that the code will still be available under GPL and enforce GPL in the majority of cases (that is: non-iOS)
Thank you for your enlightenment on this.
cmadr iOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlCXdSYACgkQkX2Xpv6ydvR2ZACbBUod2mttUIyGTLGzE7wHOjdP DtoAnA8B+LpJi9l8cvysfh5JX9q5IKbu =8EkH -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-11-06 10:31, Ed Kelly wrote:
where is the irony? cycling74 did *not* steal any code.
Perhaps...that it is ironic that after not being able to use the Max code, the thing he develops becomes part of Max. Perhaps ironic is the wrong word!
ircam != cycling74
- re-license my own library of externals ekext to BSD license.
[...]
Thank you for your enlightenment on this.
at least that is how i understand that. i'm no lawyer :-)
fgmasdr iOhannes
[list of the table names( | | [r midi_note_number] | / | [set $1( | / [ ( |
If the essence of "seeing the light" regarding Pd Vanilla is that it's more efficient to use what's already there to read/write/share patches, I don't see why you'd prefer the abstraction to such a straightforward idiom to solve your task.
But my main point about Pet Rocks is that there are no operators for symbols in Pd Vanilla aside from measuring equality.
-Jonathan
----- Original Message -----
From: Frank Barknecht fbar@footils.org To: pd-list@iem.at Cc: Sent: Sunday, November 4, 2012 5:52 AM Subject: Re: [PD] Licensing issues (was rjdj is gone, robotcowboy is coming ...)
Hi,
On Sat, Nov 03, 2012 at 07:48:45PM -0700, Jonathan Wilkes wrote:
That's a bit like having an abstraction to make an array of Pet Rocks. What do you use it for?
Everywhere you need to translate an index number into an arbitrary symbol. For example to translate midi note numbers to table-names in a generic sample player.
Ciao
Frank Barknecht _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi,
On Sun, Nov 04, 2012 at 05:48:23PM -0800, Jonathan Wilkes wrote:
[list of the table names( | |Â Â Â [r midi_note_number] |Â Â / |Â [set $1( | / [ ( |
If the essence of "seeing the light" regarding Pd Vanilla is that it's more efficient to use what's already there to read/write/share patches, I don't see why you'd prefer the abstraction to such a straightforward idiom to solve your task.
For m_symbolarray the main reason was speed and as a side-effect allowing "holes" in the array. Accessing an array (even one in a data structure) is a lot faster than sending around a long list every time a lookup is needed. m_symbolarray made a patch run nicely on an iPhone that was totally overloading the device before.
Of course often you just can get away with the usual approach that you outlined above, and please do so, if you don't run into problems.
But if a) the number of names (i.e. the list length) gets large or b) you have to activate this idiom many, many times, you can hit a wall. And it's quite easy to make a) and b) with sample players if you play polyphonic music with many instruments in it. Here m_symbolarray is one way out.
Frank Barknecht _ ______footils.org__
----- Original Message -----
From: Frank Barknecht fbar@footils.org To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Monday, November 5, 2012 9:48 AM Subject: Re: [PD] Licensing issues (was rjdj is gone, robotcowboy is coming ...)
Hi,
On Sun, Nov 04, 2012 at 05:48:23PM -0800, Jonathan Wilkes wrote:
[list of the table names( | | [r midi_note_number] | / | [set $1( | / [ ( |
If the essence of "seeing the light" regarding Pd Vanilla is that
it's more
efficient to use what's already there to read/write/share patches, I
don't
see why you'd prefer the abstraction to such a straightforward idiom to solve your task.
For m_symbolarray the main reason was speed and as a side-effect allowing "holes" in the array. Accessing an array (even one in a data structure) is a lot faster than sending around a long list every time a lookup is needed. m_symbolarray made a patch run nicely on an iPhone that was totally overloading the device before.
Oops, my ascii art above should have [set, adddollar $1( in it.
How many table names total were there in the patch that was overloading the device?
-Jonathan
Of course often you just can get away with the usual approach that you outlined above, and please do so, if you don't run into problems.
But if a) the number of names (i.e. the list length) gets large or b) you have to activate this idiom many, many times, you can hit a wall. And it's quite easy to make a) and b) with sample players if you play polyphonic music with many instruments in it. Here m_symbolarray is one way out.
Ciao
Frank Barknecht _ ______footils.org__
Hi,
On Mon, Nov 05, 2012 at 08:26:17AM -0800, Jonathan Wilkes wrote:
How many table names total were there in the patch that was overloading the device?
I don't remember anymore, that was in 2009, when the abstraction was first posted here on pd-list.
But if you don't believe me, just do some benchmarks on your own and compare array access with list filtering.
Frank Barknecht _ ______footils.org__
hello,
yes, list are very slow.
by example, pmpd* object have messages to output list, in order to "list prepend 0" - "list trim" - "send table-foo" we add few years ago messages to allow direct writing to table.
using list size > 100 or 1000 gives incredible speed difference.
cheers Cyrille
Le 05/11/2012 18:29, Frank Barknecht a écrit :
Hi,
On Mon, Nov 05, 2012 at 08:26:17AM -0800, Jonathan Wilkes wrote:
How many table names total were there in the patch that was overloading the device?
I don't remember anymore, that was in 2009, when the abstraction was first posted here on pd-list.
But if you don't believe me, just do some benchmarks on your own and compare array access with list filtering.
Ciao
----- Original Message -----
From: Cyrille Henry ch@chnry.net To: Frank Barknecht fbar@footils.org Cc: "pd-list@iem.at" pd-list@iem.at Sent: Monday, November 5, 2012 1:53 PM Subject: Re: [PD] Licensing issues (was rjdj is gone, robotcowboy is coming ...)
hello,
yes, list are very slow.
by example, pmpd* object have messages to output list, in order to "list prepend 0" - "list trim" - "send table-foo"
[list trim] is superfluous in this example.
we add few years ago messages to allow direct writing to table.
using list size > 100 or 1000 gives incredible speed difference.
cheers Cyrille
Le 05/11/2012 18:29, Frank Barknecht a écrit :
Hi,
On Mon, Nov 05, 2012 at 08:26:17AM -0800, Jonathan Wilkes wrote:
How many table names total were there in the patch that was overloading the device?
I don't remember anymore, that was in 2009, when the abstraction was
first
posted here on pd-list.
But if you don't believe me, just do some benchmarks on your own and
compare
array access with list filtering.
Ciao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Frank Barknecht fbar@footils.org To: "pd-list@iem.at" pd-list@iem.at Cc: Sent: Monday, November 5, 2012 12:29 PM Subject: Re: [PD] Licensing issues (was rjdj is gone, robotcowboy is coming ...)
Hi,
On Mon, Nov 05, 2012 at 08:26:17AM -0800, Jonathan Wilkes wrote:
How many table names total were there in the patch that was overloading the device?
I don't remember anymore, that was in 2009, when the abstraction was first posted here on pd-list.
But if you don't believe me, just do some benchmarks on your own and compare array access with list filtering.
It makes no difference if the number of table names is around 100. At 1000 your method is certainly faster-- I've just never had a patch with 1000 tables.
-Jonathan
Ciao
Frank Barknecht _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, Nov 05, 2012 at 11:38:00AM -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Frank Barknecht fbar@footils.org
On Mon, Nov 05, 2012 at 08:26:17AM -0800, Jonathan Wilkes wrote:
How many table names total were there in the patch that was overloading the device?
I don't remember anymore, that was in 2009, when the abstraction was first posted here on pd-list.
But if you don't believe me, just do some benchmarks on your own and compare array access with list filtering.
It makes no difference if the number of table names is around 100. At 1000 your method is certainly faster-- I've just never had a patch with 1000 tables.
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.
Frank Barknecht _ ______footils.org__
----- 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]
On Mon, Nov 05, 2012 at 11:38:00AM -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Frank Barknecht fbar@footils.org
On Mon, Nov 05, 2012 at 08:26:17AM -0800, Jonathan Wilkes wrote:
How many table names total were there in the patch that was
overloading
the device?
I don't remember anymore, that was in 2009, when the abstraction
was first
posted here on pd-list.
But if you don't believe me, just do some benchmarks on your own
and compare
array access with list filtering.
It makes no difference if the number of table names is around 100. At 1000
your
method is certainly faster-- I've just never had a patch with 1000
tables.
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
[1] You can certainly split symbols and count their length in Pd vanilla but it ain't pretty.
Ciao
Frank Barknecht _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi,
On Wed, Nov 07, 2012 at 05:45:49PM -0800, Jonathan Wilkes wrote:
[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...
The m_symbolarray-abstraction is a convenience wrapper around
[element symarray symbols] | [get sym name]
which includes some logic to manage the array's content. [makefilename %d-tab] btw. cannot manage anything.
So [makefilename %d-tab] is doing something different. You should not use m_symbolarray to replace it. Only use a symbolic array, where you need it.
Frank Barknecht _ ______footils.org__