Re: [PD] Updated pd-extended

[Jonathan Wilkes via 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  
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  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"  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"  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" 
 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
>>> comp

Re: [PD] Updated Pd-Extended

[Hans-Christoph Steiner]

Jonathan Wilkes via Pd-list wrote:
> Some questions about the bullet points on the page:
> 
> * update the libraries to the latest version, and test them 
> 
> 
> Aren't they updated by virtue of pulling from the latest svn?  If I can get 
> Pd-extended to compile, what else do I need to do in order to update the libs?

Pd-extended releases do not automatically pull in everything from the latest
SVN.  In terms of the included library, a Pd-extended release starts with the
previous release.  Then individual libraries must be updated based on a new
release of that library.  This kind of process is key to having a stable,
reliable set of libraries.  More info here:

http://puredata.info/docs/developer/GettingIntoPdextended

.hc

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated Pd-Extended

[Hans-Christoph Steiner]

I don't remember the details on the differences.  Pd-extended guarantees pixel
sizes of boxes across platforms and releases (if not, its a bug).  One way it
does that is using `tk scaling 1`.  I believe that was removed in vanilla.
There are probably other details like this, like related to support Tcl/Tk 8.5
and 8.6, and supporting Tk/Cocoa/64-bit.

.hc

Jonathan Wilkes via Pd-list wrote:
> Those bullet points are from the webpage, not written by me.  My questions 
> about the bullet points were inline, e.g.:
> 
>> Does this refer to the single-line change in pd-gui.tcl pertaining to 
> the font scaling, or something bigger?  If it's something bigger then 
> that's a real drag.
> 
> And by "font scaling" I mean "tk scaling 1" in pd-gui.tcl
> 
> 
> -Jonathan
> 
> 
> 
> On Tuesday, September 30, 2014 3:43 AM, IOhannes m zmoelnig  
> wrote:
>  
> 
> 
> On 2014-09-30 04:39, Jonathan Wilkes via Pd-list wrote:
>> * pull in relevant commits from pd-vanilla (you can't just pull
>> them all in because vanilla does the GUI stuff differently,
> 
> does it?
> 
> fgmasdr
> IOhannes
> 
> 
> ___
> 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

Re: [PD] Updated Pd-Extended

[Hans-Christoph Steiner]

Seb Shader via Pd-list wrote:
> Hello again list,
> 
> 
>   What do y'all think of the idea of releasing Pd-extended both as a 
> "core" pd with no libraries added except maybe the libdir and hex loaders and 
> as a version with multiple libraries (2 release stages)? Perhaps it's been 
> discussed. the thing I enjoy about Extended is the features it adds to 
> pd-vanilla, and this way people can just keep the same libraries installed in 
> the same places and switch between vanilla and extended easier. In my 
> experience I never need/want to use most of the arbitrary libraries included 
> and/or loaded on startup and could easily download and install the ones I do 
> want. I also see the appeal/logic of using a standardized set of libs though.
> 
> 
> seems like a reasonable way to develop it too... everyone focusing on the 
> core and then working on their own libs for a bundled release.

That is definitely the goal of Pd-extended, I couldn't have said it better
myself. :-)  It is purely a matter of someone doing the work.  With two little
kids and full time programming work, I have little spare cycles for
programming these days.  But I'll happily help anyone who wants to take on
part of all of making this happen.


> Also about import/saving libraries to load on startup: wouldn't it make more 
> sense if either the list were editable or there were no list? Strange that 
> users get this arbitrary list to load on startup, (not even all the libs 
> included in PdX) without being able to edit it, a set of libs that they never 
> have to [import], but then they're expected to [import] everything else 
> unless they manually edit the preferences file (quite confusing for most 
> users)?
> 

The libraries that are loaded by default are an ld legacy of the beginning
of Pd-extended.  It should be removed, but it needs to be done in a way that
is transparent when people update.  Or maybe it makes sense now to just start
fresh.  When I get back to it, I won't be working that arrangement of crufty
old libraries loaded by default.  Instead the way forward is to make a new
standard library that does things consistently and correctly across the whole
library, while only maintaining backward compatibility when it doesn't get in
the way of the primary goal.


> Btw I also have a bit of time and know a little bit of c and tcl, i'd be glad 
> to pitch in where i can when there is a concrete plan (list of to-do's) of 
> how to move forward with Pd-extended.

Excellent!  Here is the page that I maintained for release goals:

http://puredata.info/dev/NextRelease

.hc

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated Pd-Extended

[Hans-Christoph Steiner]

A core idea of having a standard format for libraries is to make them easily
packaged and distributed.  There are lots of libraries that follow
https://puredata.info/docs/developer/LibraryTemplate, so the next step is for
someone to make something like https://pypi.python.org as the central repo of
libraries that includes an update/download tool.

As for the auto-build servers, I think only the Debian ones are still running.
 The Windows one was on a server that died, and the OSX was an old laptop that
is basically dead.  It was running 10.5 anyway.

For anyone who can set up a Windows and/or OSX build machine, they were super
helpful for maintaining cross-platform compatibility.  Here are the docs:

http://puredata.info/docs/developer/WindowsMinGW
http://puredata.info/docs/developer/MacOSXFink

These all have some info, but need work:
http://puredata.info/docs/developer/MacOSXMacPorts
http://puredata.info/docs/developer/Windows64BitMinGWX64
http://puredata.info/docs/developer/MacOSXHomebrew

.hc

Dan Wilcox wrote:
> I like the idea of being able to download vanilla and then download other 
> externals as needed, Gem for instance. Currently, I've been copying in the 
> prebuilt externals from Pd extended to use with newer versions of vanilla.
> 
> Of course, this wouldn't be needed if we could set up more of a concerted 
> release schedule to crank out newer versions of extended. I also like the 
> work Hans et al. did for pixel perfect patches across platforms. I'd like to 
> see that incorporated into vanilla as it makes sense.
> 
> I see the autobuild server is still up. Does this still build for all 
> platforms?
> 
> On Sep 29, 2014, at 8:44 PM, pd-list-requ...@lists.iem.at wrote:
> 
>> From: sebfumas...@aol.com
>> Subject: Re: [PD] Updated Pd-Extended
>> Date: September 29, 2014 at 6:10:42 PM EDT
>> To: pd-list@lists.iem.at
>>
>>
>> Hello again list,
>>
>>  What do y'all think of the idea of releasing Pd-extended both as a 
>> "core" pd with no libraries added except maybe the libdir and hex loaders 
>> and as a version with multiple libraries (2 release stages)? Perhaps it's 
>> been discussed. the thing I enjoy about Extended is the features it adds to 
>> pd-vanilla, and this way people can just keep the same libraries installed 
>> in the same places and switch between vanilla and extended easier. In my 
>> experience I never need/want to use most of the arbitrary libraries included 
>> and/or loaded on startup and could easily download and install the ones I do 
>> want. I also see the appeal/logic of using a standardized set of libs though.
>>
>> seems like a reasonable way to develop it too... everyone focusing on the 
>> core and then working on their own libs for a bundled release.
>>
>> Also about import/saving libraries to load on startup: wouldn't it make more 
>> sense if either the list were editable or there were no list? Strange that 
>> users get this arbitrary list to load on startup, (not even all the libs 
>> included in PdX) without being able to edit it, a set of libs that they 
>> never have to [import], but then they're expected to [import] everything 
>> else unless they manually edit the preferences file (quite confusing for 
>> most users)?
>>
>> Btw I also have a bit of time and know a little bit of c and tcl, i'd be 
>> glad to pitch in where i can when there is a concrete plan (list of to-do's) 
>> of how to move forward with Pd-extended.
>>
>>-Sebastian
> 
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
> 
> 
> 
> 
> 
> 
> 
> 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

Re: [PD] Updated pd-extended

[Hans-Christoph Steiner]

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

Re: [PD] Updated Pd-Extended

[Jonathan Wilkes via Pd-list]

Those bullet points are from the webpage, not written by me.  My questions 
about the bullet points were inline, e.g.:

>Does this refer to the single-line change in pd-gui.tcl pertaining to 
the font scaling, or something bigger?  If it's something bigger then 
that's a real drag.

And by "font scaling" I mean "tk scaling 1" in pd-gui.tcl


-Jonathan



On Tuesday, September 30, 2014 3:43 AM, IOhannes m zmoelnig  
wrote:
 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-09-30 04:39, Jonathan Wilkes via Pd-list wrote:
> * pull in relevant commits from pd-vanilla (you can't just pull
> them all in because vanilla does the GUI stuff differently,

does it?

fgmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUKl8QAAoJELZQGcR/ejb46VIQAIHmhF2GukdVp87DsaSrlkqE
rkDiXoqi8KjAA7y/HlH4d80ntoACJj4ONfaZguc8+6+dmRSOm8CXE74r81hj2b0/
u/FyZ6Mq0FOhJEVCsm2RStlYncMlMR/nHWEyNCfQh9lumGSvod6F8nxkxQnmEzuR
lULzJ1EcHTQX8l1iVDEt9zFk+NR67sIHXXqlfwuuZESnKzE+CsQgn9AQIx5kOBzX
9McTg3mdSsZLFRQjgRsnQNnfY7xIVHZCggj9eLlBwByXjktgjBsE0EsoVx/PKm5j
RgEpGI/dEdpr5ezl3FBJABlzG2GFIPpyhOHuups3dtPmeuN5IYN9+D8Bb+OcPcVP
AyUsvbEW4a4sNU0jG5VjKLYrrgxAVGPOFpxQfTQ943ZmW6qYME6kXyq1P3dckjnn
z/RgblwJ/qUvhRWiwQGTEbDshzkU0I2UtIZceWCIOGm0+nBnC/84POq/mMuYBgZW
2KWLaIraiTUgiB9R4r8+JISnpSC+PWoOh7v8bEEET0VUQnpFfjn9HOM/cg6V3YBz
V6JfuFBCucgmK7R1NGmh82XIzzSXDSw2R0KuYDT1TPWvkuyNXHZ9naC6trZFjuDh
mx0ufaWjm5DYtVBLnAQjzTcBdMt51OJMP+A3Nfq2fAwuWuKro/cGfRAG/8mXpaZr
PDesQF/SxyrRdJ9/exub
=tT33
-END PGP SIGNATURE-


___
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

Re: [PD] Updated Pd-Extended

[IOhannes m zmoelnig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-09-30 15:32, Jonathan Wilkes via Pd-list wrote:
> Those bullet points are from the webpage, not written by me.  My
> questions about the bullet points were inline, e.g.:

ah sorry.

my email client seems to have messed up with quoting (at least it
wasn't clear to me which was the quote and which was your
comment/question).

fgmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUKrUXAAoJELZQGcR/ejb4iS4P/0s+g/aj428gaNU++l0AXx7O
62LCaxxQ2WN+61RMnNHDvxqLhssvlits+hqG4gr7Th0VooomU1V4zrqQUib/GjXa
4h54/r/cV6ffWf0+NfGgz9nBahOiZm2KuzqCQnTecMJ55NvnDJdL/DJZ96LCJpGG
8PT7PTozuqkXT4mjAOWhoi9hhQICLp+DgcXYuBG6jZbLaqUoG39cyD1gBO4bEPUf
gO1+MvLZp0ughwYpbcO6tnpJ3d9AtkgTzFyYQgMcowikwtJWO/pn/wuh82iK/Kur
b4x01IMlZl7W2nmcIp4M6nBzM5N0rEdP74qQ5oX80oYumSQUEtdCrjtqeVacbqi4
o9W8VO62hebTAwZY+IiN/XvNGbCLq+5lOxw1NM0x6Bj8IJsskPFZI2suFN77ngQv
ATLOazy+wziofSG7WAY1/5hZH1K6skRls7rQBCIINTjiD46xEegIISok7Q3eR7Bg
GR61ttQKz/CZQYF5vfBVOxVd0xISIqBBOmwi8q+tCJDeSAEFWZlqrQATq14sc+st
sk18H0N/AjzXfXcKlSm6sILCjqWw4aXHi/3kk2hllvoaGNwCfSF9h+fkHJqV/cgl
v9MMUEAcc4YZGGF6oiSq1FZ7ZwDvNgnd+eEDf5Dz2+x8Go7x7frzMQcq35ajKLqv
Gw6L07txSOTUmwneCshq
=Njax
-END PGP SIGNATURE-

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated Pd-Extended

[Jonathan Wilkes via Pd-list]

Those bullet points are from the webpage, not written by me.  My questions 
about the bullet points were inline, e.g.:

>Does this refer to the single-line change in pd-gui.tcl pertaining to 
the font scaling, or something bigger?  If it's something bigger then 
that's a real drag.

And by "font scaling" I mean "tk scaling 1" in pd-gui.tcl


-Jonathan



On Tuesday, September 30, 2014 3:43 AM, IOhannes m zmoelnig  
wrote:
 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-09-30 04:39, Jonathan Wilkes via Pd-list wrote:
> * pull in relevant commits from pd-vanilla (you can't just pull
> them all in because vanilla does the GUI stuff differently,

does it?

fgmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUKl8QAAoJELZQGcR/ejb46VIQAIHmhF2GukdVp87DsaSrlkqE
rkDiXoqi8KjAA7y/HlH4d80ntoACJj4ONfaZguc8+6+dmRSOm8CXE74r81hj2b0/
u/FyZ6Mq0FOhJEVCsm2RStlYncMlMR/nHWEyNCfQh9lumGSvod6F8nxkxQnmEzuR
lULzJ1EcHTQX8l1iVDEt9zFk+NR67sIHXXqlfwuuZESnKzE+CsQgn9AQIx5kOBzX
9McTg3mdSsZLFRQjgRsnQNnfY7xIVHZCggj9eLlBwByXjktgjBsE0EsoVx/PKm5j
RgEpGI/dEdpr5ezl3FBJABlzG2GFIPpyhOHuups3dtPmeuN5IYN9+D8Bb+OcPcVP
AyUsvbEW4a4sNU0jG5VjKLYrrgxAVGPOFpxQfTQ943ZmW6qYME6kXyq1P3dckjnn
z/RgblwJ/qUvhRWiwQGTEbDshzkU0I2UtIZceWCIOGm0+nBnC/84POq/mMuYBgZW
2KWLaIraiTUgiB9R4r8+JISnpSC+PWoOh7v8bEEET0VUQnpFfjn9HOM/cg6V3YBz
V6JfuFBCucgmK7R1NGmh82XIzzSXDSw2R0KuYDT1TPWvkuyNXHZ9naC6trZFjuDh
mx0ufaWjm5DYtVBLnAQjzTcBdMt51OJMP+A3Nfq2fAwuWuKro/cGfRAG/8mXpaZr
PDesQF/SxyrRdJ9/exub
=tT33
-END PGP SIGNATURE-


___
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

Re: [PD] Updated Pd-Extended

[Dan Wilcox]

I like the idea of being able to download vanilla and then download other 
externals as needed, Gem for instance. Currently, I've been copying in the 
prebuilt externals from Pd extended to use with newer versions of vanilla.

Of course, this wouldn't be needed if we could set up more of a concerted 
release schedule to crank out newer versions of extended. I also like the work 
Hans et al. did for pixel perfect patches across platforms. I'd like to see 
that incorporated into vanilla as it makes sense.

I see the autobuild server is still up. Does this still build for all platforms?

On Sep 29, 2014, at 8:44 PM, pd-list-requ...@lists.iem.at wrote:

> From: sebfumas...@aol.com
> Subject: Re: [PD] Updated Pd-Extended
> Date: September 29, 2014 at 6:10:42 PM EDT
> To: pd-list@lists.iem.at
> 
> 
> Hello again list,
> 
>   What do y'all think of the idea of releasing Pd-extended both as a 
> "core" pd with no libraries added except maybe the libdir and hex loaders and 
> as a version with multiple libraries (2 release stages)? Perhaps it's been 
> discussed. the thing I enjoy about Extended is the features it adds to 
> pd-vanilla, and this way people can just keep the same libraries installed in 
> the same places and switch between vanilla and extended easier. In my 
> experience I never need/want to use most of the arbitrary libraries included 
> and/or loaded on startup and could easily download and install the ones I do 
> want. I also see the appeal/logic of using a standardized set of libs though.
> 
> seems like a reasonable way to develop it too... everyone focusing on the 
> core and then working on their own libs for a bundled release.
> 
> Also about import/saving libraries to load on startup: wouldn't it make more 
> sense if either the list were editable or there were no list? Strange that 
> users get this arbitrary list to load on startup, (not even all the libs 
> included in PdX) without being able to edit it, a set of libs that they never 
> have to [import], but then they're expected to [import] everything else 
> unless they manually edit the preferences file (quite confusing for most 
> users)?
> 
> Btw I also have a bit of time and know a little bit of c and tcl, i'd be glad 
> to pitch in where i can when there is a concrete plan (list of to-do's) of 
> how to move forward with Pd-extended.
> 
>-Sebastian


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

Re: [PD] Updated Pd-Extended

[IOhannes m zmoelnig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-09-30 04:39, Jonathan Wilkes via Pd-list wrote:
> * pull in relevant commits from pd-vanilla (you can't just pull
> them all in because vanilla does the GUI stuff differently,

does it?

fgmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUKl8QAAoJELZQGcR/ejb46VIQAIHmhF2GukdVp87DsaSrlkqE
rkDiXoqi8KjAA7y/HlH4d80ntoACJj4ONfaZguc8+6+dmRSOm8CXE74r81hj2b0/
u/FyZ6Mq0FOhJEVCsm2RStlYncMlMR/nHWEyNCfQh9lumGSvod6F8nxkxQnmEzuR
lULzJ1EcHTQX8l1iVDEt9zFk+NR67sIHXXqlfwuuZESnKzE+CsQgn9AQIx5kOBzX
9McTg3mdSsZLFRQjgRsnQNnfY7xIVHZCggj9eLlBwByXjktgjBsE0EsoVx/PKm5j
RgEpGI/dEdpr5ezl3FBJABlzG2GFIPpyhOHuups3dtPmeuN5IYN9+D8Bb+OcPcVP
AyUsvbEW4a4sNU0jG5VjKLYrrgxAVGPOFpxQfTQ943ZmW6qYME6kXyq1P3dckjnn
z/RgblwJ/qUvhRWiwQGTEbDshzkU0I2UtIZceWCIOGm0+nBnC/84POq/mMuYBgZW
2KWLaIraiTUgiB9R4r8+JISnpSC+PWoOh7v8bEEET0VUQnpFfjn9HOM/cg6V3YBz
V6JfuFBCucgmK7R1NGmh82XIzzSXDSw2R0KuYDT1TPWvkuyNXHZ9naC6trZFjuDh
mx0ufaWjm5DYtVBLnAQjzTcBdMt51OJMP+A3Nfq2fAwuWuKro/cGfRAG/8mXpaZr
PDesQF/SxyrRdJ9/exub
=tT33
-END PGP SIGNATURE-

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated Pd-Extended

[Jonathan Wilkes via Pd-list]

Some questions about the bullet points on the page:

* update the libraries to the latest version, and test them 


Aren't they updated by virtue of pulling from the latest svn?  If I can get 
Pd-extended to compile, what else do I need to do in order to update the libs?


* pull in relevant commits from pd-vanilla (you can't just pull them all in 
because vanilla does the GUI stuff differently, and Pd-extended 
has promised pixel-exact sizing on all platforms for a few releases 
now). 

Does this refer to the single-line change in pd-gui.tcl pertaining to the font 
scaling, or something bigger?  If it's something bigger then that's a real drag.


* fix platform-specific bugs

Are the auto-builds still around?  If not, is there a guide to setting up a 
nightly build environment?


* finish splitting out all the core objects into standalone library 
(this is mostly done, that makes it a lot easier to keep pd-extended's 
core updated with pd-vanilla commits since all of the objects are a 
separate library that is taken directly from vanilla). 


How is this easier than not doing any work splitting out the internal objects?  
(The fact that it is not finished leads me to believe it is not easier.)


-Jonathan



On Tuesday, September 30, 2014 6:49 AM, "pured...@11h11.com" 
 wrote:
 


Hi all,

I have created a page on http://puredata.info/dev/pdextended listing  
the people interested (or the people that can help but are busy). I  
will keep this page updated. Anyone with c / tlc / build farm /  
continuous integration / ideas / time please chime in (create an  
account https://puredata.info/join_form and edit the page or let me  
know).

It is not much for now, but it's a starting point.
Cheers~




___
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

Re: [PD] Updated Pd-Extended

[puredata]

Hi all,

I have created a page on http://puredata.info/dev/pdextended listing  
the people interested (or the people that can help but are busy). I  
will keep this page updated. Anyone with c / tlc / build farm /  
continuous integration / ideas / time please chime in (create an  
account https://puredata.info/join_form and edit the page or let me  
know).


It is not much for now, but it's a starting point.
Cheers~



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated Pd-Extended

[Jonathan Wilkes via Pd-list]

On 09/29/2014 06:10 PM, Seb Shader via Pd-list wrote:

Hello again list,

What do y'all think of the idea of releasing Pd-extended both as a 
"core" pd with no libraries added except maybe the libdir and hex 
loaders and as a version with multiple libraries (2 release stages)? 
Perhaps it's been discussed. the thing I enjoy about Extended is the 
features it adds to pd-vanilla, and this way people can just keep the 
same libraries installed in the same places and switch between vanilla 
and extended easier. In my experience I never need/want to use most of 
the arbitrary libraries included and/or loaded on startup and could 
easily download and install the ones I do want. I also see the 
appeal/logic of using a standardized set of libs though.


seems like a reasonable way to develop it too... everyone focusing on 
the core and then working on their own libs for a bundled release.


Also about import/saving libraries to load on startup: wouldn't it 
make more sense if either the list were editable or there were no 
list? Strange that users get this arbitrary list to load on startup, 
(not even all the libs included in PdX) without being able to edit it, 
a set of libs that they never have to [import], but then they're 
expected to [import] everything else unless they manually edit the 
preferences file (quite confusing for most users)?


Arbitrary or not, the users who learned Pd by using Pd-extended 
exclusively assumed that these default loaded classes were the 
"standard" libs that were available in Pd.  So you have an enormous 
number of patches and abstractions out there which do not use [import] 
or [declare] to load libs (nor do they prefix the objects with the 
libdir like [zexy/time] or [hcs/canvas_name].)


If you throw those default loaded libs down the memory hole, you end up 
making all kinds of work for the user who wants to use an arbitrary 
patch or abstraction-- maybe one from Pd forum, the mailing list, an 
individual's website, a tutorial, or somewhere else.  That user very 
likely doesn't care about the "right" way to load libs, or more sensible 
default behavior in the next release of Pd-extended.  They just want a 
patch or abstraction to load without broken objects.


On the other hand-- I'm pretty sure you can edit the list, either in the 
preferences file (named something like .pdsettings on a Linux distro) or 
in the path and startup dialogs.


-Jonathan



Btw I also have a bit of time and know a little bit of c and tcl, i'd 
be glad to pitch in where i can when there is a concrete plan (list of 
to-do's) of how to move forward with Pd-extended.


   -Sebastian


___
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

Re: [PD] Updated Pd-Extended

[Seb Shader via Pd-list]

Hello again list,


What do y'all think of the idea of releasing Pd-extended both as a 
"core" pd with no libraries added except maybe the libdir and hex loaders and 
as a version with multiple libraries (2 release stages)? Perhaps it's been 
discussed. the thing I enjoy about Extended is the features it adds to 
pd-vanilla, and this way people can just keep the same libraries installed in 
the same places and switch between vanilla and extended easier. In my 
experience I never need/want to use most of the arbitrary libraries included 
and/or loaded on startup and could easily download and install the ones I do 
want. I also see the appeal/logic of using a standardized set of libs though.


seems like a reasonable way to develop it too... everyone focusing on the core 
and then working on their own libs for a bundled release.


Also about import/saving libraries to load on startup: wouldn't it make more 
sense if either the list were editable or there were no list? Strange that 
users get this arbitrary list to load on startup, (not even all the libs 
included in PdX) without being able to edit it, a set of libs that they never 
have to [import], but then they're expected to [import] everything else unless 
they manually edit the preferences file (quite confusing for most users)?


Btw I also have a bit of time and know a little bit of c and tcl, i'd be glad 
to pitch in where i can when there is a concrete plan (list of to-do's) of how 
to move forward with Pd-extended.


   -Sebastian
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated pd-extended

[zmoelnig]

Quoting Jonathan Wilkes :

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

unsigned int refcount;
unsigned int length;

and pd-extended adds the new members:

unsigned int length;
unsigned int refcount;


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



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated pd-extended

[Billy Stiltner]

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 <
> zmoel...@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
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated pd-extended

[Jonathan Wilkes via Pd-list]

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

Re: [PD] Updated pd-extended

[IOhannes m zmölnig]

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.





signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated pd-extended

[Jonathan Wilkes via 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  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" > 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"
mailto:h...@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"
mailto:h...@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

Re: [PD] Updated pd-extended

[Jonathan Wilkes via 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  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"  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"  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" 
>>> 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

Re: [PD] Updated pd-extended

[Alexandre Torres Porres]

love those two ideas

I could also add the idea of having some research group working on it. At
least here in Brazil I know a couple of people who'd like to back it up.

so yeah, I was waiting for the american PdCon and it never happened :(
guess I'll have to make another south american one

cheers

2014-09-21 18:19 GMT-03:00 me.grimm :

> >> it involves time
>
> ... or money.
>
> maybe we revisit the kickstarter (or something else) idea brought forth by
> jonathon a few years ago and just pay someone to do it. to me it seems like
> 1) none of us really have any money (im just assuming here we are all poor
> artists) and more importantly 2) none of us really have any time and those
> that do might not have the skills.
>
> OR maybe we have another PDCon (remember that?) to get amped up and pump
> something out
>
> m
>
> On Sun, Sep 21, 2014 at 1:44 PM, Dan Wilcox  wrote:
>
>> I talked to Hans about this a bit. In essence, it involves bringing in
>> the new pd vanilla source and making sure the Pd-extended
>> additions/modifications aren't lost. With the updates/cleanups to the
>> tcl/tk sources a few years ago (great work Hans et al!), it should be alot
>> easier than the previous extended releases. But still, *easy* or not, it
>> involves time.
>>
>> On Sep 21, 2014, at 6:00 AM, pd-list-requ...@lists.iem.at wrote:
>>
>> *From: *Alexandre Torres Porres 
>> *Subject: **Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended*
>> *Date: *September 20, 2014 at 5:02:59 PM EDT
>> *To: *Billy Stiltner 
>> *Cc: *"pd-list@lists.iem.at" 
>>
>>
>> I wish I knew something about coding to help out with its development :P
>> I do care a lot about it though and wish I could help in some other way.
>>
>> I do see a few problems with extended, but they're basically related to
>> some of the externals and libraries that sometimes do not work as they
>> should, have bad and messy help files and are sometimes redundanct. If
>> welcome, I could help sharing my thoughts and two cents about that, but I
>> realize those are not actual bug fixes regarding the code, so it's not a
>> priority on its to do list and issues for being updated to another release.
>>
>> Anyway, while were at it, what kind of work exactly do you mean someone
>> would have to do? I suppose there is a great list of bug fixes just to keep
>> it basically what it is. Given the context, I'm not assuming any big to do
>> list for some new features agenda. But besidesthe bug fixes, how hard is it
>> for someone to just update to the latest vanilla core?
>>
>> Well, since Pd is an open source project that relies on community effort,
>> and this is the list of its main developers and users, I guess this is the
>> place to talk about a collaboration and see if we can get Pd-extended's
>> development
>> to continue.
>>
>> I'd to help in any way I can.
>>
>> Cheers
>>
>>
>> 
>> 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
>>
>>
>
>
> --
> 
> m.e.grimm | m.f.a | ed.m.
> megr...@gmail.com
> _
>
> ___
> 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

Re: [PD] Updated pd-extended

[Ivica Bukvic]

...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"  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" 
> 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" 
> >> 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"  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
> >>

Re: [PD] Updated pd-extended

[Hans-Christoph Steiner]

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"  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" 
>> 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"  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-requ...@lists.iem.at wrote:
>>
>> However, your description of the user/developer ratio doesn't ring
>> true
 to
>>>

Re: [PD] Updated pd-extended

[Ivica Bukvic]

Based on what metrics?
On Sep 25, 2014 11:05 AM, "Hans-Christoph Steiner"  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" 
> 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"  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-requ...@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

Re: [PD] Updated pd-extended

[Hans-Christoph Steiner]

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"  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"  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-requ...@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






 ___

Re: [PD] Updated pd-extended

[Ivica Bukvic]

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"  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"  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-requ...@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 mai

Re: [PD] Updated pd-extended

[Hans-Christoph Steiner]

Just follow this, and it'll be easy to get it included on all platforms:
https://puredata.info/docs/developer/GettingIntoPdextended

.hc

pured...@11h11.com wrote:
> Hi,
> 
> Would do anything to finally include mtl abstractions to pd-extended. I can
> build on Windows, Mac, Linux & the RPI.
> 
> Will try to poke Hans about the code diffs on #dataflow. Should we (anyone
> interested in updating pd-extended) have a chat (irc, hangout, whatever). I am
> sure Hans will be willing to gives 30 minutes to help us help him.
> 
> Let's bang it.
> 
> ___
> 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

Re: [PD] Updated pd-extended

[Hans-Christoph Steiner]

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"  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-requ...@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

Re: [PD] Updated pd-extended

[Hans-Christoph Steiner]

Did someone write some tests for some Pd flavor?  That'd be a nice development.

Pd-extended's test suite consists of loading every object, and loading every
help patch.  They are scripts in SVN: scripts/load_every_object.sh and
scripts/tests/  They have been quite helpful in finding issues.

.hc

Jonathan Wilkes via Pd-list wrote:
> Before you pay someone to do it, we need to define what "it" is.
> 
> "It" might generally look something like this:
> 1) Pull from the newest stable upstream code
> 
> 2) Get it to compile
> 3) Run the regression tests
> 4) Make alpha and beta builds, gather reports of bugs, fix bugs, re-run tests
> 5) Release
> 
> So for Pd-extended, one would pull from the newest stable Vanilla source.
> 
> 
> To complete #2 and #4, one need build environments for all of Pd-extended's 
> target platforms.  Probably the easiest way to achieve that is to partner 
> with two other developers-- for example, if one uses Ubuntu, find an OSX 
> person and a Windows person who can build Pd on their respective OSes.  
> (There are guides on puredata.info about how to do this for each platform.)
> 
> 
> Pd-extended doesn't have any tests AFAICT, so skip that step.
> 
> Kickstarter won't really help you here.  It's possible that it would give 
> some incentive for doing a single release, but how can it sustain that work 
> for the next release, or the one after that?
> 
> -Jonathan
> 
> On Sunday, September 21, 2014 5:22 PM, me.grimm  wrote:
>  
> 
> 
>>> it involves time
> 
> ... or money. 
> 
> maybe we revisit the kickstarter (or something else) idea brought forth by 
> jonathon a few years ago and just pay someone to do it. to me it seems like 
> 1) none of us really have any money (im just assuming here we are all poor 
> artists) and more importantly 2) none of us really have any time and those 
> that do might not have the skills.
> 
> OR maybe we have another PDCon (remember that?) to get amped up and pump 
> something out
> 
> m
> 
> 
> On Sun, Sep 21, 2014 at 1:44 PM, Dan Wilcox  wrote:
> 
> I talked to Hans about this a bit. In essence, it involves bringing in the 
> new pd vanilla source and making sure the Pd-extended additions/modifications 
> aren't lost. With the updates/cleanups to the tcl/tk sources a few years ago 
> (great work Hans et al!), it should be alot easier than the previous extended 
> releases. But still, *easy* or not, it involves time.
>>
>>
>> On Sep 21, 2014, at 6:00 AM, pd-list-requ...@lists.iem.at wrote:
>>
>> From: Alexandre Torres Porres 
>>>
>>> Subject: Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended
>>>
>>> Date: September 20, 2014 at 5:02:59 PM EDT
>>>
>>> To: Billy Stiltner 
>>>
>>> Cc: "pd-list@lists.iem.at" 
>>>
>>>
>>>
>>> I wish I knew something about coding to help out with its development :P I 
>>> do care a lot about it though and wish I could help in some other way. 
>>>
>>>
>>> I do see a few problems with extended, but they're basically related to 
>>> some of the externals and libraries that sometimes do not work as they 
>>> should, have bad and messy help files and are sometimes redundanct. If 
>>> welcome, I could help sharing my thoughts and two cents about that, but I 
>>> realize those are not actual bug fixes regarding the code, so it's not a 
>>> priority on its to do list and issues for being updated to another release.
>>>
>>>
>>> Anyway, while were at it, what kind of work exactly do you mean someone 
>>> would have to do? I suppose there is a great list of bug fixes just to keep 
>>> it basically what it is. Given the context, I'm not assuming any big to do 
>>> list for some new features agenda. But besidesthe bug fixes, how hard is it 
>>> for someone to just update to the latest vanilla core? 
>>>
>>>
>>> Well, since Pd is an open source project that relies on community effort, 
>>> and this is the list of its main developers and users, I guess this is the 
>>> place to talk about a collaboration and see if we can get Pd-extended's 
>>> developmentto continue.
>>>
>>>
>>> I'd to help in any way I can.
>>>
>>>
>>> Cheers
>>
>> 
>> 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

Re: [PD] Updated pd-extended

[Hans-Christoph Steiner]

I haven't checked the status of any of those patches in a long time.  I posted
many in the patch tracker, did those get included?  I used to maintain the
pd-extended git repo as a branch that always showed the pd-extended changes as
a series of commits on top of Pd-vanilla's git.  That is called the
'patch_series' branch in the pd-extended.git. But then so many of my patches
did not get accepted, I abandoned that approach since it was too much work.
More recently, I reversed it, treating vanilla's git as a source of patches
for Pd-extended.

.hc

Miller Puckette wrote:
> I remember seeing a series of patches (code diffs I mean) that made the
> necessary changes to Pd vanilla to Pd extended - does anyone know if these
> still exist?  (I couldn't find them when I looked at the Pd extended SVN
> repository a few weeks ago).
> 
> Some of them should be in Pd vanilla anyway, and if I took that part on it
> would make the rest a lot easier.
> 
> cheers
> Miller
> 
> On Sun, Sep 21, 2014 at 01:44:11PM -0400, Dan Wilcox wrote:
>> I talked to Hans about this a bit. In essence, it involves bringing in the 
>> new pd vanilla source and making sure the Pd-extended 
>> additions/modifications aren't lost. With the updates/cleanups to the tcl/tk 
>> sources a few years ago (great work Hans et al!), it should be alot easier 
>> than the previous extended releases. But still, *easy* or not, it involves 
>> time.
>>
>> On Sep 21, 2014, at 6:00 AM, pd-list-requ...@lists.iem.at wrote:
>>
>>> From: Alexandre Torres Porres 
>>> Subject: Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended
>>> Date: September 20, 2014 at 5:02:59 PM EDT
>>> To: Billy Stiltner 
>>> Cc: "pd-list@lists.iem.at" 
>>>
>>>
>>> I wish I knew something about coding to help out with its development :P I 
>>> do care a lot about it though and wish I could help in some other way. 
>>>
>>> I do see a few problems with extended, but they're basically related to 
>>> some of the externals and libraries that sometimes do not work as they 
>>> should, have bad and messy help files and are sometimes redundanct. If 
>>> welcome, I could help sharing my thoughts and two cents about that, but I 
>>> realize those are not actual bug fixes regarding the code, so it's not a 
>>> priority on its to do list and issues for being updated to another release.
>>>
>>> Anyway, while were at it, what kind of work exactly do you mean someone 
>>> would have to do? I suppose there is a great list of bug fixes just to keep 
>>> it basically what it is. Given the context, I'm not assuming any big to do 
>>> list for some new features agenda. But besidesthe bug fixes, how hard is it 
>>> for someone to just update to the latest vanilla core? 
>>>
>>> Well, since Pd is an open source project that relies on community effort, 
>>> and this is the list of its main developers and users, I guess this is the 
>>> place to talk about a collaboration and see if we can get Pd-extended's 
>>> development
>>> to continue.
>>>
>>> I'd to help in any way I can.
>>>
>>> Cheers
>>
>> 
>> 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
> 
> 
> ___
> 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

Re: [PD] Updated pd-extended

[Jonathan Wilkes via 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-requ...@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


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated pd-extended

[Phil Stone]

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" > 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-requ...@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




--
Phil Stone
Programmer - Application Development Team
Information Technology
UC Davis School of Veterinary Medicine
530-752-5282 (o)

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated pd-extended

[Ivica Bukvic]

True. It is trying to be to many things-- an ensemble and a software portal.
On Sep 23, 2014 12:04 PM, "Dan Wilcox"  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  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"  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  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"  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-requ...@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
>>> cou

Re: [PD] Updated pd-extended

[Dan Wilcox]

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  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"  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  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"  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-requ...@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 li

Re: [PD] Updated pd-extended

[Ivica Bukvic]

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"  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  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"  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-requ...@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://li

Re: [PD] Updated pd-extended

[Dan Wilcox]

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  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"  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-requ...@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





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management

Re: [PD] Updated pd-extended

[Ivica Bukvic]

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"  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-requ...@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
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated pd-extended

[Dan Wilcox]

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-requ...@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

Re: [PD] Updated pd-extended

[puredata]

Hi,

Would do anything to finally include mtl abstractions to pd-extended.  
I can build on Windows, Mac, Linux & the RPI.


Will try to poke Hans about the code diffs on #dataflow. Should we  
(anyone interested in updating pd-extended) have a chat (irc, hangout,  
whatever). I am sure Hans will be willing to gives 30 minutes to help  
us help him.


Let's bang it.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated pd-extended

[Jonathan Wilkes via Pd-list]

On 09/21/2014 05:35 PM, Dan Wilcox wrote:

Well, time & money are intertwined.

This is why I was talking about a Pd foundation/organization etc that 
could take donations from schools, organizations, poor artists etc and 
roll it into bounties or development support/residences. Pd has a 
pretty active user base but a much much smaller developer base so it 
makes things a bit harder since there is essentially more pressure on 
these smaller numbers of developers who already have limited time as 
it is.


I know a "foundation" is a huge word to throw around but it could 
literally be one place in the world, probably support by some 
university, that hosts people to work on aspects of Pd. We've already 
had people stepping up to help pay for airfare for the last few Pd 
meetups / patching circles etc, so that could be something similar.


Anyway, it's totally *doable* it always come back to who will do it 
and when.


I'd be happy to help with something like this.

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.


Furthermore, we've got a flag to make a Qt window pop up when starting 
the most recent git version of Pd-l2ork.  We'll incrementally be adding 
the functionality to create Qt canvas windows and draw patches in them 
side-by-side with a functioning tcl/tk gui.


-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated pd-extended

[Dan Wilcox]

Graduate students?

On Sep 22, 2014, at 11:40 AM, Jonathan Wilkes  wrote:

> Kickstarter won't really help you here.  It's possible that it would give 
> some incentive for doing a single release, but how can it sustain that work 
> for the next release, or the one after that?


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

Re: [PD] Updated pd-extended

[Jonathan Wilkes via Pd-list]

Before you pay someone to do it, we need to define what "it" is.

"It" might generally look something like this:
1) Pull from the newest stable upstream code

2) Get it to compile
3) Run the regression tests
4) Make alpha and beta builds, gather reports of bugs, fix bugs, re-run tests
5) Release

