Pd-list July 2007

pd-list@lists.iem.at

148 participants
241 discussions

LPC
by josue moreno 05 Jul '07

05 Jul '07

Hi everyone, i want to know if there is any work done on Pd about LPC, if there isnt, can you suggest any software? Id been trying to get CMix but the link seems to be broke Im on Mac OS X 10.4.8 PPC thanks _________________________________________________________________ Dale rienda suelta a tu tiempo libre. Mil ideas para exprimir tu ocio con MSN Entretenimiento. http://entretenimiento.msn.es/

1 0

trouble with pd 0.40 extended 2007-07-04
by alexandre r. decoupigny 05 Jul '07

05 Jul '07

hey there, i just installed this version on an ibook G4 1.33 Mac OS X Ver. 10.4.2, and the following graphic/display specs: ATI Mobility Radeon 9550: Chipset Model: ATY,M12 Vendor: ATI (0x1002) Basically, when i start Pd i get the following message: libdir loader $Revision: 1.6 $ written by Hans-Christoph Steiner <hans(a)at.or.at> compiled on Jul 4 2007 at 04:12:52 compiled against Pd version 0.40.2.extended-2007-07-04 /Applications/Pd-0.40.2-extended-2007-07-04.app/Contents/Resources/Scripts/../extra/Gem.pd_darwin: dlopen(/Applications/Pd-0.40.2-extended-2007-07-04.app/Contents/Resources/Scripts/../extra/Gem.pd_darwin, 10): Symbol not found: _glFramebufferRenderbufferEXT Referenced from: /Applications/Pd-0.40.2-extended-2007-07-04.app /Contents/Resources/Scripts/../extra/Gem.pd_darwin Expected in: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL Gem: can't load library libdir_loader: added cyclone to the global classpath This is deprecated behavior. libdir_loader: added zexy to the global classpath This is deprecated behavior. libdir_loader: added creb to the global classpath This is deprecated behavior. libdir_loader: added cxc to the global classpath This is deprecated behavior. libdir_loader: added iemlib to the global classpath This is deprecated behavior. libdir_loader: added list-abs to the global classpath This is deprecated behavior. libdir_loader: added mapping to the global classpath This is deprecated behavior. libdir_loader: added markex to the global classpath This is deprecated behavior. libdir_loader: added maxlib to the global classpath This is deprecated behavior. libdir_loader: added memento to the global classpath This is deprecated behavior. libdir_loader: added mjlib to the global classpath This is deprecated behavior. libdir_loader: added motex to the global classpath This is deprecated behavior. libdir_loader: added oscx to the global classpath This is deprecated behavior. libdir_loader: added pddp to the global classpath This is deprecated behavior. libdir_loader: added pdogg to the global classpath This is deprecated behavior. libdir_loader: added pixeltango to the global classpath This is deprecated behavior. libdir_loader: added pmpd to the global classpath This is deprecated behavior. libdir_loader: added rradical to the global classpath This is deprecated behavior. libdir_loader: added sigpack to the global classpath This is deprecated behavior. libdir_loader: added smlib to the global classpath This is deprecated behavior. libdir_loader: added toxy to the global classpath This is deprecated behavior. libdir_loader: added unauthorized to the global classpath This is deprecated behavior. vbap: can't load library libdir_loader: added pan to the global classpath This is deprecated behavior. libdir_loader: added freeverb to the global classpath This is deprecated behavior. libdir_loader: added hcs to the global classpath This is deprecated behavior. libdir_loader: added jmmmp to the global classpath This is deprecated behavior. libdir_loader: added ext13 to the global classpath This is deprecated behavior. libdir_loader: added hardware to the global classpath This is deprecated behavior. libdir_loader: added deprecated to the global classpath This is deprecated behavior. libdir_loader: added flatspace to the global classpath This is deprecated behavior. I already deleted the .org files in the preferences and also all the other older pd versions.. any idea how to sort this one out ? thanks a lot anyways alexandre -- alexandre r. decoupigny www.listeningart.blogspot.com www.myspace.com/alexandredecoupigny Adore Apples. Love Green Apples. http://www.greenpeace.org/apple/

3 3

pdmtl abstractions questions and comments
by Mathieu Bouchard 05 Jul '07

