Re: [PD] [PD-announce] the end of type restrictions
On 23 Jul 2007, at 7:03 AM, Thomas Grill wrote: The question for me is rather why desiredata announcements are posted into the PD-list given that the codebase has moved away in a way that makes it impossible to transfer most of the features. Although I find DD an interesting project, it's essentially off-topic for the pd-list. discussion about these differences, with all the reasoning and debate around them, has greatly improved my understanding of Pd, its eccentricities and how to use it - which is the main reason I read this list. I think these discussions have probably helped shape thinking about the future developments in Pd as well, so they are very much on-topic in my view simon ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Tue, 24 Jul 2007, Chris McCormick wrote: So why don't more people do that? Rewrite the code the way [they think] Miller wants instead of forking their own incompatible version of Pd? It's a matter of paradigmatic divergences on how to back up perceived risk with a self-coherent belief system of return-on-investment that accounts for the phenomenology of the aesthetics and anesthetics of the transmutation of computational expressions. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Mon, 23 Jul 2007, Frank Barknecht wrote: Hm, but mostly there is, at least kind of: The hot left-most inlet corresponds to the right-to-left triggering of many objects. Yeah, but I was mostly commenting on internal structure of pd. sending to the left inlet means the same as sending to the object itself; whereas there does not exist a sending from the object itself that is equivalent to sending through a certain outlet, although you can send messages without any outlet, just like what [s] and semicolon messageboxes do, but that's another thing. It's likely because of the nice symmetry in the following common idiom to get inter-onset intervals: [t b b] | | [timer] [timer] (and its relatives to some extent) is an object that is used in a hot-to-cold fashion more often than in the cold-to-hot direction common with most other objects like [pack] etc. What's the problem with just having crossing wires and consistent semantics? Crossing wires have to happen all of the time anyway. I think that what you claim is a common idiom for [timer] is more than correct, as it would only output 0 if plugged the other way, but for [cputime] and [realtime]... I can very well imagine making plenty of them cross-wired, meaning what would've been straight-wired if those objects were more normal. I think that this special inlet ordering does more harm than good. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Sun, 22 Jul 2007, Frank Barknecht wrote: Maybe the Max/MSP reference manual, page 656? Quoting: [...] type of number, converting the input items as necessary). If no argument is typed in, unpack will have two int outlets. Symbol arguments allow symbols to pass through, and change numbers to the empty symbol (). pd's [unpack] does not convert. it says type mismatch. I think that in retrospect, the type declaration could be much more useful if it actually caused conversion, but turning any number to the empty symbol is certainly not conversion. Yes, I know: Pd is not Max and Pd doesn't differentiate ints and floats (here) Just suppose no i is used in Max's [unpack] and no int is passed to it; and suppose no p is used in Pd's [unpack] and no pointer is passed to it; then the essential differences of both [unpack]s should become most obvious. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Sun, 22 Jul 2007, Frank Barknecht wrote: I think, the usefulness, type-checking can have, is obvious, otherwise we wouldn't have C. Of course, sometimes it's a pain, otherwise we wouldn't have other languages. I don't think that the choice of C vs other languages is just a matter of type checking, nor even just a matter of types. The purpose of types is not limited to merely checks. They can also be used for expressing conversions and documentation and contracts and polymorphisms. But to illustrate where the type-checking of [unpack] is useful, see attached patch: If I have an [unpack 0 0 0] in my patch, and after that some math calculations on numbers, then if a symbol message reaches the [unpack 0 0 0], for years now I *know* that the error in my patch has to be somewhere before that unpack. This makes looking for the bug a bit easier and I admit: I'm used to this behaviour of unpack. What you wrote in the patch... I made exactly the same argument to a quite different group of people some years ago. It was about whether or not interfaces should be declared in the program itself and be checked. Ruby people tend to be very much into skipping all type checks. What I didn't think about until yesterday is that if I want to define a method in pd using pd itself, how would i typically do that? well, I would use a [route] as the method dispatcher; then I might use [list] to revert the implicit [list trim] that [route] does; then I have an argument list, which is an actual list. from that I can take $1 $2 $3... using messageboxes or... using [unpack]. Now if one wanted to add typechecking in a location similar to where it usually happens? It probably would be next to [unpack] or inside [unpack]. Your insistence on changing [unpack] itself is what I cannot understand. My first thought was that [unpack]'s job is just to unpack, and that many typechecks in pd occur because of technical limitations that need not exist, or as optimisation tricks that aren't as optional as they could be - e.g. so far, [unpack]'s p takes more RAM, because handling p generally takes more RAM for anything that wants to handle it correctly. I didn't think much of [unpack] being used expressly for the purpose of typechecking. Interestingly, this sort of circumstance happens even with extremely underdeveloped type systems like Pd... 3 atom types (actually 7, but I won't count the 4 that only exist within messageboxes). DesireData is down to only 2 for now, but I'm still planning to go up to 4 (and not 5 as I was saying last year). Yet we're having the same issues with that few atom types as in languages in which there are dozens of types and ability for user-defined types and plenty of actual ubiquitous practice of using the user-defined types. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Sun, 22 Jul 2007, Miller Puckette wrote: But to return to the original question, if my 'improvement' of pack destroys the nice symmetry of pack and unpack arguments, this certainly calls the design of unlack into question, since the only reason its arguments are as they are is that they were designed so in the context of a no-longer-extant pack. Is symmetry so important? Why is it that leftmost inlet is special, not only in terms of implementation (the object _is_ its own left inlet except in case of NOINLET) but also that it is the 'active' inlet for most classes? Because there's no special built-in outlet in those same objects... Why are some classes using the reverse order? [timer], [realtime], [cputime]. For those objects, messages need to be sent left-to-right; the rightmost inlet triggers output. What about [unselect] and [unroute] ? Why can't [send~] and [receive~] be used just like [send] and [receive] and instead of making it many-to-many you added [catch~] and [throw~] that instead has exactly the opposite problem? Where's [tabwrite4] ? ;) _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: On Sun, 22 Jul 2007, Miller Puckette wrote: But to return to the original question, if my 'improvement' of pack destroys the nice symmetry of pack and unpack arguments, this certainly calls the design of unlack into question, since the only reason its arguments are as they are is that they were designed so in the context of a no-longer-extant pack. Is symmetry so important? Why is it that leftmost inlet is special, not only in terms of implementation (the object _is_ its own left inlet except in case of NOINLET) but also that it is the 'active' inlet for most classes? Because there's no special built-in outlet in those same objects... Hm, but mostly there is, at least kind of: The hot left-most inlet corresponds to the right-to-left triggering of many objects. [unpack] | / [pack] will fire only once because of this. In general this convention leads to the oriental right-to-left reading direction one often uses when deciphering Pd-patches. Why are some classes using the reverse order? [timer], [realtime], [cputime]. For those objects, messages need to be sent left-to-right; the rightmost inlet triggers output. It's likely because of the nice symmetry in the following common idiom to get inter-onset intervals: [t b b] | | [timer] [timer] (and its relatives to some extent) is an object that is used in a hot-to-cold fashion more often than in the cold-to-hot direction common with most other objects like [pack] etc. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Sun, 01 Jul 2007, Mathieu Bouchard wrote: On Sat, 30 Jun 2007, Chris McCormick wrote: On Sat, Jun 30, 2007 at 01:29:40PM -0400, Mathieu Bouchard wrote: Anyway, seriously, if you wanted [unpost] as an external for Miller's pd, you can't, because Miller rejected the sys_printhook patch in 2004. Maybe it would go in now that there is this excellent concrete example of being able to catch and process errors in-patch. If it makes sense to you that excellent concrete examples can push new features into pd, I cannot help your case. It doesn't work that way. On Mon, Jul 23, 2007 at 01:51:21AM -0400, Mathieu Bouchard wrote: It's very possible for you to transfer the features. You only have to rewrite the code the way that Miller wants them to be written like. So why don't more people do that? Rewrite the code the way [they think] Miller wants instead of forking their own incompatible version of Pd? Best, Chris. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: [unpack] does not have default values. If you unpack a list of length 2 using [unpack 0 0 0], the last outlet won't be used. The zero is never used as a float. So, if one believes that the type declarations only have to do with former limitations that have been overcome, the actual arguments of [unpack] may be ignored, and instead the actual values of them may be used. Actually a thought occured to me: If the arguments of [unpack] should not also specify their types, why do we have these arguments at all? As I see it, then they would only be there to specify the number of outlets. However using the argument count to specify the outlet count is really awkward IMO, a much better approach (especially when used with abstraction arguments) for this would be to use a number directly to specify the outlet count. So instead of [unpack 0 0 0] an [unpack 3] would create an unpack with 3 outlets for any kind of atom. But as this of course is damn incompatible with old patches, a new class name should be used. A candidate for this would be an unpack method for [list] like [list unpack 3]. Miller already considered a method like this in a comment in x_list.c. Then also a [list pack 3] could be introduced as a type- and default-value-less synonym for [pack 0 0 0] (or [pack e e e]). How does this sound? Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: On Sat, 21 Jul 2007, Frank Barknecht wrote: It's not in my responsibility to decide, if and where people may rely on the ouput of [unpack] and how they use it, but as I see it, [unpack 0 0] is of contract between the patch author and Pd, which states, that this construct will always give nothing but two floats. What is the thing that states it? Maybe the Max/MSP reference manual, page 656? Quoting: Arguments anything Optional. The number of outlets is determined by the number of arguments. The arguments can be any combination of ints, floats, and symbols. The argument specifies the output of the unpack object's outlet; the input type is forced to the outlet type (e.g., outlets that correspond to int or float arguments will always output that type of number, converting the input items as necessary). If no argument is typed in, unpack will have two int outlets. Symbol arguments allow symbols to pass through, and change numbers to the empty symbol (). Yes, I know: Pd is not Max and Pd doesn't differentiate ints and floats (here) and I'm not sure ATM how symbol arguments in Pd's unpack deal with float inputs (I'm far away from a running Pd.) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
Actually a thought occured to me: If the arguments of [unpack] should not also specify their types, why do we have these arguments at all? As I see it, then they would only be there to specify the number of outlets. However using the argument count to specify the outlet count is really awkward IMO, a much better approach (especially when used with abstraction arguments) for this would be to use a number directly to specify the outlet count. I know what you're saying, and I just had to reply: I would not be surprised if the reason it was chosen to use the argument count was simply to ensure that the graphical box was large enough to support the number of specified outlets.. That said, I bet it wouldn't be too difficult to create a new object that behaves as you describe. Maybe call it explode. :) Steve ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
Hallo, Stephen Sinclair hat gesagt: // Stephen Sinclair wrote: I know what you're saying, and I just had to reply: I would not be surprised if the reason it was chosen to use the argument count was simply to ensure that the graphical box was large enough to support the number of specified outlets.. Though in Max this wasn't a problem, as a box's size doesn't depend on the length of its content there, you can resize the box freely. In Pd the common workardound is to just add additional dummy arguments, but you probably have made these already yourself. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Sat, 21 Jul 2007, Frank Barknecht wrote: I was hoping that compatibilty as a goal would be a two-way compatibility: Patches, that were developed on DD would also be running on MSP-Pd, minus some features like faster graphics or special objects like [tracecall] (which would only be like a missing external). missing functionality is missing functionality. It can be missing classes, missing methods, it can be nonsense output such as empty symbols, it's still missing functionality. I don't know why the addition of any classes like [tracecall] [parse] [unparse] [unpost] etc. would be exempt from your two-way requirement. I think that the argument we're having, boils down to whether the type-checking is a real feature of [unpack]. So I conclude that your compatibility is a one-way street, which I think is a pity. Sorry, why does it have to be two-way?... I think that it's a pity that you're asking for two-way. I just find the disappearing or changing meaning of 0 confusing. What have you ever used that meaning for? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: I just find the disappearing or changing meaning of 0 confusing. What have you ever used that meaning for? Well, for making sure, that unpack will give a number at that outlet or nothing there at all. I think, the usefulness, type-checking can have, is obvious, otherwise we wouldn't have C. Of course, sometimes it's a pain, otherwise we wouldn't have other languages. But to illustrate where the type-checking of [unpack] is useful, see attached patch: If I have an [unpack 0 0 0] in my patch, and after that some math calculations on numbers, then if a symbol message reaches the [unpack 0 0 0], for years now I *know* that the error in my patch has to be somewhere before that unpack. This makes looking for the bug a bit easier and I admit: I'm used to this behaviour of unpack. Of course sometimes a type-less unpack-operation is useful as well, but all I'm suggesting is that this should be made in a different object like the proposed [list unpack] and not in [unpack] itself. Your insistence on changing [unpack] itself is what I cannot understand. Bye -- Frank Barknecht _ __footils.org_ __goto10.org__ unpackit.pd Description: application/puredata ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
I'm now quite confused about the purpose and direction of DesireData. When Chun made his presentation at FAVE last year I was very excited. The idea of forking the pd-gui to make a much improved interface that could be used with Pd seemed wonderful, sensible, and needed. Several people asked the question Is this new interface compatible with the existing Pd?, and the answer was an unqualified yes. I've always seen it as a smart move, taking advantage of Millers forsight in designing Pd as a client-server architecture and using that decoupling to improve the interface. I don't even understand why anyone is talking about changing object behaviours, those are part of the server/engine not the interface surely? Is DesireData heading in the direction of being a completely different piece of software incompatible with PureData? Will I still be able to install the DesireData interface and use it with Pd? Why are these great new objects like [tracecall] that Mathieu is building not being added to Pd? On Sun, 22 Jul 2007 14:20:24 -0400 (EDT) Mathieu Bouchard [EMAIL PROTECTED] wrote: On Sat, 21 Jul 2007, Frank Barknecht wrote: I was hoping that compatibilty as a goal would be a two-way compatibility: Patches, that were developed on DD would also be running on MSP-Pd, minus some features like faster graphics or special objects like [tracecall] (which would only be like a missing external). missing functionality is missing functionality. It can be missing classes, missing methods, it can be nonsense output such as empty symbols, it's still missing functionality. I don't know why the addition of any classes like [tracecall] [parse] [unparse] [unpost] etc. would be exempt from your two-way requirement. I think that the argument we're having, boils down to whether the type-checking is a real feature of [unpack]. So I conclude that your compatibility is a one-way street, which I think is a pity. Sorry, why does it have to be two-way?... I think that it's a pity that you're asking for two-way. I just find the disappearing or changing meaning of 0 confusing. What have you ever used that meaning for? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Sun, 22 Jul 2007, Frank Barknecht wrote: Actually a thought occured to me: If the arguments of [unpack] should not also specify their types, why do we have these arguments at all? [...] So instead of [unpack 0 0 0] an [unpack 3] would create an unpack with 3 outlets for any kind of atom. But as this of course is damn incompatible with old patches, a new class name should be used. I have no idea why pd is like that, except that it conveniently enlarges the box as a way to compensate for the problem that the size of the object box isn't taking the number of in/outlets in advance. (DesireData ensures that the box is wide enough, by looking at the number of in/outlets) I agree that changing the behaviour of pd's unpack to be like jmax's, is going to be damn incompatible. A candidate for this would be an unpack method for [list] like [list unpack 3]. So far I agree about [list unpack 3]. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Mon, 23 Jul 2007, Andy Farnell wrote: Will I still be able to install the DesireData interface and use it with Pd? You can't use that user interface with Miller's pd because Miller's pd does not offer the functionality required so that this user interface can be implemented. I've never said that you could use DesireData with Pd - e.g. you can't put pieces of Miller's 0.41 and DesireData together and expect it to work at all. It's *always* been like that. I've always seen it as a smart move, taking advantage of Millers forsight in designing Pd as a client-server architecture and using that decoupling to improve the interface. DesireData's client-server architecture has rather little to do with Miller's. I had to reinvent almost all of it. Basically, I can't see DesireData as taking advantage of that. The client-server design I use is much like jMax's, but transplanted into a Pd/Tcl context. You have to understand it this way: if Pd had been a single-process program, it wouldn't have been any more difficult to turn it into DesireData. I mean that there's hardly any decoupling in Miller's Pd. I don't even understand why anyone is talking about changing object behaviours, those are part of the server/engine not the interface surely? DesireData isn't just about the user interface. Is DesireData heading in the direction of being a completely different piece of software incompatible with PureData? You could drop the sensationalistic language, and actually think about what constitutes incompatibility, and why, and how much, and what you'd get in return, and whether each change is a nice tradeoff or not. Why are these great new objects like [tracecall] that Mathieu is building not being added to Pd? Because they can't. They lack the supporting internal parts. The server/engine of DesireData has been modified so that [tracecall] becomes possible. If you compile [tracecall] as an external, you get: undefined symbol: pd_stack. You can't have [unpost] either, because when I introduced the Pd Console in early 2004, Miller rewrote it so that it doesn't use the sys_printhook feature, because Miller did not want the sys_printhook feature. This is the only essential difference that I can find between Miller's rewrite of the Pd Console and the original Pd Console. This is what he considered to be a cleaner reimplementation of the Pd Console. Now this sys_printhook feature is exactly what [unpost] needs in order to be possible. If you compile [unpost] as an external, you get: undefined symbol: sys_printhook. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
It's lame, but the idea behind the original design of pack/unpack was to have the argument lists look the same. So, to send a variety of (known-type) data down a send/receive channel or whatnot, one could use pack tea for 2 and a corresponding unpack tea for 2. Of course, that in the unpack side, only the types were significant, is stylistically wierd. It just seemed less wierd than any other idea I had at the time. cheers M On Sun, Jul 22, 2007 at 03:41:02PM -0400, Mathieu Bouchard wrote: On Sun, 22 Jul 2007, Frank Barknecht wrote: Actually a thought occured to me: If the arguments of [unpack] should not also specify their types, why do we have these arguments at all? [...] So instead of [unpack 0 0 0] an [unpack 3] would create an unpack with 3 outlets for any kind of atom. But as this of course is damn incompatible with old patches, a new class name should be used. I have no idea why pd is like that, except that it conveniently enlarges the box as a way to compensate for the problem that the size of the object box isn't taking the number of in/outlets in advance. (DesireData ensures that the box is wide enough, by looking at the number of in/outlets) I agree that changing the behaviour of pd's unpack to be like jmax's, is going to be damn incompatible. A candidate for this would be an unpack method for [list] like [list unpack 3]. So far I agree about [list unpack 3]. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - t?l:+1.514.383.3801, Montr?al QC Canada ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
Am 23.07.2007 um 09:54 schrieb Andy Farnell: Why are these great new objects like [tracecall] that Mathieu is building not being added to Pd? The question for me is rather why desiredata announcements are posted into the PD-list given that the codebase has moved away in a way that makes it impossible to transfer most of the features. Although I find DD an interesting project, it's essentially off-topic for the pd-list. best greetings, Thomas ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On 7/22/07, Thomas Grill [EMAIL PROTECTED] wrote: Am 23.07.2007 um 09:54 schrieb Andy Farnell: Why are these great new objects like [tracecall] that Mathieu is building not being added to Pd? The question for me is rather why desiredata announcements are posted into the PD-list given that the codebase has moved away in a way that makes it impossible to transfer most of the features. Although I find DD an interesting project, it's essentially off-topic for the pd-list. Hm, I can't quite agree with that; how would I know about DD if such announcements were not made? DD is still undoubtedly Pd, even with its myriad modifications. I'd very much like to continue being informed about its progress (and sure, I am on the DD list, but again, we do not ban discussion of GEM on the Pd-list). Regardless of the differences in developer opinions (and I think these are made to be more acerbic than necessary, especially for such enjoyable and exciting software, though perhaps I interpret incorrectly), DD is Pd to me! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
Sure enough... It does not work in Pd. I checked and it still worked in Max/FTS vintage 1993, so it's Pd at fault :) M On Sun, Jul 22, 2007 at 05:12:31PM -0400, Mathieu Bouchard wrote: On Sun, 22 Jul 2007, Miller Puckette wrote: It's lame, but the idea behind the original design of pack/unpack was to have the argument lists look the same. So, to send a variety of (known-type) data down a send/receive channel or whatnot, one could use pack tea for 2 and a corresponding unpack tea for 2. error: pack: tea: bad type could you please use an example that actually does not cause an error in your own pd? There's no way to use tea and for as being default values in that context. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - t?l:+1.514.383.3801, Montr?al QC Canada ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Sun, 22 Jul 2007, Miller Puckette wrote: On Sun, Jul 22, 2007 at 05:12:31PM -0400, Mathieu Bouchard wrote: There's no way to use tea and for as being default values in that context. Sure enough... It does not work in Pd. I checked and it still worked in Max/FTS vintage 1993, so it's Pd at fault :) If you implemented that, then how do you feel about the inability of symbols f s p to be used as default values? How do you determine that something like that is Pd's fault?... by opposition to being an improvement in design compared to Max/FTS. I bet that in your absence I could've found a bunch of people who would've thought that this is intentional... perhaps including me. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
But to return to the original question, if my 'improvement' of pack destroys the nice symmetry of pack and unpack arguments, this certainly calls the design of unlack into question, since the only reason its arguments are as they are is that they were designed so in the context of a no-longer-extant pack. On Sun, Jul 22, 2007 at 09:21:38PM -0400, Mathieu Bouchard wrote: On Sun, 22 Jul 2007, Miller Puckette wrote: On Sun, Jul 22, 2007 at 05:12:31PM -0400, Mathieu Bouchard wrote: There's no way to use tea and for as being default values in that context. Sure enough... It does not work in Pd. I checked and it still worked in Max/FTS vintage 1993, so it's Pd at fault :) If you implemented that, then how do you feel about the inability of symbols f s p to be used as default values? How do you determine that something like that is Pd's fault?... by opposition to being an improvement in design compared to Max/FTS. I bet that in your absence I could've found a bunch of people who would've thought that this is intentional... perhaps including me. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - t?l:+1.514.383.3801, Montr?al QC Canada ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Sun, 22 Jul 2007, Thomas Grill wrote: The question for me is rather why desiredata announcements are posted into the PD-list given that the codebase has moved away in a way that makes it impossible to transfer most of the features. Although I find DD an interesting project, it's essentially off-topic for the pd-list. Tell me: is this a mailing-list about pd the language, or about pd the implementation? How do you know that? It's very possible for you to transfer the features. You only have to rewrite the code the way that Miller wants them to be written like. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: http://artengine.ca/desiredata/gallery/unpack-mixed.png Oh, that last one is tricky IMO. Even when you obviously don't care about patch compatibility to other Pds anymore, making [unpack 0 0 0] behave as you suggest may break even old patches and abstractions, that rely on nothing else than a float getting through a 0 in unpack. Why don't you use [unpack a a a] like in trigger? Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
In what case do you rely on using [unpack 0 0 0] except for throwing an error when it receives a symbol? As it was previously suggested on this list, why use anything else than [t a] or [t b]? I think Mathieu's end of type restrictions is a great idea. For example, if you use Max/Msp every so often, you regularly curse at the useless int/float type restriction. Mathieu, you would only need to create a new object that would determine the type of the data (unless your new [route] still does this). For example, I sometimes use [route bang list symbol] to parse data by its type when an abstraction has many different functions attached to the same inlet. -- thomas ouellet fredericks, [EMAIL PROTECTED], montreal, canada On 7/21/07, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: http://artengine.ca/desiredata/gallery/unpack-mixed.png Oh, that last one is tricky IMO. Even when you obviously don't care about patch compatibility to other Pds anymore, making [unpack 0 0 0] behave as you suggest may break even old patches and abstractions, that rely on nothing else than a float getting through a 0 in unpack. Why don't you use [unpack a a a] like in trigger? Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote: In what case do you rely on using [unpack 0 0 0] except for throwing an error when it receives a symbol? As it was previously suggested on this list, why use anything else than [t a] or [t b]? It's not in my responsibility to decide, if and where people may rely on the ouput of [unpack] and how they use it, but as I see it, [unpack 0 0] is of contract between the patch author and Pd, which states, that this construct will always give nothing but two floats. What Matju does is breaking this contract, which I can only explain by assuming, that he doesn't view it as a contract, but views the 0 0 part more as a kind of default value for something like [unpack anything anything]. While I'm a strong subscriber to the [t a b] and nothing else idea and don't use [t f] anymore, I don't think, that [t f] should ever output a symbol, and that's what [unpack 0] seems to do now in DD and that's what I think is wrong. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Sat, 21 Jul 2007, Frank Barknecht wrote: Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: http://artengine.ca/desiredata/gallery/unpack-mixed.png Oh, that last one is tricky IMO. Even when you obviously don't care about patch compatibility to other Pds anymore, Well, I obviously care about compatibility, else I'd be working something completely different than DesireData. The question here is: what is compatibility? (what is it that DesireData has to be compatible with?) If you find anything incompatible with PureData in DesireData at the level of running existing patches, please tell me, I'd like to make a list. Currently the ones that I can think of are the uses of DS/gpointers and Toxy and the GUI externals, but then I make my list with what my conception of compatibility is. making [unpack 0 0 0] behave as you suggest may break even old patches and abstractions, that rely on nothing else than a float getting through a 0 in unpack. Can patches rely on that as a feature any more than they may rely on stack overflow happening at a specific moment rather than any other? I've also made patches that don't produce the same result at all when using 64-bit floats... without using any externs nor anything that anyone would call a bug... Why don't you use [unpack a a a] like in trigger? because a in [trigger] is thought of as anything which is a category of messages, not of atoms. I think that using a here can't have this meaning in this context - actually we could use the letter a here and say that it means atom instead of anything and it would be ok, but I'd rather use another letter in case later some other object needs both a letter for anything and a letter for atom. Then I thought about e for element... _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-announce mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/pd-announce ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Sat, 21 Jul 2007, Mathieu Bouchard wrote: On Sat, 21 Jul 2007, Frank Barknecht wrote: Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: http://artengine.ca/desiredata/gallery/unpack-mixed.png Oh, that last one is tricky IMO. Even when you obviously don't care about patch compatibility to other Pds anymore, Well, I obviously care about compatibility, else I'd be working something completely different than DesireData. The question here is: what is compatibility? (what is it that DesireData has to be compatible with?) Ok, sorry for starting a mail thread on pd-announce, a place where mail threads shouldn't be started. When replying to that mail, don't forget to replace pd-announce by pd-list like what was done for some other mails in the thread... _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-announce mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/pd-announce ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: On Sat, 21 Jul 2007, Frank Barknecht wrote: Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: http://artengine.ca/desiredata/gallery/unpack-mixed.png Oh, that last one is tricky IMO. Even when you obviously don't care about patch compatibility to other Pds anymore, Well, I obviously care about compatibility, else I'd be working something completely different than DesireData. The question here is: what is compatibility? (what is it that DesireData has to be compatible with?) I was hoping that compatibilty as a goal would be a two-way compatibility: Patches, that were developed on DD would also be running on MSP-Pd, minus some features like faster graphics or special objects like [tracecall] (which would only be like a missing external). But now you're changing the behaviour of builtin objects, and not some exotic objects like [polytouchin], but some of the most important objects that show up in every patch. As I see it (though I'm not that familiar with Pd's nor DD's internals) you even do this, when a new object name like [dd_select], [dd_route], would be possible just as as well. So I conclude that your compatibility is a one-way street, which I think is a pity. Why don't you use [unpack a a a] like in trigger? because a in [trigger] is thought of as anything which is a category of messages, not of atoms. I think that using a here can't have this meaning in this context - actually we could use the letter a here and say that it means atom instead of anything and it would be ok, but I'd rather use another letter in case later some other object needs both a letter for anything and a letter for atom. Then I thought about e for element... I think, e would also be fine. I just find the disappearing or changing meaning of 0 confusing. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Sat, 21 Jul 2007, Frank Barknecht wrote: It's not in my responsibility to decide, if and where people may rely on the ouput of [unpack] and how they use it, but as I see it, [unpack 0 0] is of contract between the patch author and Pd, which states, that this construct will always give nothing but two floats. What is the thing that states it? The help file says that types have to be specified, but doesn't say that type checking can be relied upon. The source code only says what is being done right now, not what are the intents and the expectations. We could make abstractions that embody contracts and unit-tests, but unless they come from Miller or are Miller-approved, this can only be a tentative at formalising the distinction between a feature, a limitation, an implementation detail, a bug, etc. If it's not Miller, then it has to be some authority or some sufficiently explicit consensus. If we don't have that, implementing a new feature is a matter of: first do it, then try to gather complaints about it, then try to cook up some ex-post-facto specification from it. The problem with this is that we're never safe, there's always one more opinion that can be contrary to the reconstructed contract and which hasn't been stated yet. What Matju does is breaking this contract, which I can only explain by assuming, that he doesn't view it as a contract, but views the 0 0 part more as a kind of default value for something like [unpack anything anything]. [unpack] does not have default values. If you unpack a list of length 2 using [unpack 0 0 0], the last outlet won't be used. The zero is never used as a float. So, if one believes that the type declarations only have to do with former limitations that have been overcome, the actual arguments of [unpack] may be ignored, and instead the actual values of them may be used. [pack] is a rather different beast, so its case has to be considered separately: it always outputs the same length of list, and it does use its own arguments as defaults, but only if they are floats. While I'm a strong subscriber to the [t a b] and nothing else idea and don't use [t f] anymore, I don't think, that [t f] should ever output a symbol, When something is posted to the console, and it begins with Error: , how do you distinguish between: A) a mistake that the user has to fix, B) a limitation whose existence can't be relied upon, C) just bad luck (connection refused, out of disk space, file not found) And/or another similar question - how do you distinguish between: 1) an error that represents a breach of contract by the user 2) an error that represents a breach of contract by the implementor 3) an error whose reporting is required by the contract 4) an error whose reporting is not specified by a contract, but which exists by necessity 5) an error that is none of the above 6) a warning 7) a notice _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: On Sat, 21 Jul 2007, Mathieu Bouchard wrote: On Sat, 21 Jul 2007, Frank Barknecht wrote: Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: http://artengine.ca/desiredata/gallery/unpack-mixed.png Oh, that last one is tricky IMO. Even when you obviously don't care about patch compatibility to other Pds anymore, Well, I obviously care about compatibility, else I'd be working something completely different than DesireData. The question here is: what is compatibility? (what is it that DesireData has to be compatible with?) Ok, sorry for starting a mail thread on pd-announce And I'm guilty for carrying on. Anyway: You don't need to CC pd-list, if you post to pd-announce, as all pd-announce mails also reach pd-list, where they appear without a To: pd-announce-header then. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Sat, 21 Jul 2007, Frank Barknecht wrote: Ok, sorry for starting a mail thread on pd-announce And I'm guilty for carrying on. Well, the first post was intended as an announcement, and then immediately any people who reply are supposed to figure out that they have to reply to pd-list, so in some sense it wasn't my responsibility to change it, unless I reply to my own mail... but if a replier doesn't do it, then it's still the responsibility of anyone else to only reply in a way that takes the thread off of pd-announce. Does that sound right? Anyway: You don't need to CC pd-list, if you post to pd-announce, as all pd-announce mails also reach pd-list, where they appear without a To: pd-announce-header then. I didn't post to both pd-announce and pd-list; I posted to pd-announce and then you got it on pd-list and then replied to it from that perspective, and this is what caused the To/Cc: to automatically include both pd-list and pd-announce. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] the end of type restrictions
On Sat, 21 Jul 2007, Thomas O Fredericks wrote: In what case do you rely on using [unpack 0 0 0] except for throwing an error when it receives a symbol? As it was previously suggested on this list, why use anything else than [t a] or [t b]? Actually, there is one single use for [t f], which has to do with a distinction that GridFlow needs. Originally, in jMax, a float atom or int atom was something clearly distinct from a list containing only one such atom. In Pd, the distinction is supposed to be ignored but Pd still makes that distinction and GridFlow still uses it because I never thought about any sensible replacement for it. I have a problem with that auto-conversion, especially as there isn't much of any other kind of auto-conversion that ever happens in pd (can you think of anything else like that?). I think Mathieu's end of type restrictions is a great idea. For example, if you use Max/Msp every so often, you regularly curse at the useless int/float type restriction. int-vs-float is just a distinction. An example of a restriction, is to forbid the use of float in an int context. An example of a useless restriction is to get the user to choose between int context float context symbol context pointer context in advance because no any-atom context is offered. The int-vs-float distinction is useful because with ints your counters can go up to 2147483647 whereas with float they can only go up to 16777216, and yet float can handle things than int cannot. Mathieu, you would only need to create a new object that would determine the type of the data (unless your new [route] still does this). The new [route] still does this because it is expected from [route] that using symbol arguments will match the selector of the message; the basic 5 selectors are: bang, float, symbol, pointer, list. (anything is not a selector, it's the collection of all other possible selectors together) For example, I sometimes use [route bang list symbol] to parse data by its type when an abstraction has many different functions attached to the same inlet. The only way that my type restriction removal may affect normal patches, is that it will remove a need to use [route] where it was previously used to work around a restriction; that's an optional change, but I usually jump at every opportunity to make patches simpler to read, understand, explain and modify. (supposing that making a patch less generic doesn't count...) _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] the end of type restrictions
why would [route] and [symbol] be restricted to processing either all floats or all symbols? Why would [unpack] care whether list elements are float vs symbol vs pointer? Well, actually, they don't anymore: http://artengine.ca/desiredata/gallery/route-mixed.png http://artengine.ca/desiredata/gallery/select-mixed.png http://artengine.ca/desiredata/gallery/unpack-mixed.png _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-announce mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/pd-announce ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
