Pd-dev July 2008

pd-dev@lists.iem.at

25 participants
100 discussions

abstractions
by Mathieu Bouchard 16 Jul '08

16 Jul '08

On Mon, 7 Jul 2008, Roman Haefeli wrote: > sorry, if i now seem to be nitpicking, but this is actually what i mean > by 'core classes': the classes, that cover the initial focus of the > library, in the case of gridflow the classes, that do deal with grids. ok. > i don't think, that something hardcoded as [range 8 9 10] in > [#camera]/[pd camera] justifies the use an extra external, if three > [moses] objects cover exaxtly the same. Look, [range] is in use in more abstractions than that, plus in more patches that you can see (unreleased stuff). [#camera] was just one example, and furthermore, [range] was just one example. There is also [route2], [listread], [listfind], and whatever else, that get used in abstractions, and that aren't as straightforward to replace by Miller's builtins. > i rather meant: is it really necessary to have the exact functionality > of [range]? cannot the same be achieved by having some [moses]es here > and there? It's not the point. > different languages provide different ways to deal with issues. And Pd doesn't provide enough when it comes to supporting abstractions in a way that makes them be able to use Pd in a way equivalent to how normal externals can use Pd, and at a price not significantly greater. For example, [#in] and [#out] aren't in such great shape since they became abstractions, and they're significantly more complicated, because even the simplest dynamic patching is complicated. At Pd Convention 2004, there was a nice moment during the papers sessions, where there was an apparent consensus that as many things as possible should be made as abstractions. I still think about that. I like the idea, and I've always liked the idea, and you can trace my appreciation of that idea back to the original design of GridFlow, but it's not always so feasible just by using Pd. > i might be wrong, but i haven't seen a case yet, where [range] would be > the only option to solve a certain problem. Originally [range] was only there so that when I convert jMax patches to Pd patches, I wouldn't have to do elaborate search-and-replaces. Although later on I could have decided to let it go and do things the Pd way, instead I came with the idea that [moses] was not enough and that if [sel] and [route] and such, take multiple number of arguments, [moses] should. In some patches I had to string 8 [moses] together. Anyway, you seem to be on the defensive side... we don't absolutely need [range] so why bother? This is influenced by the fact that it is troublesome to make [range] in the first place, because at the same time it's not possible (or overly difficult) to make an abstraction out of it, and because it's troublesome to even carry portable C code around if it's not already in a very popular distro. If it were easy to make an abstraction, perhaps you wouldn't think like this. Or perhaps you would think like this about [range] anyway, but you wouldn't think like this about another example such as [route2]. > but in this case i am more in favor of repeating [moses]es instead of > introducing another class, that doesn't really cover new possibilities. not much actually covers new possibilities. any abstraction could be just pasted in a patch so that you don't need the abstraction. It's all a matter of how much you're ok with doing that. It's more of a quantitative difference than qualitative. > in this particular case, i also prefer [moses], because it does not > crash, while [range] crashes pd, I don't have (nor remember) that bug. I disavow any version of GridFlow prior to 0.9.2, and frankly, I also don't remember all of the bugs that might have been in 0.9.2 or 0.9.3. If you want to report bugs, do it relative to the last release, 0.9.4, or the SVN. (I uploaded it Friday, just didn't send an announcement yet). > from a developers perspective: why bother with making new code work, > that introduces new problems and needs special attention, if pretty much > the same could be achieved with a bit more effort in the user domain? Exactly. So why bother improving Pd? It's hard, it introduces new problems, and needs special attention. If any possible improvement looks like it could be great, just break down this possible improvement into smaller, more incremental improvements, so that when you look at them individually, any of them looks like it's not worth doing. Looking at the big picture makes one worry, and we shouldn't worry, so let's not look at the big picture. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

10 24

enabling Gem's explicit help-patches (was: Re: Pd-cvs Digest, Vol 41, Issue 12)
by IOhannes m zmoelnig 15 Jul '08

15 Jul '08

pd-cvs-request(a)iem.at wrote: > Date: Fri, 11 Jul 2008 18:05:58 -0700 > From: eighthave(a)users.sourceforge.net > > added back the help symbol prefix and set it as 'Gem/', since it is needed to make the helpfiles work in the current setup > > Modified Paths: > -------------- > branches/pd-extended/v0-40/packages/Makefile > > Modified: branches/pd-extended/v0-40/packages/Makefile > =================================================================== > --- branches/pd-extended/v0-40/packages/Makefile 2008-07-11 14:45:51 UTC (rev 10162) > +++ branches/pd-extended/v0-40/packages/Makefile 2008-07-12 01:05:57 UTC (rev 10163) > @@ -479,15 +479,18 @@ > # always run aclocal/autoconf until "configure" is deleted from CVS > cd $(gem_src)/src && aclocal > cd $(gem_src)/src && autoconf > - cd $(gem_src)/src && ./configure --without-ffmpeg --with-pd=$(pd_src) \ > - --disable-NV > + cd $(gem_src)/src && ./configure \ > + DEFINES='-DHELPSYMBOL -DHELPSYMBOL_BASE="Gem/"' \ > + --without-ffmpeg --with-pd=$(pd_src) --disable-NV > $(MAKE) -C $(gem_src)/src > good try, but unfortunately it doesn't work like this. the "HELPSYMBOL" define is not a boolean, but really the actual help-symbol you request. so even if quoting worked in the attempt (which it does not), what you would get is that all Gem-objects would have the same help-patch "Gem/1" (which would eventually expand to "Gem/1-help"...) i suggest to not mess around with the HELPSYMBOL defines, but rather put the the binary and the reference-files into extra/Gem/. if you want to keep the reference-patches in doc/5.reference/Gem, why not duplicate them for now? fmgasfd.r IOhannes PS: probably trying it locally once before submitting it would have been a good idea :-)

2 1

[ pure-data-Bugs-2005973 ] MacOSX bugs
by SourceForge.net 15 Jul '08

15 Jul '08

Bugs item #2005973, was opened at 2008-06-29 15:36 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005973&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: MacOSX bugs Initial Comment: 1. In big patches sometimes if the screen doesn't fit the whole patch then the titlebar of the opened window is under the mac-top-menu and this gives you only the option to press cmd-w to close this window. You can not move it to see the sections that are out of the screen(in the bottom of the screen in most cases) 2. When you open properties for gui objects then the opened window is placed in a random position and in many cases is placed almost out of the screen(not the titlebar of the properties-window). 3. with you double-click in an object,message,etc the context menu that appears sometimes is appeared in some distance from that object. 4. a wish! ::: a shortcut to connect two objects(their 1st inlet/outlet) and segment cords plz!! ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2008-07-15 02:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-06-30 07:50 Message: Logged In: YES user_id=564396 Originator: NO please do not mix bug-reports and wishlists in this tracker. please report one bug (wishlist, patch,...) per tracker item. else you risk that some minor bug in your list is fixed and the entire ticket is closed... please use a more descriptive title ("bugs" in a "bugtracker" is really generic...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005973&group_…

1 0

[ pure-data-Bugs-2017183 ] renaming 'current' dir causes error on File->Open attem
by SourceForge.net 13 Jul '08

13 Jul '08

Bugs item #2017183, was opened at 2008-07-13 10:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2017183&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: frey (freynz) Assigned to: Nobody/Anonymous (nobody) Summary: renaming 'current' dir causes error on File->Open attem Initial Comment: On Pd 0.40.2 vanilla, 0.41.4-vanilla, and 0.40.3-extended, renaming the directory that Pd thinks is the 'current' directory causes subsequent attempts to call up the Open dialog to fail with the following error: bad directory "/Users/damian/2.current/rj/Track.rj" bad directory "/Users/damian/2.current/rj/Track.rj" while executing "tk_getOpenFile -defaultextension .pd -filetypes { {{pd files} {.pd}} {{max files} {.pat}}} -initialdir $pd_opendir" (procedure "menu_open" line 3) invoked from within "menu_open" (procedure "pdtk_canvas_ctrlkey" line 33) invoked from within "pdtk_canvas_ctrlkey .printout.text o 0" (command bound to event) to reproduce the error: 1. open ~/thing/wossname.pd 2. close the patch. 3. mv ~/thing ~/otherthing 4. File->Open or Ctrl-O/Splodge-O ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2017183&group_…

1 0

[ pure-data-Bugs-1721404 ] xsample lib not loading
by SourceForge.net 13 Jul '08

13 Jul '08

Bugs item #1721404, was opened at 2007-05-18 15:50 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1721404&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: v0.39.2 >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: kyleklip (kyleklip) Assigned to: Thomas Grill (xovo) Summary: xsample lib not loading Initial Comment: The xgroove~ and xplay~ objects are not working for me on Pd-0.39.2-extended-rc2 (OS X 10.4.9). The *.pd_darwin files are in the /extra folder, and other objects are loading fine from there (tested vasp and it loads). Could this be an issue with the actual compiled externals? I know that flext can be a bit tricky on OS X (at least for me). ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2008-07-13 02:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Thomas Grill (xovo) Date: 2008-06-28 18:15 Message: Logged In: YES user_id=350252 Originator: NO I consider that a packaging issue or version mismatch... there's a PD API change from 0.39 to 0.40 iirc, so flext-based objects must be compiled explicitly for either version. ---------------------------------------------------------------------- Comment By: Luke Iannini (lukeiannini) Date: 2007-07-01 23:02 Message: Logged In: YES user_id=1541432 Originator: NO Sorry, that's 392RC4 not 392RC2. ---------------------------------------------------------------------- Comment By: Luke Iannini (lukeiannini) Date: 2007-07-01 23:01 Message: Logged In: YES user_id=1541432 Originator: NO Hi all, These are working fine for me on both 392RC2 (out of the box) and 0.40.2 autobuilds (though 0.40.2 does not have it loading by default in the plist) on Mac/Intel 10.4.10. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-05-29 03:35 Message: Logged In: YES user_id=27104 Originator: NO For the flext-based externals, Pd-extended just includes the binaries built by Thomas Grill, which were downloaded from his site: http://grrrr.org/ext/beta/pd/osx/ Pd-0.39.2-extended-rc2 has the latest from that site. Other than that, I don't know much about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1721404&group_…

1 0

removing string types from pd-extended release
by Hans-Christoph Steiner 11 Jul '08

11 Jul '08

Hey, We talked about this in the recent past. Could someone who knows the details remove the declarations of the string type from branches/pd- extended/0.40? Or shall I just remove the whole patch? I want to include string support, but using the technique that IOhannes laid out, which should be possible without patching Pd (AFAIK). .hc ------------------------------------------------------------------------ ---- Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli

5 13

urlloader, a web-based abstraction loader
by Stephen Sinclair 11 Jul '08

11 Jul '08

Hello, I have just submitted patch #, which implements a new loader for Pd. This allows one to specify in a patch a "base URL" in which missing abstractions are expected to be found. The loader downloads an index at each listed URL, and if it knows about an abstraction that hasn't yet been loaded, it will download the patch file to a cache and open it from there. This is an idea I've been toying with for a while, and I've given it some consideration on several levels. I'm not even convinced it's a great idea, but I think it's something some people might be interested in. Lately I haven't had time to work on it, but I've got it working well enough that perhaps I should publish it before it starts to just stagnate in my home folder. I thought I should just send a follow-up email explaining how to use it and expanding on some of the points listed in the patch comments: First, to test the patch you'll need to do a few things. 1) Get it compiled and loaded. The code is in externals/loaders/urlloader. Put it in your startup path and make sure it gets loaded. (pd should post some messages when it is loaded.) You'll need the libcurl-dev package installed. 2) Make the files accessible through http. There is a directory under /urlloader called /remote. These files must go to a web server. For testing, I have a local Apache running on my laptop, and the files are hosted at http://localhost/pd. The /pd folder is just a symlink from /var/www/pd to the /remote folder. Note that the test patch (test.pd) points to this location, so if you decide to use a different location, you'll have to modify it. 3) Sign the patches in the remote folder. The urlloader requires GPG to work (more on this below). So you'll need to have gpg working to test this code. If you have a gpg key, use it, otherwise make one. (Not hard.) You want files ending in .asc, so issue these two commands: gpg -b --armor -s unknown.pd gpg -b --armor -s another.pd 4) Open test.pd It should open the test patch, and then the [another] and [unknown] objects should be instantiated. Open them and you'll see that the actual location of the files is in a cache directory in your /home folder. Some points: - Requires GPG to verify downloaded patches before loading them. Since this patch essentially allows code downloaded from a website to run locally on your machine, it can obviously be a screaming security risk. Therefore I did not want to publish this code before implementing this feature. However, it's got a few ugly user interface implications. Of course not everyone knows how to use GPG (I learned how just for this actually). But also, what if you don't have the key to verify a signature? Currently it just 'posts' this to the pd window, and you have to go download it. The person publishing the abstractions must provide their public key for this purpose. You then have to manually import it into your keyring with 'gpg --import'. - Also verifies the files MD5 sums I think this is probably redundant with the GPG stuff mentioned above. Originally I was just going to use the MD5 sum of a file to verify its integrity. However, I realized that trust issues go much deeper than that, since a loaded abstraction can easily specify another URL and then download patches from the new location. You wouldn't want your computer automatically following and downloading anything it sees, so I saw it as a necessity to support some kind of trust infrastructure. But I left the MD5 code in the patch for now anyways. The pd.index file that sits in /remote is just the output of the 'md5sum' command. On the TODO list: - Port to non-Linux operating systems. Currently I developed this on Ubuntu. It should be portable to other systems, provided libcurl and gpg work there. - Determine proper caching rules. Currently patches are cached for 100 seconds, then downloaded again after the expire. This is just for testing purposes. In real-world a more intelligent caching system would be necessary. (That might be a good use of the MD5 sum in the index file, now that I think about it.) - Aliases for URLs which could be prepended to object names. (e.g., urlA:myobject) If more than one URL has the same object listed, the first one will be downloaded, which may as well be considered undeterministic to the user. It would be nice to support a way for the user to specify what URL an object belongs to. Using some kind of alias prepended to the object name might be a way of doing it, with the alias specified in the [baseurl] object. In fact, these should be related only to the canvas the [baseurl] objects reside in, whereas right now everything is pretty much global. (It would probably require modification of the g_list data structure, if I understand right.) - Deal sanely with versioning. (support svn URLs?) This brings up a problem with versions. What if a patch is designed that depends on an abstraction at some server, but then the owner of that server makes an incompatible change which breaks the person's patch. It would be nice to support some kind of versioning, so you could say not only, 'this patch depends on xyz', but 'this patch depends on version 2.5 of xyz'. I was thinking that one way to support this might be to include support for subversion URLs, or at least websvn, so that specific versions of files would be downloaded, but still easily updated to a newer version. - Determine whether this is even a good idea. I'm not completely convinced that downloading patches and running them directly is the best way to deal with abstractions hosted in the 'cloud'. It might be better to have a coherent and trusted repository system like APT. Please try it and give some feedback. If you'd like me to commit this work to the svn, please feel free to grant me access, though I'll likely continue developing it on my own either way. Steve

2 3

[ pure-data-Bugs-2013351 ] pdpedia broken
by SourceForge.net 10 Jul '08

10 Jul '08

Bugs item #2013351, was opened at 2008-07-08 07:03 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2013351&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pdpedia Group: None >Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Hans-Christoph Steiner (eighthave) Summary: pdpedia broken Initial Comment: pdpedia is currently broken. only the entry page (http://wiki.puredata.info) works, all other pages (e.g. http://wiki.puredata.info/en/) will fail with failed to open stream: Permission denied in /Library/WebServer/VirtualHosts/pdpedia/htdocs/en/LocalSettings.php ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-10 15:48 Message: Logged In: YES user_id=27104 Originator: NO it's back, it was down due to a problematic OS upgrade. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2013351&group_…

1 0

Re: [PD-dev] [ pure-data-Bugs-2004979 ] hid defaults to debugging (flood of "hid_get_events")
by Hans-Christoph Steiner 10 Jul '08

10 Jul '08

On Jul 8, 2008, at 10:43 PM, yves degoyon wrote: > Hans-Christoph Steiner wrote: >> >> On Jun 29, 2008, at 2:53 PM, Frank Barknecht wrote: >> >> >>> Hallo, >>> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: >>> >>> >>>> On Jun 29, 2008, at 2:10 PM, Frank Barknecht wrote: >>>> >>>>> Though there is a larger question lurking here: What should >>>>> trunk be >>>>> and how should bug reporters check, if a bug may be already >>>>> fixed? Or >>>>> in short: What is the reference repository: some branches or the >>>>> trunk? To me, trunk was that reference version (and for the >>>>> record: to >>>>> me it is for bug reports regarding my stuff, unless the reports >>>>> are >>>>> branch-specific). But if you regard pd-extended branches as >>>>> reference >>>>> for your externals, I'll take note of that for future reports. >>>>> >>>> Trunk is the reference, but during a release cycle, I am following >>>> the practice laid out by a number of other projects of focusing all >>>> my work on the release branch. Then once the release is done, I'll >>>> merge those changes into trunk. Otherwise, it is a lot of work >>>> maintaining changes in two branches at the same time. >>>> >>> That's perfectly fine. Maybe I should rephrase the question to: When >>> to close bugs? >>> >>> If I encounter a bug, I first update my checkout to the latest >>> version >>> of the trunk, recompile, and if the bug still is there, I go to the >>> bug report page and look, if there is an open bug report >>> regarding it. >>> Mabye I'll also search the mailing list. In this case I didn't >>> find a >>> bug report, and in the archive I saw you asking for a report. So >>> I sat >>> down and wrote one. It was closed some minutes later because >>> there is >>> a branch that doesn't have the bug anymore. >>> >>> Now someone else may come along, do the same thing as I did, but now >>> there is no open bug report anymore so she may go through the same >>> procedure again. >>> >>> Anyway, no need to further pursue this issue in this petty case, but >>> in general I'd prefer if bug reports would stay open until they are >>> fixed in the main branch i.e. the trunk to avoid duplicate reports. >>> >> Bug reports should be closed when they don't need any more >> attention. > > gosh, this is 'wooden tong' talk > frank is perfectly right to ask what is the reference branch, > where, when thing will be fixed, > it's not a game of playing with bug report status, > is where i could find the right version? punto, coma, punto y punto > > don't ignore this please, > i think it's contributing in the overall confusion > > i worked in sofware management too, > and every bug should be closed as 'fixed in version 0.xx an up' > nothing more, > so you don't work that way? > > ya'llah > sevy Perhaps what I propose isn't the best idea. But it takes less work, from what I can see. I am quite overloaded in terms of Pd work so I can't always pay attention to the details. And answering lots of emails with criticism is largely a time sync unless people are going to actually propose something better and not just say what I am doing is bad. Coming up with a workable plan is where the real work is. I would happily follow someone else's plan if they spend the time to consider all of the issues and then keep working on it and documenting it as it is implemented. .hc ------------------------------------------------------------------------ ---- kill your television

1 0

[ pure-data-Patches-2014632 ] urlloader: loader to download abstractions from the web.
by SourceForge.net 10 Jul '08

10 Jul '08

Patches item #2014632, was opened at 2008-07-09 20:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2014632&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Sinclair (radarsat1) Assigned to: Nobody/Anonymous (nobody) Summary: urlloader: loader to download abstractions from the web. Initial Comment: urlloader: Implement a Pd loader to download missing abstractions from a given URL. Uses libcurl for downloading, supporting HTTP and FTP transports. Requires GPG to verify downloaded patches before loading them. Also verifies the files MD5 sums stored in an index file, code taken from binutils. Cached files time out after 100 seconds, currently hard coded in a #define. TODO: - Port to non-Linux operating systems. - MD5 checking is probably redundant to GPG signature verification. - Handle missing signatures better. - Determine proper caching rules. - Aliases for URLs which could be prepended to object names. (e.g., urlA:myobject) - Determine whether this is even a good idea. - Deal sanely with versioning. (support svn URLs?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2014632&group_…

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev July 2008