05 Jul '07

On Wed, 4 Jul 2007, Frank wrote: > There is a minor annoaynce with the dot for abstractions ATM because of > an unfixed bug: If you save a new abstraction that already has a dot in > its name like "list.abs" Oh, I thought that this was a feature :) >> Edit the five source files, changing the name in it for something else. Is >> that so impossible? It might not be pretty, but I wouldn't call it >> "impossible". > Well, but then you wouldn't have five objects named [counter] > anymore. Oh, I didn't know that you needed them to still be called [counter] in the end, just that there are 5 classes named [counter] at one point and that something is done to resolve the conflict in some way. If you don't ever instantiate it as just [counter] then you may as well consider the prefix as part of the new name, such that [whoever/counter] is still in some way also a renaming of [counter]. > And of course there is the social problem: How is it decided, which > counter should keep its name? So far, I don't remember anything about a decision committee (of any size) which would consist of pd users. There was some vague mention of democratic processes in the pd developers world, that did not get backed by answers to questions like: who would have the right to vote? would all votes be considered equal? how would votes be conducted? what would the questions be about? As long as no-one attempts to answer those questions then this situation will continue. If no-one attempts it, it might be because the current situation is not so bad or people have resigned themselves to be less picky, whi > However I fear, that they also became a kind of excuse to not think > about developing a way to decide things like "which [counter] to keep". That's one more example of the pattern that people who are the most able to solve the problem are the ones who feel the least affected by the problem. > Of course one could easily overhaul the path windows (and one has to do > it for plain Pd as well) to be able to handle more paths, but the actual > problem is: Why are there so many paths and are they all really > necessary? Because software is released as archive files (.zip or .tar.gz). Those, by convention, are made to contain one big folder; else, someone uncompressing them would create that big folder, to hold the contents of the archive, so that it's easy to know what is in use and easy to remove it, replace it or disable it, just like it's easy to handle a folder. Now, at the same time, people don't want to use fully qualified names. Developers are people, and they make the decision to call an external [list-map] instead of [list-abs/list-map]. Because of this, -path is necessary. The other possibility is a package management system that puts all files together in one tree yet remembers which are part of what. This solves some problems and bring some fresh new ones, such that name conflicts can't be resolved (e.g. there can't be two files named /usr/sbin/sendmail at once...) > I meant: Using [list-abs/list-abs] instead of just [list-abs] is a > kind of bit rot, because the more people use the double or triple > prefix, the more it gets carved into (some) stones and at some point, > users will expect the [list]-abs objects with long names to be > available. Maybe that's not something to call bit rot, but it would be > rotten. ;) The bit-rot, according to previous definitions, would happen when support for extraneous forms of class-names gets removed. I figure that this could happen if a class browser reveals that it really sucks to have each class multiple times under slightly different names, unless there's some way to identify which names are "canonical" and which names are "aliases". In such a case, the class browser could have the ability to hide all aliases, or hide just the unnecessary prefixes. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

1 0

pd interfacing with java
by Mathieu Bouchard 05 Jul '07

05 Jul '07

On Wed, 4 Jul 2007, ruth mccracken wrote: > I want to interface a pd synth with some java apps. > Are there any pd/java interfaces available? > If not, could someone please give me some suggestions or pointers...I searched the pd .info site without much luck. Not everything is on the .info site. You will find what you are looking for at http://www.le-son666.com/software/pdj/ _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

1 0

pdmtl abstractions questions and comments
by Mathieu Bouchard 05 Jul '07

05 Jul '07

