[PD] deken auto-unzip on Windows WAS: deken install user experience
I'm sure there is a way. A quick check shows me that there is are a couple of options for unzipping with Tcl: http://wiki.tcl.tk/17433 https://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/zip/decode.html That should just be included in either the deken plugin, or the pd windows build. .hc Matt Barber: > Users on the Facebook group have complained that on Windows they have to > take the extra step of unzipping. Is there a way to include a simple > windows binary with Pd that would decompress automatically? > > On Wed, Jun 8, 2016 at 8:00 AM, IOhannes m zmoelnig <zmoel...@iem.at> wrote: > >> On 2016-06-08 12:09, Hans-Christoph Steiner wrote: >>> >>> I'd >>> like to find a little time to contribute to it, to smooth out the user >> >> cool. >> welcome back. >> >>> >>> * hide all incompatible library version by default (e.g. hide OSX and >>> Windows versions on GNU/Linux) >> >> this is what we are currently doing. >> all incompatible versions are sorted after the compatible ones, and >> (more importantly) they are greyed out. >> they are still selectable though. >> >>> >>> * by default, install into user's pd externals folder without any prompt >>> (~/pd-externals, etc) >> >> hmm, well: there has been a lot of discussion on this list about which >> approach should be taken. >> >> a short (probably biased) recap (but you'll find more detailed reasoning >> in the archives): >> - originally, deken would try to download/install into the externals >> folder (as your suggestion). it would even try to create this folder, in >> case it was not there yet. >> this was rejected, as many people very much dislike applications >> creating folders in their home directory (~/pd-externals). >> - a second iteration did the same, but without trying to create any >> directories. if no writable folder was found, deken would prompt the >> user for a target directory) >> this was rejected because people have very different opinions about the >> scope of downloaded externals (per-user, per-project, per-pd). >> - a third iteration added a big button to manually set the directory >> before downloading stuff (and otherwise would try the standard search >> paths first). >> this was rejected because it was not obvious. (which only shows that i'm >> a bad UI designer) >> - the fourth iteration went for simplicity and prompted the user where >> to install. >> >> currently, Pd-vanilla uses the 4th iteration, wheras deken upstream >> still uses the 3rd iteration. >> >> >>> >>> * add "Advanced Mode" or "Expert Mode" that shows the current user >>> experience >>> >>> * remember which mode the user has selected across pd starts (e.g. make >>> a pref) >> >> yes, many more things should be user-settable, not just two basic modes. >> e.g. >> directory-selection: >> - [ ] ask every time >> - [x] ask once per Pd process >> - [ ] choose automatically from existing search-paths >> - [ ] choose automatically, possibly creating default locations >> >> as for search results, i was thinking about switching to a tree-view, >> where only the most recent version of a found library would be shown by >> default; but opening the (sub)tree, you would see all the older versions. >> the wrong-arch results could be grouped together into an "incompatible" >> subtree that is closed by default. >> >> in any case: deken development is somewhat independent of puredata >> itself and is occasionally merged into Pd proper. >> it has it's own bug/feature tracker at [1] and we are happily accepting >> merge requests and contributors. >> >> >> fgmasdr >> IOhannes >> >> >> >> [1] https://github.com/pure-data/deken >> >> >> >> >> >> >> >> ___ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> >> > > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] deken install user experience
I mean completely hide, no trace at all. The way it is now is intimidating. The correct fix IMHO would be to make pd support ~/.local/share/pd-externals on GNU/Linux, then make all platforms install into there by default. .hc IOhannes m zmoelnig: > On 2016-06-08 12:09, Hans-Christoph Steiner wrote: >> >> I'd >> like to find a little time to contribute to it, to smooth out the user > > cool. > welcome back. > >> >> * hide all incompatible library version by default (e.g. hide OSX and >> Windows versions on GNU/Linux) > > this is what we are currently doing. > all incompatible versions are sorted after the compatible ones, and > (more importantly) they are greyed out. > they are still selectable though. > >> >> * by default, install into user's pd externals folder without any prompt >> (~/pd-externals, etc) > > hmm, well: there has been a lot of discussion on this list about which > approach should be taken. > > a short (probably biased) recap (but you'll find more detailed reasoning > in the archives): > - originally, deken would try to download/install into the externals > folder (as your suggestion). it would even try to create this folder, in > case it was not there yet. > this was rejected, as many people very much dislike applications > creating folders in their home directory (~/pd-externals). > - a second iteration did the same, but without trying to create any > directories. if no writable folder was found, deken would prompt the > user for a target directory) > this was rejected because people have very different opinions about the > scope of downloaded externals (per-user, per-project, per-pd). > - a third iteration added a big button to manually set the directory > before downloading stuff (and otherwise would try the standard search > paths first). > this was rejected because it was not obvious. (which only shows that i'm > a bad UI designer) > - the fourth iteration went for simplicity and prompted the user where > to install. > > currently, Pd-vanilla uses the 4th iteration, wheras deken upstream > still uses the 3rd iteration. > > >> >> * add "Advanced Mode" or "Expert Mode" that shows the current user >> experience >> >> * remember which mode the user has selected across pd starts (e.g. make >> a pref) > > yes, many more things should be user-settable, not just two basic modes. > e.g. > directory-selection: > - [ ] ask every time > - [x] ask once per Pd process > - [ ] choose automatically from existing search-paths > - [ ] choose automatically, possibly creating default locations > > as for search results, i was thinking about switching to a tree-view, > where only the most recent version of a found library would be shown by > default; but opening the (sub)tree, you would see all the older versions. > the wrong-arch results could be grouped together into an "incompatible" > subtree that is closed by default. > > in any case: deken development is somewhat independent of puredata > itself and is occasionally merged into Pd proper. > it has it's own bug/feature tracker at [1] and we are happily accepting > merge requests and contributors. > > > fgmasdr > IOhannes > > > > [1] https://github.com/pure-data/deken > > > > > > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] deken install user experience
I'm just trying deken for the first time, awesome piece of work! I'd like to find a little time to contribute to it, to smooth out the user experience for newbies. I can see there are all sorts of use cases for all of the install options that it currently provides, but it is pretty confusing for most people who just want to use a library. I don't want to step on any toes, so I thought I'd throw out some ideas here: * hide all incompatible library version by default (e.g. hide OSX and Windows versions on GNU/Linux) * by default, install into user's pd externals folder without any prompt (~/pd-externals, etc) * add "Advanced Mode" or "Expert Mode" that shows the current user experience * remember which mode the user has selected across pd starts (e.g. make a pref) .hc ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Window menu
A Window menu is a very common pattern for apps. For example, in OSX Mail where I'm typing this email it has a Window menu with Minimize, Zoom, etc. There are many things in apps that are just standard and should be left that way. With Pd, you need to consider lots of platforms: GNOME, KDE, XFCE, Windows, OSX, etc. .hc On Nov 10, 2015, at 3:01 AM, Jonathan Wilkes via Pd-list wrote: > Hi list, > Does anyone use the Window menu? > > I've never used it or its keybindings. If no one else needs it I'm going to > remove > it in the GUI port. > > -Jonathan > > ___ > 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] Update cyclone maintenance
About maintaining cyclone, I think a reorg would be great, and further maintenance as well. If you want to do whatever you want with it, then just make a fork and work on it as a new name. If you want to stick to cyclone's central goal of Max/MSP compatibility, then keep working on it as cyclone. But please do not work on cyclone and break the Max/MSP compatibility. .hc Alexandre Torres Porres: About the [rampsmooth~], I see the new object is corrected, great! One thing though, I just realized how it has no audio signal inlets for the arguments!!! It was supposed to have them, just like [slide~] does. cheers 2015-06-07 7:28 GMT-03:00 Fred Jan Kraan fjkr...@xs4all.nl: Hi Jan, Thanks for pointing this out. I had seen the logic juggling with RAMPSMOOTH_GEOMETRIC and RAMPSMOOTH_LINEAR, but hadn't came to the conclusion the default behaviour was incorrect. I changed the code for now, but could make the change possible at run-time, as it was intended. But as we already have [slide~] for this, it is not very needed. Greetings, Fred Jan On 2015-06-07 11:33 AM, Jan Baumgart wrote: Actually, the linear version is already in cyclone's code. You can choose at compile time by not setting #define RAMPSMOOTH_GEOMETRIC cheers, jan On 06/06/2015 10:26 PM, Alexandre Torres Porres wrote: I have another bug to report, now in [rampsmooth~]. According to its help file, it should generate a linear ramp, but it doesn't. Instead, it generates a logarithmic curve just like [slide~]. I have attached a picture that shows how both are operating in the same way, where they shouldn't. In MAX, [rampsmooth~] does in fact generate a perfectly linear ramp, unlike [slide~]. I was actually able to implement [slide~] only with [fexpr~], making it 100% compatible to vanilla. If there's a filter formula tht generates perfectly linear ramps I can implement it I guess, but it should be fairly easy to change it in the object. I'll see what I can do to help. cheers 2015-06-05 18:08 GMT-03:00 Dan Wilcox danomat...@gmail.com mailto:danomat...@gmail.com: [m_scale] is an abstraction ... Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres por...@gmail.com mailto:por...@gmail.com wrote: Yeah, I already built it with expr, so I don't really need to download etxernals for that. I was just wondering if extended already had such a thing, and it doesn't, so I think it's a nice addon to cyclone. An addon to cyclone would implicate and addon to extended, but then, it's not clear it'll ever be maintained again. Last time anyone talked about it in this list was 6 months ago... one way or another, seems like a nice addon to cyclone. Maybe it could be just an abstraction and it doesn't have to be a compiled object, I see the point. But I'd like to try and code it as an external into the cyclone library if possible. cheers 2015-06-05 17:50 GMT-03:00 Dan Wilcox danomat...@gmail.com mailto:danomat...@gmail.com: See [m_scale] in rjlib: https://github.com/rjdj/rjlib/tree/master/rj Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/ On Jun 5, 2015, at 4:35 PM, pd-list-requ...@lists.iem.at mailto:pd-list-requ...@lists.iem.at wrote: *From:*Alexandre Torres Porres por...@gmail.com mailto:por...@gmail.com *Subject:**Re: [PD] Update cyclone maintenance* *Date:*June 5, 2015 at 4:34:55 PM EDT *To:*Fred Jan Kraan fjkr...@xs4all.nl mailto:fjkr...@xs4all.nl *Cc:*pd-list@lists.iem.at mailto:pd-list@lists.iem.at pd-list@lists.iem.at mailto:pd-list@lists.iem.at I'm voting for a new [scale] and [scale~] object in cyclone, the second is missing completely in extended, the first is around, but in different versions, like [maxlib/scale], which has a log option, and is actually buggy, and the [expr_scale], which is just an expr abstraction. Seems like very simple externals to make and I could go ahead and code them. I think they'd be really useful. For example, [scale~] would be essential to adjust the amplitude range from LFOs to control your patches. the [scale] would be good for adjusting MIDI input. cheers ___ 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] Updating Pd-Extended
Pd-extended is in need of a new maintainer. Obviously, I can't keep up these days. I'm happy to help anyone get up to speed. .hc On Dec 24, 2014, at 2:00 PM, João Pais wrote: Hello list, I wanted to ask, what is the current state of the pd-extended distribution? Pd-vanilla has had some regular updates recently (some of them with interesting developments), but the latest pd-ext version is still from almost 2 years ago. Best, jmmmp ___ 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
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] [Bulk] Re: [Bulk] Re: Updated pd-extended
These are the kinds of work that needs to be done in Pd-extended: * update the libraries to the latest version, and test them * 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). * fix platform-specific bugs * 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). Code contributions are of course key. For people who don't do C, another way of getting work done is raising money to pay someone to do it. I'm happy to advise anyone who wants to take any of this on. Feel free to ping me directly to point me to threads here, since I don't check this list very often. .hc Alexandre Torres Porres wrote: 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 2014-09-20 2:08 GMT-03:00 Billy Stiltner billy.stilt...@gmail.com: i get u 2 obi hans kinobis mixed up On Fri, Sep 19, 2014 at 11:56 PM, Hans-Christoph Steiner h...@at.or.at wrote: IOhannes m zmoelnig wrote: On 2014-09-16 05:36, Alexandre Torres Porres wrote: as long as we're on the subject, I'm noticing this seems to be the biggest version difference, it's 3 generations behind (0.43 extended vs 0.46 vanilla). My question is, next release would be 0.44 or would you be able to skip right to 0.46? If the idea is to follow the order and go to 0.44 next, why is it so important to stick to this sequence? it is not. why do you think it is? most likely the next release of Pd-extended (if that ever happens) will be based on whatever Pd-version is current then. Moreover, what holds pd extended from being updated to the latest versions? Like the original question, would it be possible to just get the extra extended stuff and pack it around vanilla? like in the original question: yes, for *most* externals this will be possible. Pd (and PdX) has a pretty stable API/ABI (i'm saying *most* because you never know; but i expect all externals to keep working). I understand this wouldn't be as simple as that, but you know what I mean... actually, i don't. I wonder if the problem is that there is some to do list in the extended agenda that holds it development and update to the latest versions. i'm an outsider to Pd-extended, so i'm not authorized to answer this. however, my unauthorized answer is: the to do list of the pd-extended agenda is the same as the todo list of the one *single* person who only ever pushed the development of PdX. and this person is currently occupied with earning money to feed their family, so PdX-development has become a minor priority. i guess that Pd-extended development never paid very well. That sums it up pretty well, thanks :) I'd love to see Pd-extended development continue, I have not given up on it, but my time is very limited for that. I think of it more as an extended pause for my contributions. Really the only the preventing another release is someone doing the work. .hc ___ 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] Pd-extended for ARM - where to find the latest versions
This is the build I made for RPi: http://apt.puredata.info/releases/pool/pd-extended_0.43.4~extended1-1~raspbian_wheezy_armhf.deb .hc Ingo wrote: I'm looking for the latest builds of Pd-extended for ARM (Cubietruck). I was checking Index of /auto-build/latest http://autobuild.puredata.info/auto-build/latest/ but there's nothing since 9 months. I'm looking for a version that would run on Lubuntu 12.04. Anything from 0.42.5 up should be working fine for me. I tried adding deb http://apt.puredata.info/releases precise main to /etc/apt/sources.list and did apt-get update It won't install from there using apt-get install pd-extended. Any help or download link is appreciated! Thanks Ingo ___ pd-l...@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
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 - http
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] [Bulk] Re: [Bulk] Re: Updated pd-extended
IOhannes m zmoelnig wrote: On 2014-09-16 05:36, Alexandre Torres Porres wrote: as long as we're on the subject, I'm noticing this seems to be the biggest version difference, it's 3 generations behind (0.43 extended vs 0.46 vanilla). My question is, next release would be 0.44 or would you be able to skip right to 0.46? If the idea is to follow the order and go to 0.44 next, why is it so important to stick to this sequence? it is not. why do you think it is? most likely the next release of Pd-extended (if that ever happens) will be based on whatever Pd-version is current then. Moreover, what holds pd extended from being updated to the latest versions? Like the original question, would it be possible to just get the extra extended stuff and pack it around vanilla? like in the original question: yes, for *most* externals this will be possible. Pd (and PdX) has a pretty stable API/ABI (i'm saying *most* because you never know; but i expect all externals to keep working). I understand this wouldn't be as simple as that, but you know what I mean... actually, i don't. I wonder if the problem is that there is some to do list in the extended agenda that holds it development and update to the latest versions. i'm an outsider to Pd-extended, so i'm not authorized to answer this. however, my unauthorized answer is: the to do list of the pd-extended agenda is the same as the todo list of the one *single* person who only ever pushed the development of PdX. and this person is currently occupied with earning money to feed their family, so PdX-development has become a minor priority. i guess that Pd-extended development never paid very well. That sums it up pretty well, thanks :) I'd love to see Pd-extended development continue, I have not given up on it, but my time is very limited for that. I think of it more as an extended pause for my contributions. Really the only the preventing another release is someone doing the work. .hc ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