So for Pd-extended, one would pull from the newest stable Vanilla source.


To complete #2 and #4, one need build environments for all of Pd-extended's 
target platforms.  Probably the easiest way to achieve that is to partner with 
two other developers-- for example, if one uses Ubuntu, find an OSX person and 
a Windows person who can build Pd on their respective OSes.  (There are guides 
on puredata.info about how to do this for each platform.)


Pd-extended doesn't have any tests AFAICT, so skip that step.

Kickstarter won't really help you here.  It's possible that it would give some 
incentive for doing a single release, but how can it sustain that work for the 
next release, or the one after that?

-Jonathan

On Sunday, September 21, 2014 5:22 PM, me.grimm  wrote:
 


>> it involves time

... or money. 

maybe we revisit the kickstarter (or something else) idea brought forth by 
jonathon a few years ago and just pay someone to do it. to me it seems like 1) 
none of us really have any money (im just assuming here we are all poor 
artists) and more importantly 2) none of us really have any time and those that 
do might not have the skills.

OR maybe we have another PDCon (remember that?) to get amped up and pump 
something out

m


On Sun, Sep 21, 2014 at 1:44 PM, Dan Wilcox  wrote:

I talked to Hans about this a bit. In essence, it involves bringing in the new 
pd vanilla source and making sure the Pd-extended additions/modifications 
aren't lost. With the updates/cleanups to the tcl/tk sources a few years ago 
(great work Hans et al!), it should be alot easier than the previous extended 
releases. But still, *easy* or not, it involves time.
>
>
>On Sep 21, 2014, at 6:00 AM, pd-list-requ...@lists.iem.at wrote:
>
>From: Alexandre Torres Porres 
>>
>>Subject: Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended
>>
>>Date: September 20, 2014 at 5:02:59 PM EDT
>>
>>To: Billy Stiltner 
>>
>>Cc: "pd-list@lists.iem.at" 
>>
>>
>>
>>I wish I knew something about coding to help out with its development :P I do 
>>care a lot about it though and wish I could help in some other way. 
>>
>>
>>I do see a few problems with extended, but they're basically related to some 
>>of the externals and libraries that sometimes do not work as they should, 
>>have bad and messy help files and are sometimes redundanct. If welcome, I 
>>could help sharing my thoughts and two cents about that, but I realize those 
>>are not actual bug fixes regarding the code, so it's not a priority on its to 
>>do list and issues for being updated to another release.
>>
>>
>>Anyway, while were at it, what kind of work exactly do you mean someone would 
>>have to do? I suppose there is a great list of bug fixes just to keep it 
>>basically what it is. Given the context, I'm not assuming any big to do list 
>>for some new features agenda. But besidesthe bug fixes, how hard is it for 
>>someone to just update to the latest vanilla core? 
>>
>>
>>Well, since Pd is an open source project that relies on community effort, and 
>>this is the list of its main developers and users, I guess this is the place 
>>to talk about a collaboration and see if we can get Pd-extended's 
>>developmentto continue.
>>
>>
>>I'd to help in any way I can.
>>
>>
>>Cheers
>
>
>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
>
>