On Tue, 3 Jul 2007, Hans wrote: >> b) abstractions that finish with "_" are graphical abstractions. >> Sometimes, we create an abstraction without a gui, then we create a >> gui that wraps the same abstraction. The name of both abstractions >> will be the same, except that the second version will have a "_" >> appended. > This sounds to me that you are exposing the implementation in the > interface. In this case, [hello] vs [hello_] have very different interfaces, because [hello] doesn't have a GUI and [hello_] has one, even though the rest of the interface (inlets/outlets/messages) may be the same. > I disagree that 99% of programming is math, I'd say more like 9%. It's > much more logic than math Math swallowed Logic, back in the 1800's. Not all of Logic, mind you, but at least the specific kind thereof that gets written in computer programs. > "math" is a very broad term very much agreed: many are led to think that math is all about numbers, but in undergrad math a lot of thing is about generic mental structures that you can't assume that they have to do with numbers. Nowadays numbers are just a very usual pattern found in math, not so much the core topic. > If you are interested in the concept of mapping in the musical > instrument context, here is a paper that illustrates the idea > http://citeseer.ist.psu.edu/546217.html While the paper might be relevant in the context in which it was published, music is more than musical interfaces and pd is about more than music or audio. The original concept of mapping that they inspired themselves from, is that inputs gets associated to outputs; outputs depend on inputs; inputs are the things that outputs depend of. It doesn't have directly to do with numbers, but the first examples of mappings that people learn are usually one number input to one number output. The paper mentions multidimensional mappings (many-to-many connections). (usually, one-to-one means "each combination of inputs causes a different combination of outputs" but this is not the case in that paper, where they are actually talking about the number of inputs and outputs) > (written by people in Montreal :): In this paper only 1 of 3 is in Montréal. I say that only because you make it sound like there were several of them, I don't mean it in any chauvinistic kind of way. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

1 0

pdmtl abstractions questions and comments
by Mathieu Bouchard 04 Jul '07

04 Jul '07

Frank a écrit: > Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: >> [...] >> prefix is required. Then I might call it patate/patate_poil.pd, but >> that's redundant, so I remove the folder so that it's just called >> [patate_poil], and then we're back to prefixes. However if pd wasn't >> doing that and if there wasn't [import] then the slash wouldn't be >> anything more than a tilted underscore. So what are those guidelines >> good for? > Actually that is why I didn't yet use directory prefixes Actually see my mail to Patrice Colet (patco) about the mistake in what I wrote. But you seem to have figured out the mistake and figure out what I meant instead: > objects like [list-abs] or [list-moses] are impossible to use in Pd > {without the prefix} anyways, as [abs] and [moses] are builtins. > If someone else does an abstraction collection for lists, I'd say, > "list_" or "list." are two other good choices. So far, Max seems to be using ".", for example "jit."; because of this, I've used the "." prefix but for "lti." classes; actually I also used it for some PureUnity classes, initially like "f." "~." "#." to mean float's, signal's, grid's, in a way that is meant to be used as [$1.hello]. I have changed this to around to [hello.$1] because of pd 0.40 and of personal preference. > Where directory prefixes shine however is for making packages of > externals and abstractions. Pd-extended is the prime example: It can > ship all five [counter] objects, which would be impossible without > subdirectories for each collection. Edit the five source files, changing the name in it for something else. Is that so impossible? It might not be pretty, but I wouldn't call it "impossible". > start to use objects called [list-abs/list-abs] just because for > packaging reasons, list-abs.pd in pd-extended lives in a directory > called "list-abs". Now that's what I call redundancy: Instead of one, we > get two prefixes. At least my help-files still work. I'd call this three prefixes: "list" occurs twice, then "abs" occurs twice, one of which is a prefix for the other one. I usually call this the "Java disease", but I wouldn't want people to think that this is specific to Java or that I call it that way just because of my general dislike of Java. > pdmtl may face a similar or worse problem when people start using > objects with names like [pdmtl/list/op]. Here not only help-files will > be broken, as the help file "list/op-help.pd" uses an object called > [list/op] which is unavailable unless "pdmtl" is in the path. Actually > all objects using [list/x]-objects are broken then! Therefore, whether a folder is intended to be a package (prefix) or a plain folder (that'd go in -path), is something that has to be decided in advance for every folder and has to be stated in some way. I mean, one can get around it, but it causes trouble eventually, because of unability to figure out whether the "real name" of an abstraction is [list/op] or [pdmtl/list/op]. > All this to me seems to kind of pervert what Guenther Geiger actually > intended when suggesting directory prefixes and initiating the > CVS-repository. Actually, it never occurred to me that those two things were related. I think that I joined pd-list shortly after the CVS created, but I don't recall that anyone said (in the last five years of pd-list) that the whole externals/ thingie had to do with Geiger namespaces. So, if anything got perverted, it's quite natural, because the original goals have not been re-stated often enough. > The reality now is, that [flatspace] announces that it is deprecated, I admit that I don't really remember what [flatspace] is, if I ever knew. I think that I largely skipped over it. > and the "Path" window is filled with more entries than it can handle. Apart from what the intention might have been about paths or libs (libdirs), this is not a problem with Hans's work per se, it's a problem in u_main.tk, and it's very possible to fix it: e.g. http://artengine.ca/desiredata/gallery/pdrc_5b.gif and the same user interface also exists for -path and -helppath separately. >> I think that category names have to be figured out pretty quick if people >> are expected to start using the names in backwards-compatible ways. Else >> you get into what is called "bit rot" - a program is not just the contents >> of source files, it's also a set of relationships with its environment, >> and especially, its direct dependencies. > [list-abs/list-abs] is bit-rot. Well, i've only seen the word "bit-rot" to mean things that result from not updating software to changing interfaces (I'm not counting the meaning of it that has to do with physical media). Thus I don't really know what you mean by [list-abs/list-abs] is bit-rot: it's not like your [list-abs] has gone unmaintained for years such that the definition of pd (or what pd is in practice) has changed such that is has become contextually broken or outdated or irrelevant... _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

