I disagree. Your example lists what? 2 more developers? I'm talking about "developers" as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper.
I still maintain that the number of low level developers to overall users (non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring true to me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in Pd-l2ork and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Well, I guess you can call me a "developer," whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned me the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable in any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which allowed us to use a full SVG-based canvas, so I have no doubt we will be able to do this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms and I would argue in turn that will result in faster development. So, if you are really interested in pushing the development of non-vanilla pd I think you should heed some of Jonathan's advice and look for ways how community can work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before that can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote:
I disagree. Your example lists what? 2 more developers? I'm talking about "developers" as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper.
I still maintain that the number of low level developers to overall users (non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring true to me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in Pd-l2ork and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I had to bring up semantics because "developer" means alot of different things to alot of different people.
Also, I didn't want to bring up vanilla versus non-vanilla, just pointing out that the number of people who could help Hans put out a new version of extended is rather low. IMO a languishing extended is bad news for Pd in general as it's the go to distribution for most people using Pd ... but that's probably for another debate. We all work on what's important to us, I'm just sad again to see that the priorities don't seem to match up with a concerted joint effort, at least as compared to my experience working with OpenFrameworks. But of course what's considered a "concerted, joint effort" is also up to interpretation :D
Hopefully we'll have a development meet up at some point soon.
I personally feel guilty seeing things like this come up because I have the *ability* to do it, but I don't have the time when trying to balance life, work, & art. Honestly, this is when I know I'm probably getting in too deep ...
This is why I suggested "graduate students". At this point, up keep and versioning should be supported by some sort of institution, if possible, and by people who could be rotated in and out.
On Sep 23, 2014, at 10:57 AM, Ivica Bukvic ico@vt.edu wrote:
Well, I guess you can call me a "developer," whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned me the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable in any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which allowed us to use a full SVG-based canvas, so I have no doubt we will be able to do this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms and I would argue in turn that will result in faster development. So, if you are really interested in pushing the development of non-vanilla pd I think you should heed some of Jonathan's advice and look for ways how community can work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before that can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico
On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote: I disagree. Your example lists what? 2 more developers? I'm talking about "developers" as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper.
I still maintain that the number of low level developers to overall users (non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring true to me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in Pd-l2ork and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Well, there is a concerted effort on the pd-l2ork side of things. We now technically have 3 devs contributing code regularly to git and 3 additional contributors. On Sep 23, 2014 11:14 AM, "Dan Wilcox" danomatika@gmail.com wrote:
I had to bring up semantics because "developer" means alot of different things to alot of different people.
Also, I didn't want to bring up vanilla versus non-vanilla, just pointing out that the number of people who could help Hans put out a new version of extended is rather low. IMO a languishing extended is bad news for Pd in general as it's the go to distribution for most people using Pd ... but that's probably for another debate. We all work on what's important to us, I'm just sad again to see that the priorities don't seem to match up with a concerted joint effort, at least as compared to my experience working with OpenFrameworks. But of course what's considered a "concerted, joint effort" is also up to interpretation :D
Hopefully we'll have a development meet up at some point soon.
I personally feel guilty seeing things like this come up because I have the *ability* to do it, but I don't have the time when trying to balance life, work, & art. Honestly, this is when I know I'm probably getting in too deep ...
This is why I suggested "graduate students". At this point, up keep and versioning should be supported by some sort of institution, if possible, and by people who could be rotated in and out.
On Sep 23, 2014, at 10:57 AM, Ivica Bukvic ico@vt.edu wrote:
Well, I guess you can call me a "developer," whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned me the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable in any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which allowed us to use a full SVG-based canvas, so I have no doubt we will be able to do this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms and I would argue in turn that will result in faster development. So, if you are really interested in pushing the development of non-vanilla pd I think you should heed some of Jonathan's advice and look for ways how community can work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before that can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote:
I disagree. Your example lists what? 2 more developers? I'm talking about "developers" as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper.
I still maintain that the number of low level developers to overall users (non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring true to me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in Pd-l2ork and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Yes, this is great news. I didn't mean to sound pessimistic earlier, just realistic.
My 2cents, though is that the l2ork website is hard to navigate :D
On Sep 23, 2014, at 11:54 AM, Ivica Bukvic ico@vt.edu wrote:
Well, there is a concerted effort on the pd-l2ork side of things. We now technically have 3 devs contributing code regularly to git and 3 additional contributors.
On Sep 23, 2014 11:14 AM, "Dan Wilcox" danomatika@gmail.com wrote: I had to bring up semantics because "developer" means alot of different things to alot of different people.
Also, I didn't want to bring up vanilla versus non-vanilla, just pointing out that the number of people who could help Hans put out a new version of extended is rather low. IMO a languishing extended is bad news for Pd in general as it's the go to distribution for most people using Pd ... but that's probably for another debate. We all work on what's important to us, I'm just sad again to see that the priorities don't seem to match up with a concerted joint effort, at least as compared to my experience working with OpenFrameworks. But of course what's considered a "concerted, joint effort" is also up to interpretation :D
Hopefully we'll have a development meet up at some point soon.
I personally feel guilty seeing things like this come up because I have the *ability* to do it, but I don't have the time when trying to balance life, work, & art. Honestly, this is when I know I'm probably getting in too deep ...
This is why I suggested "graduate students". At this point, up keep and versioning should be supported by some sort of institution, if possible, and by people who could be rotated in and out.
On Sep 23, 2014, at 10:57 AM, Ivica Bukvic ico@vt.edu wrote:
Well, I guess you can call me a "developer," whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned me the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable in any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which allowed us to use a full SVG-based canvas, so I have no doubt we will be able to do this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms and I would argue in turn that will result in faster development. So, if you are really interested in pushing the development of non-vanilla pd I think you should heed some of Jonathan's advice and look for ways how community can work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before that can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico
On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote: I disagree. Your example lists what? 2 more developers? I'm talking about "developers" as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper.
I still maintain that the number of low level developers to overall users (non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring true to me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in Pd-l2ork and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
True. It is trying to be to many things-- an ensemble and a software portal. On Sep 23, 2014 12:04 PM, "Dan Wilcox" danomatika@gmail.com wrote:
Yes, this is great news. I didn't mean to sound pessimistic earlier, just realistic.
My 2cents, though is that the l2ork website is hard to navigate :D
On Sep 23, 2014, at 11:54 AM, Ivica Bukvic ico@vt.edu wrote:
Well, there is a concerted effort on the pd-l2ork side of things. We now technically have 3 devs contributing code regularly to git and 3 additional contributors. On Sep 23, 2014 11:14 AM, "Dan Wilcox" danomatika@gmail.com wrote:
I had to bring up semantics because "developer" means alot of different things to alot of different people.
Also, I didn't want to bring up vanilla versus non-vanilla, just pointing out that the number of people who could help Hans put out a new version of extended is rather low. IMO a languishing extended is bad news for Pd in general as it's the go to distribution for most people using Pd ... but that's probably for another debate. We all work on what's important to us, I'm just sad again to see that the priorities don't seem to match up with a concerted joint effort, at least as compared to my experience working with OpenFrameworks. But of course what's considered a "concerted, joint effort" is also up to interpretation :D
Hopefully we'll have a development meet up at some point soon.
I personally feel guilty seeing things like this come up because I have the *ability* to do it, but I don't have the time when trying to balance life, work, & art. Honestly, this is when I know I'm probably getting in too deep ...
This is why I suggested "graduate students". At this point, up keep and versioning should be supported by some sort of institution, if possible, and by people who could be rotated in and out.
On Sep 23, 2014, at 10:57 AM, Ivica Bukvic ico@vt.edu wrote:
Well, I guess you can call me a "developer," whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned me the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable in any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which allowed us to use a full SVG-based canvas, so I have no doubt we will be able to do this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms and I would argue in turn that will result in faster development. So, if you are really interested in pushing the development of non-vanilla pd I think you should heed some of Jonathan's advice and look for ways how community can work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before that can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote:
I disagree. Your example lists what? 2 more developers? I'm talking about "developers" as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper.
I still maintain that the number of low level developers to overall users (non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring true to me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in Pd-l2ork and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Maybe the software portal could be a subdomain or integrated on the pure-data.info site along with vanilla & extended.
On Sep 23, 2014, at 12:18 PM, Ivica Bukvic ico@vt.edu wrote:
True. It is trying to be to many things-- an ensemble and a software portal.
On Sep 23, 2014 12:04 PM, "Dan Wilcox" danomatika@gmail.com wrote: Yes, this is great news. I didn't mean to sound pessimistic earlier, just realistic.
My 2cents, though is that the l2ork website is hard to navigate :D
On Sep 23, 2014, at 11:54 AM, Ivica Bukvic ico@vt.edu wrote:
Well, there is a concerted effort on the pd-l2ork side of things. We now technically have 3 devs contributing code regularly to git and 3 additional contributors.
On Sep 23, 2014 11:14 AM, "Dan Wilcox" danomatika@gmail.com wrote: I had to bring up semantics because "developer" means alot of different things to alot of different people.
Also, I didn't want to bring up vanilla versus non-vanilla, just pointing out that the number of people who could help Hans put out a new version of extended is rather low. IMO a languishing extended is bad news for Pd in general as it's the go to distribution for most people using Pd ... but that's probably for another debate. We all work on what's important to us, I'm just sad again to see that the priorities don't seem to match up with a concerted joint effort, at least as compared to my experience working with OpenFrameworks. But of course what's considered a "concerted, joint effort" is also up to interpretation :D
Hopefully we'll have a development meet up at some point soon.
I personally feel guilty seeing things like this come up because I have the *ability* to do it, but I don't have the time when trying to balance life, work, & art. Honestly, this is when I know I'm probably getting in too deep ...
This is why I suggested "graduate students". At this point, up keep and versioning should be supported by some sort of institution, if possible, and by people who could be rotated in and out.
On Sep 23, 2014, at 10:57 AM, Ivica Bukvic ico@vt.edu wrote:
Well, I guess you can call me a "developer," whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned me the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable in any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which allowed us to use a full SVG-based canvas, so I have no doubt we will be able to do this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms and I would argue in turn that will result in faster development. So, if you are really interested in pushing the development of non-vanilla pd I think you should heed some of Jonathan's advice and look for ways how community can work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before that can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico
On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote: I disagree. Your example lists what? 2 more developers? I'm talking about "developers" as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper.
I still maintain that the number of low level developers to overall users (non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring true to me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in Pd-l2ork and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
It is already linked from that site. On Sep 23, 2014 12:27 PM, "Dan Wilcox" danomatika@gmail.com wrote:
Maybe the software portal could be a subdomain or integrated on the pure-data.info site along with vanilla & extended.
On Sep 23, 2014, at 12:18 PM, Ivica Bukvic ico@vt.edu wrote:
True. It is trying to be to many things-- an ensemble and a software portal. On Sep 23, 2014 12:04 PM, "Dan Wilcox" danomatika@gmail.com wrote:
Yes, this is great news. I didn't mean to sound pessimistic earlier, just realistic.
My 2cents, though is that the l2ork website is hard to navigate :D
On Sep 23, 2014, at 11:54 AM, Ivica Bukvic ico@vt.edu wrote:
Well, there is a concerted effort on the pd-l2ork side of things. We now technically have 3 devs contributing code regularly to git and 3 additional contributors. On Sep 23, 2014 11:14 AM, "Dan Wilcox" danomatika@gmail.com wrote:
I had to bring up semantics because "developer" means alot of different things to alot of different people.
Also, I didn't want to bring up vanilla versus non-vanilla, just pointing out that the number of people who could help Hans put out a new version of extended is rather low. IMO a languishing extended is bad news for Pd in general as it's the go to distribution for most people using Pd ... but that's probably for another debate. We all work on what's important to us, I'm just sad again to see that the priorities don't seem to match up with a concerted joint effort, at least as compared to my experience working with OpenFrameworks. But of course what's considered a "concerted, joint effort" is also up to interpretation :D
Hopefully we'll have a development meet up at some point soon.
I personally feel guilty seeing things like this come up because I have the *ability* to do it, but I don't have the time when trying to balance life, work, & art. Honestly, this is when I know I'm probably getting in too deep ...
This is why I suggested "graduate students". At this point, up keep and versioning should be supported by some sort of institution, if possible, and by people who could be rotated in and out.
On Sep 23, 2014, at 10:57 AM, Ivica Bukvic ico@vt.edu wrote:
Well, I guess you can call me a "developer," whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned me the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable in any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which allowed us to use a full SVG-based canvas, so I have no doubt we will be able to do this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms and I would argue in turn that will result in faster development. So, if you are really interested in pushing the development of non-vanilla pd I think you should heed some of Jonathan's advice and look for ways how community can work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before that can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote:
I disagree. Your example lists what? 2 more developers? I'm talking about "developers" as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper.
I still maintain that the number of low level developers to overall users (non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring true to me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in Pd-l2ork and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Yeah, sure. I think I meant more that you could utilize the pure-data.info site directly for all the pd-l2ork build/install info and download hosting and keep the current l2ork site for the ensemble.
Anyway, just an idea :D In any case, pd-L2ork IMO needs a space to it's own, especially if you expand to more platforms & build/install info.
My original criticism was more that there isn't a pd-l2ork section, it's listed under "Join the L2orkmania" -> "Software".
On Sep 23, 2014, at 1:22 PM, Ivica Bukvic ico@vt.edu wrote:
It is already linked from that site.
On Sep 23, 2014 12:27 PM, "Dan Wilcox" danomatika@gmail.com wrote: Maybe the software portal could be a subdomain or integrated on the pure-data.info site along with vanilla & extended.
On Sep 23, 2014, at 12:18 PM, Ivica Bukvic ico@vt.edu wrote:
True. It is trying to be to many things-- an ensemble and a software portal.
On Sep 23, 2014 12:04 PM, "Dan Wilcox" danomatika@gmail.com wrote: Yes, this is great news. I didn't mean to sound pessimistic earlier, just realistic.
My 2cents, though is that the l2ork website is hard to navigate :D
On Sep 23, 2014, at 11:54 AM, Ivica Bukvic ico@vt.edu wrote:
Well, there is a concerted effort on the pd-l2ork side of things. We now technically have 3 devs contributing code regularly to git and 3 additional contributors.
On Sep 23, 2014 11:14 AM, "Dan Wilcox" danomatika@gmail.com wrote: I had to bring up semantics because "developer" means alot of different things to alot of different people.
Also, I didn't want to bring up vanilla versus non-vanilla, just pointing out that the number of people who could help Hans put out a new version of extended is rather low. IMO a languishing extended is bad news for Pd in general as it's the go to distribution for most people using Pd ... but that's probably for another debate. We all work on what's important to us, I'm just sad again to see that the priorities don't seem to match up with a concerted joint effort, at least as compared to my experience working with OpenFrameworks. But of course what's considered a "concerted, joint effort" is also up to interpretation :D
Hopefully we'll have a development meet up at some point soon.
I personally feel guilty seeing things like this come up because I have the *ability* to do it, but I don't have the time when trying to balance life, work, & art. Honestly, this is when I know I'm probably getting in too deep ...
This is why I suggested "graduate students". At this point, up keep and versioning should be supported by some sort of institution, if possible, and by people who could be rotated in and out.
On Sep 23, 2014, at 10:57 AM, Ivica Bukvic ico@vt.edu wrote:
Well, I guess you can call me a "developer," whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned me the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable in any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which allowed us to use a full SVG-based canvas, so I have no doubt we will be able to do this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms and I would argue in turn that will result in faster development. So, if you are really interested in pushing the development of non-vanilla pd I think you should heed some of Jonathan's advice and look for ways how community can work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before that can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico
On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote: I disagree. Your example lists what? 2 more developers? I'm talking about "developers" as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper.
I still maintain that the number of low level developers to overall users (non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring true to me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in Pd-l2ork and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Both valid points and I fully agree with you. FWIW, it's kind of hard maintaining all that and also developing. If only we could get some help on this, that will help us move the development forward faster ;-) On Sep 23, 2014 1:28 PM, "Dan Wilcox" danomatika@gmail.com wrote:
Yeah, sure. I think I meant more that you could utilize the pure-data.info site directly for all the pd-l2ork build/install info and download hosting and keep the current l2ork site for the ensemble.
Anyway, just an idea :D In any case, pd-L2ork IMO needs a space to it's own, especially if you expand to more platforms & build/install info.
My original criticism was more that there isn't a pd-l2ork section, it's listed under "Join the L2orkmania" -> "Software".
On Sep 23, 2014, at 1:22 PM, Ivica Bukvic ico@vt.edu wrote:
It is already linked from that site. On Sep 23, 2014 12:27 PM, "Dan Wilcox" danomatika@gmail.com wrote:
Maybe the software portal could be a subdomain or integrated on the pure-data.info site along with vanilla & extended.
On Sep 23, 2014, at 12:18 PM, Ivica Bukvic ico@vt.edu wrote:
True. It is trying to be to many things-- an ensemble and a software portal. On Sep 23, 2014 12:04 PM, "Dan Wilcox" danomatika@gmail.com wrote:
Yes, this is great news. I didn't mean to sound pessimistic earlier, just realistic.
My 2cents, though is that the l2ork website is hard to navigate :D
On Sep 23, 2014, at 11:54 AM, Ivica Bukvic ico@vt.edu wrote:
Well, there is a concerted effort on the pd-l2ork side of things. We now technically have 3 devs contributing code regularly to git and 3 additional contributors. On Sep 23, 2014 11:14 AM, "Dan Wilcox" danomatika@gmail.com wrote:
I had to bring up semantics because "developer" means alot of different things to alot of different people.
Also, I didn't want to bring up vanilla versus non-vanilla, just pointing out that the number of people who could help Hans put out a new version of extended is rather low. IMO a languishing extended is bad news for Pd in general as it's the go to distribution for most people using Pd ... but that's probably for another debate. We all work on what's important to us, I'm just sad again to see that the priorities don't seem to match up with a concerted joint effort, at least as compared to my experience working with OpenFrameworks. But of course what's considered a "concerted, joint effort" is also up to interpretation :D
Hopefully we'll have a development meet up at some point soon.
I personally feel guilty seeing things like this come up because I have the *ability* to do it, but I don't have the time when trying to balance life, work, & art. Honestly, this is when I know I'm probably getting in too deep ...
This is why I suggested "graduate students". At this point, up keep and versioning should be supported by some sort of institution, if possible, and by people who could be rotated in and out.
On Sep 23, 2014, at 10:57 AM, Ivica Bukvic ico@vt.edu wrote:
Well, I guess you can call me a "developer," whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned me the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable in any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which allowed us to use a full SVG-based canvas, so I have no doubt we will be able to do this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms and I would argue in turn that will result in faster development. So, if you are really interested in pushing the development of non-vanilla pd I think you should heed some of Jonathan's advice and look for ways how community can work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before that can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote:
I disagree. Your example lists what? 2 more developers? I'm talking about "developers" as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper.
I still maintain that the number of low level developers to overall users (non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring true to me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in Pd-l2ork and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
It is excellent news that pd-l2ork may soon be available outside of Linux, Ivica. Cheers, and best of luck on this tack.
Phil
On 9/23/14, 7:57 AM, Ivica Bukvic wrote:
Well, I guess you can call me a "developer," whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned me the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable in any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which allowed us to use a full SVG-based canvas, so I have no doubt we will be able to do this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms and I would argue in turn that will result in faster development. So, if you are really interested in pushing the development of non-vanilla pd I think you should heed some of Jonathan's advice and look for ways how community can work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before that can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico
On Sep 23, 2014 9:21 AM, "Dan Wilcox" <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
I disagree. Your example lists what? 2 more developers? I'm talking about "developers" as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper. I still maintain that the number of low level developers to overall users (non-developers) is relatively low. On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> wrote:However, your description of the user/developer ratio doesn't ring true to me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in Pd-l2ork and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.-------- Dan Wilcox @danomatika danomatika.com <http://danomatika.com> robotcowboy.com <http://robotcowboy.com> _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You've done a lot of good work in pd-l2ork, but you also broke binary compatibility of libraries for no good reason. You could have implemented that feature in a way that preserved binary compatibility of libraries. You still can, and you should.
.hc
Ivica Bukvic wrote:
Well, I guess you can call me a "developer," whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned me the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable in any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which allowed us to use a full SVG-based canvas, so I have no doubt we will be able to do this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms and I would argue in turn that will result in faster development. So, if you are really interested in pushing the development of non-vanilla pd I think you should heed some of Jonathan's advice and look for ways how community can work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before that can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote:
I disagree. Your example lists what? 2 more developers? I'm talking about "developers" as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper.
I still maintain that the number of low level developers to overall users (non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring true to me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in Pd-l2ork and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
N�n�r����)em�h�yhiם�w^��
Why is this such a problem? I did not break source compatibility (well, some of it will happen for gui objects as a result of porting gui to qt) and for every extended release you recompile new binaries anyhow and so does pd-l2ork, except that pd-l2ork goes even one step further offering a monolithic release. Besides, pd is not java and there is no binary compatibility across different platforms (except maybe libpd realized in java, but that is not what we are talking about here). Under such circumstances, I see binary compatibility strictly as a means of maintaining status quo. As a final thought, consider that a lot of good work (as you called it, and I thank you for your kind words) would not have been possible without breaking binary compatibility which, given the aforesaid circumstances, is a non-issue to begin with.
Best,
Ico On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner" hans@at.or.at wrote:
You've done a lot of good work in pd-l2ork, but you also broke binary compatibility of libraries for no good reason. You could have implemented that feature in a way that preserved binary compatibility of libraries. You still can, and you should.
.hc
Ivica Bukvic wrote:
Well, I guess you can call me a "developer," whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned
me
the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable
in
any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was
initially
a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which
allowed
us to use a full SVG-based canvas, so I have no doubt we will be able to
do
this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms
and I
would argue in turn that will result in faster development. So, if you
are
really interested in pushing the development of non-vanilla pd I think
you
should heed some of Jonathan's advice and look for ways how community can work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before
that
can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote:
I disagree. Your example lists what? 2 more developers? I'm talking
about
"developers" as in people working the C code, build scripts, tcl/tk etc
aka
people who could, theoretically, help push out a new Pd-extended
release.
True, we have plenty of people working on externals, but this is a
problem
for someone who can go deeper.
I still maintain that the number of low level developers to overall
users
(non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring true
to
me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in
Pd-l2ork
and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
N �n�r����)em�h�yhiם�w^��
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
For libraries, there is binary compatibility between pd vanilla, extended, desiredata, and vibrez. desiredata made much larger changes to the GUI-side than pd-l2ork.
.hc
Ivica Bukvic wrote:
Why is this such a problem? I did not break source compatibility (well, some of it will happen for gui objects as a result of porting gui to qt) and for every extended release you recompile new binaries anyhow and so does pd-l2ork, except that pd-l2ork goes even one step further offering a monolithic release. Besides, pd is not java and there is no binary compatibility across different platforms (except maybe libpd realized in java, but that is not what we are talking about here). Under such circumstances, I see binary compatibility strictly as a means of maintaining status quo. As a final thought, consider that a lot of good work (as you called it, and I thank you for your kind words) would not have been possible without breaking binary compatibility which, given the aforesaid circumstances, is a non-issue to begin with.
Best,
Ico On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner" hans@at.or.at wrote:
You've done a lot of good work in pd-l2ork, but you also broke binary compatibility of libraries for no good reason. You could have implemented that feature in a way that preserved binary compatibility of libraries. You still can, and you should.
.hc
Ivica Bukvic wrote:
Well, I guess you can call me a "developer," whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned
me
the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable
in
any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was
initially
a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which
allowed
us to use a full SVG-based canvas, so I have no doubt we will be able to
do
this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms
and I
would argue in turn that will result in faster development. So, if you
are
really interested in pushing the development of non-vanilla pd I think
you
should heed some of Jonathan's advice and look for ways how community can work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before
that
can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote:
I disagree. Your example lists what? 2 more developers? I'm talking
about
"developers" as in people working the C code, build scripts, tcl/tk etc
aka
people who could, theoretically, help push out a new Pd-extended
release.
True, we have plenty of people working on externals, but this is a
problem
for someone who can go deeper.
I still maintain that the number of low level developers to overall
users
(non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring true
to
me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in
Pd-l2ork
and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
N �n�r����)em�h�yhiם�w^��
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Based on what metrics? On Sep 25, 2014 11:05 AM, "Hans-Christoph Steiner" hans@at.or.at wrote:
For libraries, there is binary compatibility between pd vanilla, extended, desiredata, and vibrez. desiredata made much larger changes to the GUI-side than pd-l2ork.
.hc
Ivica Bukvic wrote:
Why is this such a problem? I did not break source compatibility (well, some of it will happen for gui objects as a result of porting gui to qt) and for every extended release you recompile new binaries anyhow and so does pd-l2ork, except that pd-l2ork goes even one step further offering a monolithic release. Besides, pd is not java and there is no binary compatibility across different platforms (except maybe libpd realized in java, but that is not what we are talking about here). Under such circumstances, I see binary compatibility strictly as a means of maintaining status quo. As a final thought, consider that a lot of good work (as you called it, and I thank you for your kind words) would not
have
been possible without breaking binary compatibility which, given the aforesaid circumstances, is a non-issue to begin with.
Best,
Ico On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner" hans@at.or.at
wrote:
You've done a lot of good work in pd-l2ork, but you also broke binary compatibility of libraries for no good reason. You could have
implemented
that feature in a way that preserved binary compatibility of libraries. You still can, and you should.
.hc
Ivica Bukvic wrote:
Well, I guess you can call me a "developer," whatever that means--I
don't
care that much about titles. Yet, I would argue that as far as low
level
stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned
me
the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would
also
argue it is essential and offers a slew of features that are
unavailable
in
any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was
initially
a conscious decision to allow for faster development while addressing
the
lack of manpower. But that is about to change once we complete port to
Qt
library. We already transitioned to Tkpath quite a while ago which
allowed
us to use a full SVG-based canvas, so I have no doubt we will be able
to
do
this again. Once this is done, we won't have to circumnavigate
exceptions
Tk library requires in order to be compliant with different platforms
and I
would argue in turn that will result in faster development. So, if you
are
really interested in pushing the development of non-vanilla pd I think
you
should heed some of Jonathan's advice and look for ways how community
can
work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before
that
can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses
on
more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote:
I disagree. Your example lists what? 2 more developers? I'm talking
about
"developers" as in people working the C code, build scripts, tcl/tk
etc
aka
people who could, theoretically, help push out a new Pd-extended
release.
True, we have plenty of people working on externals, but this is a
problem
for someone who can go deeper.
I still maintain that the number of low level developers to overall
users
(non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring
true
to
me. There's actually a surplus of developers and development
energy-- I
count two implementations of presets in the last year or two (in
Pd-l2ork
and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
N �n�r����)em�h�yhiם�w^��
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can take an external compiled for the same OS/arch and it loads and works on all of them.
.hc
Ivica Bukvic wrote:
Based on what metrics? On Sep 25, 2014 11:05 AM, "Hans-Christoph Steiner" hans@at.or.at wrote:
For libraries, there is binary compatibility between pd vanilla, extended, desiredata, and vibrez. desiredata made much larger changes to the GUI-side than pd-l2ork.
.hc
Ivica Bukvic wrote:
Why is this such a problem? I did not break source compatibility (well, some of it will happen for gui objects as a result of porting gui to qt) and for every extended release you recompile new binaries anyhow and so does pd-l2ork, except that pd-l2ork goes even one step further offering a monolithic release. Besides, pd is not java and there is no binary compatibility across different platforms (except maybe libpd realized in java, but that is not what we are talking about here). Under such circumstances, I see binary compatibility strictly as a means of maintaining status quo. As a final thought, consider that a lot of good work (as you called it, and I thank you for your kind words) would not
have
been possible without breaking binary compatibility which, given the aforesaid circumstances, is a non-issue to begin with.
Best,
Ico On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner" hans@at.or.at
wrote:
You've done a lot of good work in pd-l2ork, but you also broke binary compatibility of libraries for no good reason. You could have
implemented
that feature in a way that preserved binary compatibility of libraries. You still can, and you should.
.hc
Ivica Bukvic wrote:
Well, I guess you can call me a "developer," whatever that means--I
don't
care that much about titles. Yet, I would argue that as far as low
level
stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned
me
the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would
also
argue it is essential and offers a slew of features that are
unavailable
in
any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was
initially
a conscious decision to allow for faster development while addressing
the
lack of manpower. But that is about to change once we complete port to
Qt
library. We already transitioned to Tkpath quite a while ago which
allowed
us to use a full SVG-based canvas, so I have no doubt we will be able
to
do
this again. Once this is done, we won't have to circumnavigate
exceptions
Tk library requires in order to be compliant with different platforms
and I
would argue in turn that will result in faster development. So, if you
are
really interested in pushing the development of non-vanilla pd I think
you
should heed some of Jonathan's advice and look for ways how community
can
work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before
that
can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses
on
more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote:
I disagree. Your example lists what? 2 more developers? I'm talking
about
"developers" as in people working the C code, build scripts, tcl/tk
etc
aka
people who could, theoretically, help push out a new Pd-extended
release.
True, we have plenty of people working on externals, but this is a
problem
for someone who can go deeper.
I still maintain that the number of low level developers to overall
users
(non-developers) is relatively low.
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring
true
to
me. There's actually a surplus of developers and development
energy-- I
count two implementations of presets in the last year or two (in
Pd-l2ork
and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
N �n�r����)em�h�yhiם�w^��
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
...As strange as it may sound I must admit I've missed our broken conversations/banter. Welcome back, Hans!
Alas, this time I will have to bow out--so many things to do, so little time. Hope you'll understand.
Best,
Ico On Sep 25, 2014 11:08 AM, "Hans-Christoph Steiner" hans@at.or.at wrote:
You can take an external compiled for the same OS/arch and it loads and works on all of them.
.hc
Ivica Bukvic wrote:
Based on what metrics? On Sep 25, 2014 11:05 AM, "Hans-Christoph Steiner" hans@at.or.at
wrote:
For libraries, there is binary compatibility between pd vanilla,
extended,
desiredata, and vibrez. desiredata made much larger changes to the GUI-side than pd-l2ork.
.hc
Ivica Bukvic wrote:
Why is this such a problem? I did not break source compatibility (well, some of it will happen for gui objects as a result of porting gui to
qt)
and for every extended release you recompile new binaries anyhow and so does pd-l2ork, except that pd-l2ork goes even one step further
offering a
monolithic release. Besides, pd is not java and there is no binary compatibility across different platforms (except maybe libpd realized
in
java, but that is not what we are talking about here). Under such circumstances, I see binary compatibility strictly as a means of maintaining status quo. As a final thought, consider that a lot of good work (as you called it, and I thank you for your kind words) would not
have
been possible without breaking binary compatibility which, given the aforesaid circumstances, is a non-issue to begin with.
Best,
Ico On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner" hans@at.or.at
wrote:
You've done a lot of good work in pd-l2ork, but you also broke binary compatibility of libraries for no good reason. You could have
implemented
that feature in a way that preserved binary compatibility of
libraries.
You still can, and you should.
.hc
Ivica Bukvic wrote:
Well, I guess you can call me a "developer," whatever that means--I
don't
care that much about titles. Yet, I would argue that as far as low
level
stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has
earned
me
the title in quotations delves so deep into the core that currently
it
cannot be implemented in either vanilla or extended without
significant
changes even though it retains full backwards compatibility. I would
also
argue it is essential and offers a slew of features that are
unavailable
in
any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was
initially
a conscious decision to allow for faster development while addressing
the
lack of manpower. But that is about to change once we complete port
to
Qt
library. We already transitioned to Tkpath quite a while ago which
allowed
us to use a full SVG-based canvas, so I have no doubt we will be able
to
do
this again. Once this is done, we won't have to circumnavigate
exceptions
Tk library requires in order to be compliant with different platforms
and I
would argue in turn that will result in faster development. So, if
you
are
really interested in pushing the development of non-vanilla pd I
think
you
should heed some of Jonathan's advice and look for ways how community
can
work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before
that
can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it
focuses
on
more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of
iemgui
objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote:
> I disagree. Your example lists what? 2 more developers? I'm talking
about
> "developers" as in people working the C code, build scripts, tcl/tk
etc
aka
> people who could, theoretically, help push out a new Pd-extended
release.
> True, we have plenty of people working on externals, but this is a
problem
> for someone who can go deeper. > > I still maintain that the number of low level developers to overall
users
> (non-developers) is relatively low. > > On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote: > > However, your description of the user/developer ratio doesn't ring
true
to
> me. There's actually a surplus of developers and development
energy-- I
> count two implementations of presets in the last year or two (in
Pd-l2ork
> and the Chocolate et Coffee lib) which are in addition to however
many
> already exist on svn and the Pd forum. > > > -------- > Dan Wilcox > @danomatika > danomatika.com > robotcowboy.com > > > > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > N �n�r����)em�h�yhiם�w^��
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Um... have you actually read the source for DesireData?
If someone wants to write me up a nice, concise, friendly non-sarcastic spec about how to change Pd-l2ork's code so that it can be binary compatible with the same features it currently has, I'll be happy to try implementing it.
-Jonathan
On Thursday, September 25, 2014 12:04 PM, Ivica Bukvic ico@vt.edu wrote:
...As strange as it may sound I must admit I've missed our broken conversations/banter. Welcome back, Hans! Alas, this time I will have to bow out--so many things to do, so little time. Hope you'll understand. Best, Ico On Sep 25, 2014 11:08 AM, "Hans-Christoph Steiner" hans@at.or.at wrote:
You can take an external compiled for the same OS/arch and it loads and works on all of them.
.hc
Ivica Bukvic wrote:
Based on what metrics? On Sep 25, 2014 11:05 AM, "Hans-Christoph Steiner" hans@at.or.at wrote:
For libraries, there is binary compatibility between pd vanilla, extended, desiredata, and vibrez. desiredata made much larger changes to the GUI-side than pd-l2ork.
.hc
Ivica Bukvic wrote:
Why is this such a problem? I did not break source compatibility (well, some of it will happen for gui objects as a result of porting gui to qt) and for every extended release you recompile new binaries anyhow and so does pd-l2ork, except that pd-l2ork goes even one step further offering a monolithic release. Besides, pd is not java and there is no binary compatibility across different platforms (except maybe libpd realized in java, but that is not what we are talking about here). Under such circumstances, I see binary compatibility strictly as a means of maintaining status quo. As a final thought, consider that a lot of good work (as you called it, and I thank you for your kind words) would not
have
been possible without breaking binary compatibility which, given the aforesaid circumstances, is a non-issue to begin with.
Best,
Ico On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner" hans@at.or.at
wrote:
You've done a lot of good work in pd-l2ork, but you also broke binary compatibility of libraries for no good reason. You could have
implemented
that feature in a way that preserved binary compatibility of libraries. You still can, and you should.
.hc
Ivica Bukvic wrote:
Well, I guess you can call me a "developer," whatever that means--I
don't
care that much about titles. Yet, I would argue that as far as low
level
stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned
me
the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would
also
argue it is essential and offers a slew of features that are
unavailable
in
any other implementation of presets.
Pd-l2ork's greatest deterrent is exclusivity to Linux, which was
initially
a conscious decision to allow for faster development while addressing
the
lack of manpower. But that is about to change once we complete port to
Qt
library. We already transitioned to Tkpath quite a while ago which
allowed
us to use a full SVG-based canvas, so I have no doubt we will be able
to
do
this again. Once this is done, we won't have to circumnavigate
exceptions
Tk library requires in order to be compliant with different platforms
and I
would argue in turn that will result in faster development. So, if you
are
really interested in pushing the development of non-vanilla pd I think
you
should heed some of Jonathan's advice and look for ways how community
can
work together in combining the "best of" and engaging developers and "developers" alike who have shown dedication to the cause. But before
that
can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses
on
more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate.
Best,
Ico On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote:
> I disagree. Your example lists what? 2 more developers? I'm talking
about
> "developers" as in people working the C code, build scripts, tcl/tk
etc
aka
> people who could, theoretically, help push out a new Pd-extended
release.
> True, we have plenty of people working on externals, but this is a
problem
> for someone who can go deeper. > > I still maintain that the number of low level developers to overall
users
> (non-developers) is relatively low. > > On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote: > > However, your description of the user/developer ratio doesn't ring
true
to
> me. There's actually a surplus of developers and development
energy-- I
> count two implementations of presets in the last year or two (in
Pd-l2ork
> and the Chocolate et Coffee lib) which are in addition to however many > already exist on svn and the Pd forum. > > > -------- > Dan Wilcox > @danomatika > danomatika.com > robotcowboy.com > > > > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > N �n�r����)em�h�yhiם�w^��
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 09/25/2014 12:54 PM, Jonathan Wilkes via Pd-list wrote:
Um... have you actually read the source for DesireData?
Just to clarify this-- from m_pd.h desiredata 2010.01.05:
struct _symbol { char *name; /* the const string that represents this symbol */ t_pd *thing; /* pointer to the target of a receive-symbol or to the bindlist of several targets */ struct _symbol *next; /* brochette of all symbols (only for permanent symbols) */ size_t refcount; /* refcount<0 means that the symbol is permanent */ size_t n; /* size of name (support for NUL characters) */ #ifdef PD_PLUSPLUS_FACE bool operator == (const char *s) const {return strcmp(this->name,s)==0;} bool operator != (const char *s) const {return strcmp(this->name,s);} #endif };
Desiredata's t_symbol has extra members that aren't in Pd Vanilla's t_symbol struct. If there is any external out there that uses an array of symbols, then there will be problems due to this binary compatibility.
I have no idea if this is representative of the rest of DesireData or if
it is an outlier. I only know it is a form of binary incompatibility.
Whether it is a significant form is up for discussion, but that requires
a more sophisticated discussion than "Pd-l2ork = binary_incompatible = bad".
-Jonathan
If someone wants to write me up a nice, concise, friendly non-sarcastic spec about how to change Pd-l2ork's code so that it can be binary compatible with the same features it currently has, I'll be happy to try implementing it.
-Jonathan
On Thursday, September 25, 2014 12:04 PM, Ivica Bukvic ico@vt.edu wrote:
...As strange as it may sound I must admit I've missed our broken conversations/banter. Welcome back, Hans! Alas, this time I will have to bow out--so many things to do, so little time. Hope you'll understand. Best, Ico On Sep 25, 2014 11:08 AM, "Hans-Christoph Steiner" <hans@at.or.at mailto:hans@at.or.at> wrote:
You can take an external compiled for the same OS/arch and it loads and works on all of them. .hc Ivica Bukvic wrote: > Based on what metrics? > On Sep 25, 2014 11:05 AM, "Hans-Christoph Steiner" <hans@at.or.at <mailto:hans@at.or.at>> wrote: > >> >> For libraries, there is binary compatibility between pd vanilla, extended, >> desiredata, and vibrez. desiredata made much larger changes to the >> GUI-side >> than pd-l2ork. >> >> .hc >> >> Ivica Bukvic wrote: >>> Why is this such a problem? I did not break source compatibility (well, >>> some of it will happen for gui objects as a result of porting gui to qt) >>> and for every extended release you recompile new binaries anyhow and so >>> does pd-l2ork, except that pd-l2ork goes even one step further offering a >>> monolithic release. Besides, pd is not java and there is no binary >>> compatibility across different platforms (except maybe libpd realized in >>> java, but that is not what we are talking about here). Under such >>> circumstances, I see binary compatibility strictly as a means of >>> maintaining status quo. As a final thought, consider that a lot of good >>> work (as you called it, and I thank you for your kind words) would not >> have >>> been possible without breaking binary compatibility which, given the >>> aforesaid circumstances, is a non-issue to begin with. >>> >>> Best, >>> >>> Ico >>> On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner" <hans@at.or.at <mailto:hans@at.or.at>> >> wrote: >>> >>>> >>>> You've done a lot of good work in pd-l2ork, but you also broke binary >>>> compatibility of libraries for no good reason. You could have >> implemented >>>> that feature in a way that preserved binary compatibility of libraries. >>>> You >>>> still can, and you should. >>>> >>>> .hc >>>> >>>> Ivica Bukvic wrote: >>>>> Well, I guess you can call me a "developer," whatever that means--I >> don't >>>>> care that much about titles. Yet, I would argue that as far as low >> level >>>>> stuff is concerned in recent years pd-l2ork has certainly pushed the >>>>> envelope in terms of core development. Even the feature that has earned >>>> me >>>>> the title in quotations delves so deep into the core that currently it >>>>> cannot be implemented in either vanilla or extended without significant >>>>> changes even though it retains full backwards compatibility. I would >> also >>>>> argue it is essential and offers a slew of features that are >> unavailable >>>> in >>>>> any other implementation of presets. >>>>> >>>>> Pd-l2ork's greatest deterrent is exclusivity to Linux, which was >>>> initially >>>>> a conscious decision to allow for faster development while addressing >> the >>>>> lack of manpower. But that is about to change once we complete port to >> Qt >>>>> library. We already transitioned to Tkpath quite a while ago which >>>> allowed >>>>> us to use a full SVG-based canvas, so I have no doubt we will be able >> to >>>> do >>>>> this again. Once this is done, we won't have to circumnavigate >> exceptions >>>>> Tk library requires in order to be compliant with different platforms >>>> and I >>>>> would argue in turn that will result in faster development. So, if you >>>> are >>>>> really interested in pushing the development of non-vanilla pd I think >>>> you >>>>> should heed some of Jonathan's advice and look for ways how community >> can >>>>> work together in combining the "best of" and engaging developers and >>>>> "developers" alike who have shown dedication to the cause. But before >>>> that >>>>> can be accomplished, the community should consider agreeing on design >>>>> choices. For instance, pd-l2ork came into existence because it focuses >> on >>>>> more nimble development at the expense of potential loss of backwards >>>>> compatibility (even though after 4 years of development the only >>>>> incompatibility we infatuated is correcting buggy positioning of iemgui >>>>> objects, which is cosmetic in nature) because a good chunk of that >>>>> compatibility stems from buggy implementations that stuck around long >>>>> enough that they became a part of the standard (e.g. iemgui's buggy >>>>> positioning of objects that are arbitrarily offset from their x and y >>>>> positions, as reported by the pd script), which is unfortunate. >>>>> >>>>> Best, >>>>> >>>>> Ico >>>>> On Sep 23, 2014 9:21 AM, "Dan Wilcox" <danomatika@gmail.com <mailto:danomatika@gmail.com>> wrote: >>>>> >>>>>> I disagree. Your example lists what? 2 more developers? I'm talking >>>> about >>>>>> "developers" as in people working the C code, build scripts, tcl/tk >> etc >>>> aka >>>>>> people who could, theoretically, help push out a new Pd-extended >>>> release. >>>>>> True, we have plenty of people working on externals, but this is a >>>> problem >>>>>> for someone who can go deeper. >>>>>> >>>>>> I still maintain that the number of low level developers to overall >>>> users >>>>>> (non-developers) is relatively low. >>>>>> >>>>>> On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> wrote: >>>>>> >>>>>> However, your description of the user/developer ratio doesn't ring >> true >>>> to >>>>>> me. There's actually a surplus of developers and development >> energy-- I >>>>>> count two implementations of presets in the last year or two (in >>>> Pd-l2ork >>>>>> and the Chocolate et Coffee lib) which are in addition to however many >>>>>> already exist on svn and the Pd forum. >>>>>> >>>>>> >>>>>> -------- >>>>>> Dan Wilcox >>>>>> @danomatika >>>>>> danomatika.com <http://danomatika.com/> >>>>>> robotcowboy.com <http://robotcowboy.com/> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list >>>>>> UNSUBSCRIBE and account-management -> >>>>>> http://lists.puredata.info/listinfo/pd-list >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> N �n�r����)em�h�yhiם�w^�� >>>> >>>> _______________________________________________ >>>> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >>
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 09/26/2014 04:22 AM, Jonathan Wilkes via Pd-list wrote:
On 09/25/2014 12:54 PM, Jonathan Wilkes via Pd-list wrote:
Um... have you actually read the source for DesireData?
Just to clarify this-- from m_pd.h desiredata 2010.01.05:
struct _symbol { char *name; /* the const string that represents this symbol */ t_pd *thing; /* pointer to the target of a receive-symbol or to the bindlist of several targets */ struct _symbol *next; /* brochette of all symbols (only for permanent symbols) */ size_t refcount; /* refcount<0 means that the symbol is permanent */ size_t n; /* size of name (support for NUL characters) */ #ifdef PD_PLUSPLUS_FACE bool operator == (const char *s) const {return strcmp(this->name,s)==0;} bool operator != (const char *s) const {return strcmp(this->name,s);} #endif };
Desiredata's t_symbol has extra members that aren't in Pd Vanilla's t_symbol struct. If there is any external out there that uses an array of symbols, then there will be problems due to this binary compatibility.
actually, i have yet to come across a *single* external that uses (t_symbol) rather than (t_symbol*) - or, if you insist on arrays (t_symbol[]) rather than (t_symbol*[]).
i don't see how this breaks binary compatibility - unless of course you *use* these members¹...
fmgdsr IOhannes
¹ that is, pass them around, in a "dosomething(s->foo)" sort of way (and i don't know how to do this with an overloaded operator). since the additional members are actually methods with an implementation in the header file, i guess that any compiler would just inline them when it comes to using them (in an "s->foo(z)" sort of way), rather than forcing a resolving via dynamic lookup.
Now I'm even more confused. In the past you had written this to a query of mine:
On 01/12/2013 12:04 AM, Jonathan Wilkes wrote:
In C would I just make a struct with fields of t_symbol,
t_class, and a pointer to link to the next one?
Yeah, a linked list would work fine, probably not as efficient as >the c++ hash structure (but lots easier
to maintain). One nit-to-pick: Use a t_class pointer, which is a >t_pd.
Hm... since the code to add new classes to the list will probably end up looking exactly like the code to add symbols to the symbol table, what if I just bloat the _symbol struct by adding a t_class *s_class? Would that affect performance? >it would break binary compatibility.
But now you say the opposite in response to DesireData's _symbol struct which adds a refcount and a symbol size member "n".
How does the one break binary compatibility but the other does not?
-Jonathan
On Friday, September 26, 2014 1:48 AM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 09/26/2014 04:22 AM, Jonathan Wilkes via Pd-list wrote:
On 09/25/2014 12:54 PM, Jonathan Wilkes via Pd-list wrote:
Um... have you actually read the source for DesireData?
Just to clarify this-- from m_pd.h desiredata 2010.01.05:
struct _symbol { char *name; /* the const string that represents this symbol */ t_pd *thing; /* pointer to the target of a receive-symbol or to the bindlist of several targets */ struct _symbol *next; /* brochette of all symbols (only for permanent symbols) */ size_t refcount; /* refcount<0 means that the symbol is permanent */ size_t n; /* size of name (support for NUL characters) */ #ifdef PD_PLUSPLUS_FACE bool operator == (const char *s) const {return strcmp(this->name,s)==0;} bool operator != (const char *s) const {return strcmp(this->name,s);} #endif };
Desiredata's t_symbol has extra members that aren't in Pd Vanilla's t_symbol struct. If there is any external out there that uses an array of symbols, then there will be problems due to this binary compatibility.
actually, i have yet to come across a *single* external that uses (t_symbol) rather than (t_symbol*) - or, if you insist on arrays (t_symbol[]) rather than (t_symbol*[]).
i don't see how this breaks binary compatibility - unless of course you *use* these members¹...
fmgdsr IOhannes
¹ that is, pass them around, in a "dosomething(s->foo)" sort of way (and i don't know how to do this with an overloaded operator). since the additional members are actually methods with an implementation in the header file, i guess that any compiler would just inline them when it comes to using them (in an "s->foo(z)" sort of way), rather than forcing a resolving via dynamic lookup.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
i'm clueless
On Fri, Sep 26, 2014 at 11:40 AM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote:
Now I'm even more confused. In the past you had written this to a query of mine:
On 01/12/2013 12:04 AM, Jonathan Wilkes wrote:
In C would I just make a struct with fields of t_symbol,
t_class, and a pointer to link to the next one?
Yeah, a linked list would work fine, probably not as efficient as >the c++ hash structure (but lots easier
to maintain). One nit-to-pick: Use a t_class pointer, which is a >t_pd.
Hm... since the code to add new classes to the list will probably end up looking exactly like the code to add symbols to the symbol table, what if I just bloat the _symbol struct by adding a t_class *s_class? Would that affect performance?
it would break binary compatibility.
But now you say the opposite in response to DesireData's _symbol struct which adds a refcount and a symbol size member "n".
How does the one break binary compatibility but the other does not?
-Jonathan
On Friday, September 26, 2014 1:48 AM, IOhannes m zmölnig < zmoelnig@iem.at> wrote:
On 09/26/2014 04:22 AM, Jonathan Wilkes via Pd-list wrote:
On 09/25/2014 12:54 PM, Jonathan Wilkes via Pd-list wrote:
Um... have you actually read the source for DesireData?
Just to clarify this-- from m_pd.h desiredata 2010.01.05:
struct _symbol { char *name; /* the const string that represents this symbol */ t_pd *thing; /* pointer to the target of a receive-symbol or to the bindlist of several targets */ struct _symbol *next; /* brochette of all symbols (only for permanent symbols) */ size_t refcount; /* refcount<0 means that the symbol is permanent */ size_t n; /* size of name (support for NUL characters) */ #ifdef PD_PLUSPLUS_FACE bool operator == (const char *s) const {return strcmp(this->name,s)==0;} bool operator != (const char *s) const {return strcmp(this->name,s);} #endif };
Desiredata's t_symbol has extra members that aren't in Pd Vanilla's t_symbol struct. If there is any external out there that uses an array of symbols, then there will be problems due to this binary compatibility.
actually, i have yet to come across a *single* external that uses (t_symbol) rather than (t_symbol*) - or, if you insist on arrays (t_symbol[]) rather than (t_symbol*[]).
i don't see how this breaks binary compatibility - unless of course you *use* these members¹...
fmgdsr IOhannes
¹ that is, pass them around, in a "dosomething(s->foo)" sort of way (and i don't know how to do this with an overloaded operator). since the additional members are actually methods with an implementation in the header file, i guess that any compiler would just inline them when it comes to using them (in an "s->foo(z)" sort of way), rather than forcing a resolving via dynamic lookup.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Quoting Jonathan Wilkes jancsika@yahoo.com:
Now I'm even more confused. In the past you had written this to a
query of mine:
[...]
But now you say the opposite in response to DesireData's _symbol
struct which adds a refcount and a symbol size member "n".How does the one break binary compatibility but the other does not?
i might have been mistaken.
the problem remains that as soon as we do add new members to a public
struct, somebody *might* use them.
and *this* is breaking binary compatibility.
e.g. if you external uses "(t_symbol*s)->n" you cannot run (nor
compile) it in Pd-vanilla.
if it does not, you still can.
if pd-l2ork adds the new members
<snip> unsigned int refcount; unsigned int length; </snip> and pd-extended adds the new members: <snip> unsigned int length; unsigned int refcount; </snip>
then any external that uses "(t_symbol*s)->n" will be doomed.
mfgasdr IOhannes
PS: it would help if you posted a reference to the actual thread (e.g.
in the pd-list archives). i had trouble finding my contribution to the
thread you posted...
There were at least two proposals back when the change was made. They're in the archives. I certainly don't remember the details at this point.
.hc
Jonathan Wilkes wrote:
Um... have you actually read the source for DesireData?
If someone wants to write me up a nice, concise, friendly non-sarcastic spec about how to change Pd-l2ork's code so that it can be binary compatible with the same features it currently has, I'll be happy to try implementing it.
-Jonathan
On Thursday, September 25, 2014 12:04 PM, Ivica Bukvic ico@vt.edu wrote:
...As strange as it may sound I must admit I've missed our broken conversations/banter. Welcome back, Hans! Alas, this time I will have to bow out--so many things to do, so little time. Hope you'll understand. Best, Ico On Sep 25, 2014 11:08 AM, "Hans-Christoph Steiner" hans@at.or.at wrote:
You can take an external compiled for the same OS/arch and it loads and works on all of them.
.hc
Ivica Bukvic wrote:
Based on what metrics? On Sep 25, 2014 11:05 AM, "Hans-Christoph Steiner" hans@at.or.at wrote:
For libraries, there is binary compatibility between pd vanilla, extended, desiredata, and vibrez. desiredata made much larger changes to the GUI-side than pd-l2ork.
.hc
Ivica Bukvic wrote:
Why is this such a problem? I did not break source compatibility (well, some of it will happen for gui objects as a result of porting gui to qt) and for every extended release you recompile new binaries anyhow and so does pd-l2ork, except that pd-l2ork goes even one step further offering a monolithic release. Besides, pd is not java and there is no binary compatibility across different platforms (except maybe libpd realized in java, but that is not what we are talking about here). Under such circumstances, I see binary compatibility strictly as a means of maintaining status quo. As a final thought, consider that a lot of good work (as you called it, and I thank you for your kind words) would not
have
been possible without breaking binary compatibility which, given the aforesaid circumstances, is a non-issue to begin with.
Best,
Ico On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner" hans@at.or.at
wrote:
You've done a lot of good work in pd-l2ork, but you also broke binary compatibility of libraries for no good reason. You could have
implemented
that feature in a way that preserved binary compatibility of libraries. You still can, and you should.
.hc
Ivica Bukvic wrote: > Well, I guess you can call me a "developer," whatever that means--I
don't
> care that much about titles. Yet, I would argue that as far as low
level
> stuff is concerned in recent years pd-l2ork has certainly pushed the > envelope in terms of core development. Even the feature that has earned me > the title in quotations delves so deep into the core that currently it > cannot be implemented in either vanilla or extended without significant > changes even though it retains full backwards compatibility. I would
also
> argue it is essential and offers a slew of features that are
unavailable
in > any other implementation of presets. > > Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially > a conscious decision to allow for faster development while addressing
the
> lack of manpower. But that is about to change once we complete port to
Qt
> library. We already transitioned to Tkpath quite a while ago which allowed > us to use a full SVG-based canvas, so I have no doubt we will be able
to
do > this again. Once this is done, we won't have to circumnavigate
exceptions
> Tk library requires in order to be compliant with different platforms and I > would argue in turn that will result in faster development. So, if you are > really interested in pushing the development of non-vanilla pd I think you > should heed some of Jonathan's advice and look for ways how community
can
> work together in combining the "best of" and engaging developers and > "developers" alike who have shown dedication to the cause. But before that > can be accomplished, the community should consider agreeing on design > choices. For instance, pd-l2ork came into existence because it focuses
on
> more nimble development at the expense of potential loss of backwards > compatibility (even though after 4 years of development the only > incompatibility we infatuated is correcting buggy positioning of iemgui > objects, which is cosmetic in nature) because a good chunk of that > compatibility stems from buggy implementations that stuck around long > enough that they became a part of the standard (e.g. iemgui's buggy > positioning of objects that are arbitrarily offset from their x and y > positions, as reported by the pd script), which is unfortunate. > > Best, > > Ico > On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote: > >> I disagree. Your example lists what? 2 more developers? I'm talking about >> "developers" as in people working the C code, build scripts, tcl/tk
etc
aka >> people who could, theoretically, help push out a new Pd-extended release. >> True, we have plenty of people working on externals, but this is a problem >> for someone who can go deeper. >> >> I still maintain that the number of low level developers to overall users >> (non-developers) is relatively low. >> >> On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote: >> >> However, your description of the user/developer ratio doesn't ring
true
to >> me. There's actually a surplus of developers and development
energy-- I
>> count two implementations of presets in the last year or two (in Pd-l2ork >> and the Chocolate et Coffee lib) which are in addition to however many >> already exist on svn and the Pd forum. >> >> >> -------- >> Dan Wilcox >> @danomatika >> danomatika.com >> robotcowboy.com >> >> >> >> >> >> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >> >> N �n�r����)em�h�yhiם�w^��
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hm, I can't seem to find any proposals on the list. If someone can find them for me (and if there are indeed details there) I'll see if they will work.
-Jonathan
On Wednesday, October 1, 2014 10:51 AM, Hans-Christoph Steiner hans@at.or.at wrote:
There were at least two proposals back when the change was made. They're in the archives. I certainly don't remember the details at this point.
.hc
Jonathan Wilkes wrote:
Um... have you actually read the source for DesireData?
If someone wants to write me up a nice, concise, friendly non-sarcastic spec about how to change Pd-l2ork's code so that it can be binary compatible with the same features it currently has, I'll be happy to try implementing it.
-Jonathan
On Thursday, September 25, 2014 12:04 PM, Ivica Bukvic ico@vt.edu wrote:
...As strange as it may sound I must admit I've missed our broken conversations/banter. Welcome back, Hans! Alas, this time I will have to bow out--so many things to do, so little time. Hope you'll understand. Best, Ico On Sep 25, 2014 11:08 AM, "Hans-Christoph Steiner" hans@at.or.at wrote:
You can take an external compiled for the same OS/arch and it loads and works on all of them.
.hc
Ivica Bukvic wrote:
Based on what metrics? On Sep 25, 2014 11:05 AM, "Hans-Christoph Steiner" hans@at.or.at wrote:
For libraries, there is binary compatibility between pd vanilla, extended, desiredata, and vibrez. desiredata made much larger changes to the GUI-side than pd-l2ork.
.hc
Ivica Bukvic wrote:
Why is this such a problem? I did not break source compatibility (well, some of it will happen for gui objects as a result of porting gui to qt) and for every extended release you recompile new binaries anyhow and so does pd-l2ork, except that pd-l2ork goes even one step further offering a monolithic release. Besides, pd is not java and there is no binary compatibility across different platforms (except maybe libpd realized in java, but that is not what we are talking about here). Under such circumstances, I see binary compatibility strictly as a means of maintaining status quo. As a final thought, consider that a lot of good work (as you called it, and I thank you for your kind words) would not
have
been possible without breaking binary compatibility which, given the aforesaid circumstances, is a non-issue to begin with.
Best,
Ico On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner" hans@at.or.at
wrote:
You've done a lot of good work in pd-l2ork, but you also broke binary compatibility of libraries for no good reason. You could have
implemented
that feature in a way that preserved binary compatibility of libraries. You still can, and you should.
.hc
Ivica Bukvic wrote: > Well, I guess you can call me a "developer," whatever that means--I
don't
> care that much about titles. Yet, I would argue that as far as low
level
> stuff is concerned in recent years pd-l2ork has certainly pushed the > envelope in terms of core development. Even the feature that has earned me > the title in quotations delves so deep into the core that currently it > cannot be implemented in either vanilla or extended without significant > changes even though it retains full backwards compatibility. I would
also
> argue it is essential and offers a slew of features that are
unavailable
in > any other implementation of presets. > > Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially > a conscious decision to allow for faster development while addressing
the
> lack of manpower. But that is about to change once we complete port to
Qt
> library. We already transitioned to Tkpath quite a while ago which allowed > us to use a full SVG-based canvas, so I have no doubt we will be able
to
do > this again. Once this is done, we won't have to circumnavigate
exceptions
> Tk library requires in order to be compliant with different platforms and I > would argue in turn that will result in faster development. So, if you are > really interested in pushing the development of non-vanilla pd I think you > should heed some of Jonathan's advice and look for ways how community
can
> work together in combining the "best of" and engaging developers and > "developers" alike who have shown dedication to the cause. But before that > can be accomplished, the community should consider agreeing on design > choices. For instance, pd-l2ork came into existence because it focuses
on
> more nimble development at the expense of potential loss of backwards > compatibility (even though after 4 years of development the only > incompatibility we infatuated is correcting buggy positioning of iemgui > objects, which is cosmetic in nature) because a good chunk of that > compatibility stems from buggy implementations that stuck around long > enough that they became a part of the standard (e.g. iemgui's buggy > positioning of objects that are arbitrarily offset from their x and y > positions, as reported by the pd script), which is unfortunate. > > Best, > > Ico > On Sep 23, 2014 9:21 AM, "Dan Wilcox" danomatika@gmail.com wrote: > >> I disagree. Your example lists what? 2 more developers? I'm talking about >> "developers" as in people working the C code, build scripts, tcl/tk
etc
aka >> people who could, theoretically, help push out a new Pd-extended release. >> True, we have plenty of people working on externals, but this is a problem >> for someone who can go deeper. >> >> I still maintain that the number of low level developers to overall users >> (non-developers) is relatively low. >> >> On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote: >> >> However, your description of the user/developer ratio doesn't ring
true
to >> me. There's actually a surplus of developers and development
energy-- I
>> count two implementations of presets in the last year or two (in Pd-l2ork >> and the Chocolate et Coffee lib) which are in addition to however many >> already exist on svn and the Pd forum. >> >> >> -------- >> Dan Wilcox >> @danomatika >> danomatika.com >> robotcowboy.com >> >> >> >> >> >> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >> >> N �n�r����)em�h�yhiם�w^��
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 09/23/2014 09:19 AM, Dan Wilcox wrote:
I disagree. Your example lists what? 2 more developers? I'm talking about "developers" as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper.
I still maintain that the number of low level developers to overall users (non-developers) is relatively low.
That's true in nearly any piece of user-facing software. But compared to other user-facing software, Pd seems to have a fairly large number of users with a working knowledge of C, building/compiling, etc. Enough that I can think of at least 13 for whom there is proof just by what I've read from them on the user list. But there are probably many more than that.
-Jonathan
On Sep 23, 2014, at 6:00 AM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
However, your description of the user/developer ratio doesn't ring true to me. There's actually a surplus of developers and development energy-- I count two implementations of presets in the last year or two (in Pd-l2ork and the Chocolate et Coffee lib) which are in addition to however many already exist on svn and the Pd forum.
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Billy Stiltner -
Dan Wilcox -
Hans-Christoph Steiner -
IOhannes m zmölnig -
Ivica Bukvic -
Jonathan Wilkes -
Phil Stone -
zmoelnig＠iem.at