-- 

m.e.grimm | m.f.a | ed.m.
megr...@gmail.com
_ 
___
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

Re: [PD] Updated pd-extended

[Miller Puckette]

I remember seeing a series of patches (code diffs I mean) that made the
necessary changes to Pd vanilla to Pd extended - does anyone know if these
still exist?  (I couldn't find them when I looked at the Pd extended SVN
repository a few weeks ago).

Some of them should be in Pd vanilla anyway, and if I took that part on it
would make the rest a lot easier.

cheers
Miller

On Sun, Sep 21, 2014 at 01:44:11PM -0400, Dan Wilcox wrote:
> I talked to Hans about this a bit. In essence, it involves bringing in the 
> new pd vanilla source and making sure the Pd-extended additions/modifications 
> aren't lost. With the updates/cleanups to the tcl/tk sources a few years ago 
> (great work Hans et al!), it should be alot easier than the previous extended 
> releases. But still, *easy* or not, it involves time.
> 
> On Sep 21, 2014, at 6:00 AM, pd-list-requ...@lists.iem.at wrote:
> 
> > From: Alexandre Torres Porres 
> > Subject: Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended
> > Date: September 20, 2014 at 5:02:59 PM EDT
> > To: Billy Stiltner 
> > Cc: "pd-list@lists.iem.at" 
> > 
> > 
> > I wish I knew something about coding to help out with its development :P I 
> > do care a lot about it though and wish I could help in some other way. 
> > 
> > I do see a few problems with extended, but they're basically related to 
> > some of the externals and libraries that sometimes do not work as they 
> > should, have bad and messy help files and are sometimes redundanct. If 
> > welcome, I could help sharing my thoughts and two cents about that, but I 
> > realize those are not actual bug fixes regarding the code, so it's not a 
> > priority on its to do list and issues for being updated to another release.
> > 
> > Anyway, while were at it, what kind of work exactly do you mean someone 
> > would have to do? I suppose there is a great list of bug fixes just to keep 
> > it basically what it is. Given the context, I'm not assuming any big to do 
> > list for some new features agenda. But besidesthe bug fixes, how hard is it 
> > for someone to just update to the latest vanilla core? 
> > 
> > Well, since Pd is an open source project that relies on community effort, 
> > and this is the list of its main developers and users, I guess this is the 
> > place to talk about a collaboration and see if we can get Pd-extended's 
> > development
> > to continue.
> > 
> > I'd to help in any way I can.
> > 
> > Cheers
> 
> 
> 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


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated pd-extended