2 1

bug in [writesf~] (was: Re: [writesf~] sample rate)
by Mathieu Bouchard 04 Jul '07

04 Jul '07

On Tue, 3 Jul 2007, Roman Häfeli wrote: > yesterday, matju helped me investigating in this problem and it turned > out, that 0x400EAC44 is hardcoded for aiff-files in the file > d_soundfile.c on line 700. In DesireData I added this in create_soundfile: while (samplerate >= 0x10000) {aiffhdr->samprate[1]++; samplerate/=2;} aiffhdr->samprate[2] = (long)samplerate>>8; aiffhdr->samprate[3] = (long)samplerate; > it is defined in a variable called 'dogdoo' That name is too clever. I'll have to change it to something stupid, such as "header". _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

1 0

Re: [PD] Sending Data form Max/Msp to PD via upd
by martin.peach＠sympatico.ca 04 Jul '07

04 Jul '07

It should be spelled "udpreceive", udp for "User Datagram Protocol" and "i before e except after c", the rule for strange english spellings. Martin alexandre r. decoupigny wrote: > > thanks martin .. tried it ...little joy ..i have to fix it first.. > one more question though.. are you sure the [mrpeach/updrecieve] is included > in the mac osx version.. or does it need the GEM library ? apart from the > gem library, pd loads all the included > libraries on this machine. But it wont create a [mrpeach/updrecieve] > object.. any clue to what > is wrong here would be magnificient..

1 0

Re: [PD] [GEM] Problems with "homer.avi" and "anim-1.mov" on thesimplest patch
by Javier García 04 Jul '07

04 Jul '07

Sorry, i forgot attaching the file..here it is >From: Javier GarcÃa <tirengarfio(a)hotmail.com> >To: PD-list(a)iem.at >Subject: [PD] [GEM] Problems with "homer.avi" and "anim-1.mov" on >thesimplest patch >Date: Sat, 30 Jun 2007 20:14:57 +0200 > >Hi, > >I can't see correctly "anim-1.mov" or "homer.avi" which is at >/doc/examples/Gem/data/ with the simplest GEM patch to play a movie >(attached). > >It seems something lacks to handle correctly the channels. > >I know there is some wroten about video formats at the Gem's FAQ, but if >they are the Gem's samples I suppose the files are correct. > >Â¿Is the patch uncorrect? Â¿Are the files uncorrect? > > >br. >Javi > >_________________________________________________________________ >Un amor, una aventura, compaÃ±Ãa para un viaje. RegÃstrate gratis en MSN >Amor >& Amistad. http://match.msn.es/match/mt.cfm?pg=channel&tcid=162349 > > >_______________________________________________ >PD-list(a)iem.at mailing list >UNSUBSCRIBE and account-management -> >http://lists.puredata.info/listinfo/pd-list _________________________________________________________________ Un amor, una aventura, compaÃ±Ãa para un viaje. RegÃstrate gratis en MSN Amor & Amistad. http://match.msn.es/match/mt.cfm?pg=channel&tcid=162349

2 2

pdmtl abstractions questions and comments (previously without a subject)
by Thomas O Fredericks 04 Jul '07

