Re: [PD] Updated Pd-Extended
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
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
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 zmoel...@iem.at 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
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 h...@at.or.at wrote: There were at least two proposals back when the change was made. They're in the archives. I certainly don't remember the details at this point. .hc Jonathan Wilkes wrote: Um... have you actually read the source for DesireData? If someone wants to write me up a nice, concise, friendly non-sarcastic spec about how to change Pd-l2ork's code so that it can be binary compatible with the same features it currently has, I'll be happy to try implementing it. -Jonathan On Thursday, September 25, 2014 12:04 PM, Ivica Bukvic i...@vt.edu wrote: ...As strange as it may sound I must admit I've missed our broken conversations/banter. Welcome back, Hans! Alas, this time I will have to bow out--so many things to do, so little time. Hope you'll understand. Best, Ico On Sep 25, 2014 11:08 AM, Hans-Christoph Steiner h...@at.or.at wrote: You can take an external compiled for the same OS/arch and it loads and works on all of them. .hc Ivica Bukvic wrote: Based on what metrics? On Sep 25, 2014 11:05 AM, Hans-Christoph Steiner 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 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 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
Re: [PD] Updated Pd-Extended
-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
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 zmoel...@iem.at 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
-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
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
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
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 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
Quoting Jonathan Wilkes jancs...@yahoo.com: Now I'm even more confused. In the past you had written this to a query of mine: [...] But now you say the opposite in response to DesireData's _symbol struct which adds a refcount and a symbol size member n. How does the one break binary compatibility but the other does not? i might have been mistaken. the problem remains that as soon as we do add new members to a public struct, somebody *might* use them. and *this* is breaking binary compatibility. e.g. if you external uses (t_symbol*s)-n you cannot run (nor compile) it in Pd-vanilla. if it does not, you still can. if pd-l2ork adds the new members snip unsigned int refcount; unsigned int length; /snip and pd-extended adds the new members: snip unsigned int length; unsigned int refcount; /snip then any external that uses (t_symbol*s)-n will be doomed. mfgasdr IOhannes PS: it would help if you posted a reference to the actual thread (e.g. in the pd-list archives). i had trouble finding my contribution to the thread you posted... ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Updated pd-extended
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; /* refcount0 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
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; /* refcount0 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
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 megr...@gmail.com 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 danomat...@gmail.com 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 por...@gmail.com Subject: Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended Date: September 20, 2014 at 5:02:59 PM EDT To: Billy Stiltner billy.stilt...@gmail.com Cc: pd-list@lists.iem.at 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
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 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 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 danomat...@gmail.com wrote: I disagree. Your example lists what? 2 more developers? I'm talking about developers as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper. I still maintain that the number of low level developers to overall users (non-developers) is relatively low. On Sep 23, 2014, at 6:00 AM, pd-list-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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and
Re: [PD] Updated pd-extended
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 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 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 danomat...@gmail.com wrote: I disagree. Your example lists what? 2 more developers? I'm talking about developers as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper. I still maintain that the number of low level developers to overall users (non-developers) is relatively low. On Sep 23, 2014, at 6:00 AM, pd-list-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 -
Re: [PD] Updated pd-extended
Based on what metrics? On Sep 25, 2014 11:05 AM, Hans-Christoph Steiner 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 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 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 danomat...@gmail.com wrote: I disagree. Your example lists what? 2 more developers? I'm talking about developers as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper. I still maintain that the number of low level developers to overall users (non-developers) is relatively low. On Sep 23, 2014, at 6:00 AM, pd-list-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
Re: [PD] Updated pd-extended
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 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 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 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 danomat...@gmail.com wrote: I disagree. Your example lists what? 2 more developers? I'm talking about developers as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper. I still maintain that the number of low level developers to overall users (non-developers) is relatively low. On Sep 23, 2014, at 6:00 AM, pd-list-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
Re: [PD] Updated pd-extended
...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 h...@at.or.at wrote: You can take an external compiled for the same OS/arch and it loads and works on all of them. .hc Ivica Bukvic wrote: Based on what metrics? On Sep 25, 2014 11:05 AM, Hans-Christoph Steiner 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 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 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 danomat...@gmail.com wrote: I disagree. Your example lists what? 2 more developers? I'm talking about developers as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper. I still maintain that the number of low level developers to overall users (non-developers) is relatively low. On Sep 23, 2014, at 6:00 AM, pd-list-requ...@lists.iem.at wrote: However, your description of the user/developer ratio doesn't ring true to me.
Re: [PD] Updated pd-extended
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 megr...@gmail.com: 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 danomat...@gmail.com 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 por...@gmail.com *Subject: **Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended* *Date: *September 20, 2014 at 5:02:59 PM EDT *To: *Billy Stiltner billy.stilt...@gmail.com *Cc: *pd-list@lists.iem.at 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
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; /* refcount0 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 i...@vt.edu wrote:
...As strange as it may sound I must admit I've missed our broken
conversations/banter. Welcome back, Hans!
Alas, this time I will have to bow out--so many things to do, so
little time. Hope you'll understand.
Best,
Ico
On Sep 25, 2014 11:08 AM, Hans-Christoph Steiner h...@at.or.at
mailto:h...@at.or.at wrote:
You can take an external compiled for the same OS/arch and it
loads and works
on all of them.
.hc
Ivica Bukvic wrote:
Based on what metrics?
On Sep 25, 2014 11:05 AM, Hans-Christoph Steiner
h...@at.or.at 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
h...@at.or.at 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 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
Re: [PD] Updated pd-extended
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; /* refcount0 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
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
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 i...@vt.edu wrote: Well, I guess you can call me a developer, whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned me the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable in any other implementation of presets. Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which allowed us to use a full SVG-based canvas, so I have no doubt we will be able to do this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms and I would argue in turn that will result in faster development. So, if you are really interested in pushing the development of non-vanilla pd I think you should heed some of Jonathan's advice and look for ways how community can work together in combining the best of and engaging developers and developers alike who have shown dedication to the cause. But before that can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate. Best, Ico On Sep 23, 2014 9:21 AM, Dan Wilcox danomat...@gmail.com wrote: I disagree. Your example lists what? 2 more developers? I'm talking about developers as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper. I still maintain that the number of low level developers to overall users (non-developers) is relatively low. On Sep 23, 2014, at 6:00 AM, pd-list-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 - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Updated pd-extended
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 i...@vt.edu wrote: Well, there is a concerted effort on the pd-l2ork side of things. We now technically have 3 devs contributing code regularly to git and 3 additional contributors. On Sep 23, 2014 11:14 AM, Dan Wilcox danomat...@gmail.com wrote: I had to bring up semantics because developer means alot of different things to alot of different people. Also, I didn't want to bring up vanilla versus non-vanilla, just pointing out that the number of people who could help Hans put out a new version of extended is rather low. IMO a languishing extended is bad news for Pd in general as it's the go to distribution for most people using Pd ... but that's probably for another debate. We all work on what's important to us, I'm just sad again to see that the priorities don't seem to match up with a concerted joint effort, at least as compared to my experience working with OpenFrameworks. But of course what's considered a concerted, joint effort is also up to interpretation :D Hopefully we'll have a development meet up at some point soon. I personally feel guilty seeing things like this come up because I have the *ability* to do it, but I don't have the time when trying to balance life, work, art. Honestly, this is when I know I'm probably getting in too deep ... This is why I suggested graduate students. At this point, up keep and versioning should be supported by some sort of institution, if possible, and by people who could be rotated in and out. On Sep 23, 2014, at 10:57 AM, Ivica Bukvic i...@vt.edu wrote: Well, I guess you can call me a developer, whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned me the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable in any other implementation of presets. Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which allowed us to use a full SVG-based canvas, so I have no doubt we will be able to do this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms and I would argue in turn that will result in faster development. So, if you are really interested in pushing the development of non-vanilla pd I think you should heed some of Jonathan's advice and look for ways how community can work together in combining the best of and engaging developers and developers alike who have shown dedication to the cause. But before that can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate. Best, Ico On Sep 23, 2014 9:21 AM, Dan Wilcox danomat...@gmail.com wrote: I disagree. Your example lists what? 2 more developers? I'm talking about developers as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper. I still maintain that the number of low level developers to overall users (non-developers) is relatively low. On Sep 23, 2014, at 6:00 AM, pd-list-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.
Re: [PD] Updated pd-extended
True. It is trying to be to many things-- an ensemble and a software portal. On Sep 23, 2014 12:04 PM, Dan Wilcox danomat...@gmail.com wrote: Yes, this is great news. I didn't mean to sound pessimistic earlier, just realistic. My 2cents, though is that the l2ork website is hard to navigate :D On Sep 23, 2014, at 11:54 AM, Ivica Bukvic i...@vt.edu wrote: Well, there is a concerted effort on the pd-l2ork side of things. We now technically have 3 devs contributing code regularly to git and 3 additional contributors. On Sep 23, 2014 11:14 AM, Dan Wilcox danomat...@gmail.com wrote: I had to bring up semantics because developer means alot of different things to alot of different people. Also, I didn't want to bring up vanilla versus non-vanilla, just pointing out that the number of people who could help Hans put out a new version of extended is rather low. IMO a languishing extended is bad news for Pd in general as it's the go to distribution for most people using Pd ... but that's probably for another debate. We all work on what's important to us, I'm just sad again to see that the priorities don't seem to match up with a concerted joint effort, at least as compared to my experience working with OpenFrameworks. But of course what's considered a concerted, joint effort is also up to interpretation :D Hopefully we'll have a development meet up at some point soon. I personally feel guilty seeing things like this come up because I have the *ability* to do it, but I don't have the time when trying to balance life, work, art. Honestly, this is when I know I'm probably getting in too deep ... This is why I suggested graduate students. At this point, up keep and versioning should be supported by some sort of institution, if possible, and by people who could be rotated in and out. On Sep 23, 2014, at 10:57 AM, Ivica Bukvic i...@vt.edu wrote: Well, I guess you can call me a developer, whatever that means--I don't care that much about titles. Yet, I would argue that as far as low level stuff is concerned in recent years pd-l2ork has certainly pushed the envelope in terms of core development. Even the feature that has earned me the title in quotations delves so deep into the core that currently it cannot be implemented in either vanilla or extended without significant changes even though it retains full backwards compatibility. I would also argue it is essential and offers a slew of features that are unavailable in any other implementation of presets. Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially a conscious decision to allow for faster development while addressing the lack of manpower. But that is about to change once we complete port to Qt library. We already transitioned to Tkpath quite a while ago which allowed us to use a full SVG-based canvas, so I have no doubt we will be able to do this again. Once this is done, we won't have to circumnavigate exceptions Tk library requires in order to be compliant with different platforms and I would argue in turn that will result in faster development. So, if you are really interested in pushing the development of non-vanilla pd I think you should heed some of Jonathan's advice and look for ways how community can work together in combining the best of and engaging developers and developers alike who have shown dedication to the cause. But before that can be accomplished, the community should consider agreeing on design choices. For instance, pd-l2ork came into existence because it focuses on more nimble development at the expense of potential loss of backwards compatibility (even though after 4 years of development the only incompatibility we infatuated is correcting buggy positioning of iemgui objects, which is cosmetic in nature) because a good chunk of that compatibility stems from buggy implementations that stuck around long enough that they became a part of the standard (e.g. iemgui's buggy positioning of objects that are arbitrarily offset from their x and y positions, as reported by the pd script), which is unfortunate. Best, Ico On Sep 23, 2014 9:21 AM, Dan Wilcox danomat...@gmail.com wrote: I disagree. Your example lists what? 2 more developers? I'm talking about developers as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper. I still maintain that the number of low level developers to overall users (non-developers) is relatively low. On Sep 23, 2014, at 6:00 AM, pd-list-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
Re: [PD] Updated pd-extended
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 danomat...@gmail.com mailto:danomat...@gmail.com wrote: I disagree. Your example lists what? 2 more developers? I'm talking about developers as in people working the C code, build scripts, tcl/tk etc aka people who could, theoretically, help push out a new Pd-extended release. True, we have plenty of people working on externals, but this is a problem for someone who can go deeper. I still maintain that the number of low level developers to overall users (non-developers) is relatively low. On Sep 23, 2014, at 6:00 AM, pd-list-requ...@lists.iem.at mailto: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 http://danomatika.com robotcowboy.com http://robotcowboy.com ___ Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- 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
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 mailto: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 http://danomatika.com robotcowboy.com http://robotcowboy.com ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Updated pd-extended
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 por...@gmail.com Subject: Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended Date: September 20, 2014 at 5:02:59 PM EDT To: Billy Stiltner billy.stilt...@gmail.com Cc: pd-list@lists.iem.at 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
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 megr...@gmail.com 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 danomat...@gmail.com 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 por...@gmail.com Subject: Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended Date: September 20, 2014 at 5:02:59 PM EDT To: Billy Stiltner billy.stilt...@gmail.com Cc: pd-list@lists.iem.at 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
Graduate students? On Sep 22, 2014, at 11:40 AM, Jonathan Wilkes jancs...@yahoo.com 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
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 por...@gmail.com Subject: Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended Date: September 20, 2014 at 5:02:59 PM EDT To: Billy Stiltner billy.stilt...@gmail.com Cc: pd-list@lists.iem.at 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
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 danomat...@gmail.com 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 por...@gmail.com *Subject: **Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended* *Date: *September 20, 2014 at 5:02:59 PM EDT *To: *Billy Stiltner billy.stilt...@gmail.com *Cc: *pd-list@lists.iem.at 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
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 megr...@gmail.com 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 danomat...@gmail.com 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 por...@gmail.com Subject: Re: [PD] [Bulk] Re: [Bulk] Re: Updated pd-extended Date: September 20, 2014 at 5:02:59 PM EDT To: Billy Stiltner billy.stilt...@gmail.com Cc: pd-list@lists.iem.at 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
-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