[Dan Wilcox]

Well, time & money are intertwined.

This is why I was talking about a Pd foundation/organization etc that could 
take donations from schools, organizations, poor artists etc and roll it into 
bounties or development support/residences. Pd has a pretty active user base 
but a much much smaller developer base so it makes things a bit harder since 
there is essentially more pressure on these smaller numbers of developers who 
already have limited time as it is.

I know a "foundation" is a huge word to throw around but it could literally be 
one place in the world, probably support by some university, that hosts people 
to work on aspects of Pd. We've already had people stepping up to help pay for 
airfare for the last few Pd meetups / patching circles etc, so that could be 
something similar.

Anyway, it's totally *doable* it always come back to who will do it and when.

On Sep 21, 2014, at 5:19 PM, me.grimm  wrote:

> >> it involves time
> 
> ... or money. 
> 
> maybe we revisit the kickstarter (or something else) idea brought forth by 
> jonathon a few years ago and just pay someone to do it. to me it seems like 
> 1) none of us really have any money (im just assuming here we are all poor 
> artists) and more importantly 2) none of us really have any time and those 
> that do might not have the skills.
> 
> OR maybe we have another PDCon (remember that?) to get amped up and pump 
> something out
> 
> m
> 
> On Sun, Sep 21, 2014 at 1:44 PM, Dan Wilcox  wrote:
> I talked to Hans about this a bit. In essence, it involves bringing in the 
> new pd vanilla source and making sure the Pd-extended additions/modifications 
> aren't lost. With the updates/cleanups to the tcl/tk sources a few years ago 
> (great work Hans et al!), it should be alot easier than the previous extended 
> releases. But still, *easy* or not, it involves time.
> 
> On Sep 21, 2014, at 6:00 AM, pd-list-requ...@lists.iem.at wrote:
> 
>> From: Alexandre Torres Porres 
>> Subject: Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended
>> Date: September 20, 2014 at 5:02:59 PM EDT
>> To: Billy Stiltner 
>> Cc: "pd-list@lists.iem.at" 
>> 
>> 
>> I wish I knew something about coding to help out with its development :P I 
>> do care a lot about it though and wish I could help in some other way. 
>> 
>> I do see a few problems with extended, but they're basically related to some 
>> of the externals and libraries that sometimes do not work as they should, 
>> have bad and messy help files and are sometimes redundanct. If welcome, I 
>> could help sharing my thoughts and two cents about that, but I realize those 
>> are not actual bug fixes regarding the code, so it's not a priority on its 
>> to do list and issues for being updated to another release.
>> 
>> Anyway, while were at it, what kind of work exactly do you mean someone 
>> would have to do? I suppose there is a great list of bug fixes just to keep 
>> it basically what it is. Given the context, I'm not assuming any big to do 
>> list for some new features agenda. But besidesthe bug fixes, how hard is it 
>> for someone to just update to the latest vanilla core? 
>> 
>> Well, since Pd is an open source project that relies on community effort, 
>> and this is the list of its main developers and users, I guess this is the 
>> place to talk about a collaboration and see if we can get Pd-extended's 
>> development
>> to continue.
>> 
>> I'd to help in any way I can.
>> 
>> Cheers
> 
> 
> 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
> 
> 
> 
> 
> -- 
> 
> m.e.grimm | m.f.a | ed.m.
> megr...@gmail.com
> _


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