04 Jul '07

This a follow up to a few comments and questions sent by Mathieu Bouchard. In this text, Mathieu's comments and questions are preceded by a "M:". My answers are preceded by a "T:". Every subject is separated by a: ******** Please feel free to contribute to this discussion. ******** M: 'several signal classes names end in "_~" instead of "~" for no apparent reason. It seems that some nonsignal classes also end in "_" for no apparent reason.' T: In the http://wiki.dataflow.ws/PdMtlAbstractions/Usage page of the wiki, the "Special characters in abstraction names" section specifies that: a) abstractions that finish with "_~" are graphical signal objects (the only exception to this rule, and this might change, are the abstractions in the gui folder. These abstractions are used to create other "_" abstractions or to help debugging). b) abstractions that finish with "_" are graphical abstractions. Sometimes, we create an abstraction without a gui, then we create a gui that wraps the same abstraction. The name of both abstractions will be the same, except that the second version will have a "_" appended. ******** M: 'some class names are "like-this", some are "like_this", and some are "likethis", for no apparent reason. While this happens in the much less controlled world of pd's externals repository, I would expect more from the pdmtl abstractions' T: Although I prefer abstractions without a "-" or a "_" in their names, others do not. But, since our wiki states that "class names with multiple words in the name should use underscores to separate words (i.e [iem_anything_kernel], [curve_log], [define_loudspeakers], [my_canvas], etc.)", and this follows the http://puredata.info/docs/developer/CodeGuidelines, I will start the conversion of all names so it fits this standard. All abnormal abstractions will be renamed (thanks a lot for the work Mat :) ). ******** M: "I think it's pretty standard that every *-help.pd file has to contain an object of the class that it documents. Breaking this rule by cutting the documentation into that and *- example.pd files seems pointless. It seems even more pointless when the content of both files together is small enough that it would fit very well in one single patch on a small screen. If you're lacking space you can use subpatches, but really, so far, *- example.pd files seems like a superfluous concept." T: This is probably an oversight, please give examples of the erroneous help files. ******** M:- 'it's not obvious that "generate" is only for audio, and there might be lot of other classes outside of "generate" who might be understood like their purpose is to generate something. Especially confusing is the "synth" folder: why is anything of "generate" not in "synth" instead or vice-versa? ' T: I agree. The tern "generate" does not limit itself only to audio, but encompasses a lot of control abstractions. The basic problem was that the list of abstractions in this category was getting way out of hand. We had to find a solution. We asked ourselfs if we only keept control or signal abstractions in the generate category? We decide to spread the control abstractions around the other categories. By the way, we definitely do not want to create a category that ends with a "~" because who wants to instantiate an abstraction with the name generate~/bell~ ? The "synth" folder groups abstractions that are more like "complete" "midi" instruments (or at least try to be). Think of the "generate" category as the building blocks for the "synth" category. If this still seems to confusing, please reply with an alternative. ******** M: 'likewise, what's the difference between "fx" and "transform"? I don't get it.' T: The transformation category groups abstractions that transform stuff with no direct reference to any musical context. The "fx" category groups abstractions that modify signals in a musical context. You can't ask a musician to "repeat~" or "smooth~" his guitar sound. But you can ask him to "delay~", "echo~" or distort it. That's the basic difference between both categories. Is it really confusing? If you still find it confusing, where should we move the abstractions from the "transform" category? ******** M: 'the "math" folder is especially useless. As a math graduate I feel that byour concept of "math" is something that I lost somewhere along my path, or maybe that I never had it. Anyhow, 99% of what I'd call math stuff is outside of the "math" folder, so, what's the point.' T: The problem is that in any programming environment 99% of what you are doing has to do with math. The basic principle behind the categories where to think of them more as verbs, actions or types, instead of categorizing stuff along the c standard (or whatever it could/should be called). The verb, action or type categorization method tries to follow the dataflow method. For example, swap, print, send, receive, select, route, pack, etc are all verbs. That is why I imagined that categories should also follow this scheme. "math" is more of a category for stuff that hasn't found it's proper place yet. What do you think? Should the "number" category be include in "math"? How about "scale","random" or "anal". Tags instead of categories would be much better. ******** M: " _index.pd files don't actually contain a list of the patches in the folder, so why is it called an index?" T: You are obviously not using either of the official pdmtl abstractions help browsers ( hbrowser.pd or hpopup.pd) as they automatically exclude all files that they consider are not help files. One of the "in progress" ideas of the pdmtl abstractions is to exclude from the listing of help files everything that starts with a "_". So what is "_index.pd" for? There is a patch called "pdmtl_indexmaker.pd" in pdmtl's root folder. It scans all the help files, extracts information like the description of the abstraction, comments about it, etc, and then scans for the file "_index.pd" to get the description of the category. The end result gives you what you can find here: http://wiki.dataflow.ws/PdMtlAbstractions/Contents This system makes it VERY easy to list all the abstractions, their categories and descriptions. The whole process of getting the data and updating the web page takes less than a minute. ******** M: 'I see that you don't have a folder named "mapping" yet, but it's written in http://puredata.info/dev/PdLibraries, so I have to ask, what is a mapping? It seems like most object classes have the purpose "to map inputs to outputs". While browsing around in pdmtl abstractions, it seems like the term would apply to most of the stuff. So, what is that for?' T: Hum, so you asking us why we did not include a "mapping" category and then comment that "mapping" useless or too general???!!! if you are looking for something similar to the "mapping" category, you can check pdmtl's "scale" category. -- thomas ouellet fredericks, tof(a)danslchamp.org, montreal, canada > ---------- Forwarded message ---------- > From: Mathieu Bouchard < matju(a)artengine.ca> > Date: 29 juin 2007 14:52 > Subject: [PD] (no subject) > To: pd-list(a)iem.at, Alexandre Quessy < listes(a)sourcelibre.com> > > > On Fri, 29 Jun 2007, Alexandre Quessy wrote: > > > Here are some of my findings about pdmtl: > > * several signal classes names end in "_~" instead of "~" for no apparent > reason. It seems that some nonsignal classes also end in "_" for no > apparent reason. > > * some class names are "like-this", some are "like_this", and some are > "likethis", for no apparent reason. While this happens in the much less > controlled world of pd's externals repository, I would expect more from > the pdmtl abstractions. > > * I think it's pretty standard that every *-help.pd file has to contain > an object of the class that it documents. Breaking this rule by cutting > the documentation into that and *- example.pd files seems pointless. It > seems even more pointless when the content of both files together is > small enough that it would fit very well in one single patch on a small > screen. If you're lacking space you can use subpatches, but really, so > far, *-example.pd files seems like a superfluous concept. > > * it's not obvious that "generate" is only for audio, and there might be > lot of other classes outside of "generate" who might be understood like > their purpose is to generate something. Especially confusing is the > "synth" folder: why is anything of "generate" not in "synth" instead or > vice-versa? > > * likewise, what's the difference between "fx" and "transform"? I don't > get it. > > * the "math" folder is especially useless. As a math graduate I feel that > your concept of "math" is something that I lost somewhere along my > path, or maybe that I never had it. Anyhow, 99% of what I'd call math > stuff is outside of the "math" folder, so, what's the point. > > * _index.pd files don't actually contain a list of the patches in the > folder, so why is it called an index? > > * convert/lightwave2freq doesn't use the correct constant. 2.99792e+08 is > the closest you can write in pd (the exact value is 299792458). > Because of this, this abstraction doesn't do what it advertises. You > may as well round pi to 3.14. > > * I see that you don't have a folder named "mapping" yet, but it's > written in http://puredata.info/dev/PdLibraries, so I have to ask, what > is a mapping? It seems like most object classes have the purpose > "to map inputs to outputs". While browsing around in pdmtl > abstractions, it seems like the term would apply to most of the stuff. > So, what is that for? > > _ _ __ ___ _____ ________ _____________ _____________________ ... > | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada > _______________________________________________ > PD-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > -- > Alexandre Quessy > http://alexandre.quessy.net > http://www.puredata.info/Members/aalex > _______________________________________________ > abs mailing list > abs(a)dataflow.ws > https://dataflow.ws/cgi-bin/mailman/listinfo/abs-dataflow.ws >

2 2

← Newer
1
...
18
19
20
21
22
23
24
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list July 2007