Re: [PD] Updated pd-extended

[me.grimm]

>> it involves time

... or money.

maybe we revisit the kickstarter (or something else) idea brought forth by
jonathon a few years ago and just pay someone to do it. to me it seems like
1) none of us really have any money (im just assuming here we are all poor
artists) and more importantly 2) none of us really have any time and those
that do might not have the skills.

OR maybe we have another PDCon (remember that?) to get amped up and pump
something out

m

On Sun, Sep 21, 2014 at 1:44 PM, Dan Wilcox  wrote:

> I talked to Hans about this a bit. In essence, it involves bringing in the
> new pd vanilla source and making sure the Pd-extended
> additions/modifications aren't lost. With the updates/cleanups to the
> tcl/tk sources a few years ago (great work Hans et al!), it should be alot
> easier than the previous extended releases. But still, *easy* or not, it
> involves time.
>
> On Sep 21, 2014, at 6:00 AM, pd-list-requ...@lists.iem.at wrote:
>
> *From: *Alexandre Torres Porres 
> *Subject: **Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended*
> *Date: *September 20, 2014 at 5:02:59 PM EDT
> *To: *Billy Stiltner 
> *Cc: *"pd-list@lists.iem.at" 
>
>
> I wish I knew something about coding to help out with its development :P I
> do care a lot about it though and wish I could help in some other way.
>
> I do see a few problems with extended, but they're basically related to
> some of the externals and libraries that sometimes do not work as they
> should, have bad and messy help files and are sometimes redundanct. If
> welcome, I could help sharing my thoughts and two cents about that, but I
> realize those are not actual bug fixes regarding the code, so it's not a
> priority on its to do list and issues for being updated to another release.
>
> Anyway, while were at it, what kind of work exactly do you mean someone
> would have to do? I suppose there is a great list of bug fixes just to keep
> it basically what it is. Given the context, I'm not assuming any big to do
> list for some new features agenda. But besidesthe bug fixes, how hard is it
> for someone to just update to the latest vanilla core?
>
> Well, since Pd is an open source project that relies on community effort,
> and this is the list of its main developers and users, I guess this is the
> place to talk about a collaboration and see if we can get Pd-extended's
> development
> to continue.
>
> I'd to help in any way I can.
>
> Cheers
>
>
> 
> 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
>
>


-- 

m.e.grimm | m.f.a | ed.m.
megr...@gmail.com
_
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated pd-extended

[Dan Wilcox]

I talked to Hans about this a bit. In essence, it involves bringing in the new 
pd vanilla source and making sure the Pd-extended additions/modifications 
aren't lost. With the updates/cleanups to the tcl/tk sources a few years ago 
(great work Hans et al!), it should be alot easier than the previous extended 
releases. But still, *easy* or not, it involves time.

On Sep 21, 2014, at 6:00 AM, pd-list-requ...@lists.iem.at wrote:

> From: Alexandre Torres Porres 
> Subject: Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended
> Date: September 20, 2014 at 5:02:59 PM EDT
> To: Billy Stiltner 
> Cc: "pd-list@lists.iem.at" 
> 
> 
> I wish I knew something about coding to help out with its development :P I do 
> care a lot about it though and wish I could help in some other way. 
> 
> I do see a few problems with extended, but they're basically related to some 
> of the externals and libraries that sometimes do not work as they should, 
> have bad and messy help files and are sometimes redundanct. If welcome, I 
> could help sharing my thoughts and two cents about that, but I realize those 
> are not actual bug fixes regarding the code, so it's not a priority on its to 
> do list and issues for being updated to another release.
> 
> Anyway, while were at it, what kind of work exactly do you mean someone would 
> have to do? I suppose there is a great list of bug fixes just to keep it 
> basically what it is. Given the context, I'm not assuming any big to do list 
> for some new features agenda. But besidesthe bug fixes, how hard is it for 
> someone to just update to the latest vanilla core? 
> 
> Well, since Pd is an open source project that relies on community effort, and 
> this is the list of its main developers and users, I guess this is the place 
> to talk about a collaboration and see if we can get Pd-extended's development
> to continue.
> 
> I'd to help in any way I can.
> 
> Cheers


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

Re: [PD] Updated pd-extended

[IOhannes m zmoelnig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-09-11 12:45, Alessio Degani wrote:
> Hi List,
> 
> I'm new to this list, but a long time user of PD. There is a way to
> keep pd-extended aligned to the current stable release of
> pd-vanilla?

yes: invest manpower.

> I've noticed that pd-extend carries a quite old version of pd, and
> no updates in a while. The official web pages, says that a
> rolling-release pd-extend is on working, but again, no updates
> since alpha released on 01/02/2013 (if I'm not wrong).

maybe.
the latest (unstable) Pd-extended can always be found at:
  http://apt.puredata.info/auto-build/latest/

> 
> Is there a simple'n dirty way to assembly pd-extended from
> pd-vanilla by myself?

depends on what you expect from Pd-extended.
PdX is a slightly modified "pd" binary PLUS a lot of externals.
you cannot get the slightly modified pd core from pd-vanilla.
if you are only interested in the externals, you could copy them over
from a nightly Pd-extended build to your Pd-vanilla installation.

even better would be to just use the debian packages of pd and the
externals you want.

fgmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUEaTvAAoJELZQGcR/ejb4THkP+wXGkpG/yPMx66GIbyJQN1m3
7nA12Z13NoehelC084cI15ZLf8MlFwLvhBCfZ/jCxK4T+GlAxafBLEhdc8ZLmy6p
4BHIEIJ0jgpL3+0v4lYMNqqzh3H8Ihf1UsGSFN9MaRuvXc0tjD1XadeMPkmjdNI9
/RiscnUlLGqwrERDMaO3s5iqbJk7xM6b/bk4nBZy9WNvq3vc+2FDj5vf3xjcL9uv
1eVNhpNlP+hqB7lYWuUZKaUWcGIXXhzNcGU3+V6q6OQ8rb7xZzv2lW+6qXYx5H1m
CmHZJHFXLQo6DmM2wBdKkDozjoXAn3yEBWpx+Buaq86EZPjaaHtHWHRc8hUE7sWC
Y+luU/rcZrDLlQIffkGW1+FIgXD+JrI00hP+hp2C62S/icOk9wtHMFWjO65LyBMD
Ca8cOv4IF4k/dz4l1khXELU8EuquiVSi/alpCvnHyKqvrzqhQK3E5O5YzT5dfv+i
1TOokKDgSS05gus09wwBupZJPcCcDAtXDYlIocJl2+CZjMvF7sdhS6fxHuBI4ffA
OcaNv/Vm2v3qIlDKyWAn3MXAlG4bczU/4+F8Gb2k6Rdt4PAsotu4JhVTjPunmKJd
P+lF/N0qK5Qgf1T1s5gAD5FQbNI/T79OuHSKhfYM9iMiBvYOn6T9hj0lCIMqtYMI
SkrqEPxGwDtrG62B0xZV
=GPYO
-END PGP SIGNATURE-

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list