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 PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
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?
Frank Barknecht _ ______footils.org_ __goto10.org__
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.
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.
Frank Barknecht _ ______footils.org_ __goto10.org__
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:
an error that represents a breach of contract by the user
an error that represents a breach of contract by the implementor
an error whose reporting is required by the contract
an error whose reporting is not specified by a contract, but which exists by necessity
an error that is none of the above
a warning
a notice
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
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?
Frank Barknecht _ ______footils.org_ __goto10.org__
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
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.
Frank Barknecht _ ______footils.org_ __goto10.org__
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
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
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
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
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
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
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
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.
Frank Barknecht _ ______footils.org_ __goto10.org__
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
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
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.
Actually in workshops I like to show [timer] as an example where the hot inlet is not the leftmost inlet, when explaining that practially all other objects have their hot inlet left and why hot and cold is a crucial thing to understand. Somehow I feel, that showing the "wrong" way [timer] works helps students to understand this area of left/right, hot/cold, execution order and triggering a bit better.
That feeling may be wrong of course, though I don't think it is. But that's the problem with feelings.
Frank Barknecht _ ______footils.org_ __goto10.org__
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.)
Frank Barknecht _ ______footils.org_ __goto10.org__
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
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
On Sat, 21 Jul 2007, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
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
On Sat, 21 Jul 2007, Mathieu Bouchard wrote:
On Sat, 21 Jul 2007, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
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
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:
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.
Frank Barknecht _ ______footils.org_ __goto10.org__
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
Mathieu Bouchard wrote:
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...
should we do some magic to avoid threads on PD-announce? i (think that i) could set-up a filter-rule that would automatically catch all emails with the "in-reply-to" header set and reject them.
is this a good idea? are there any caveats? (dunno, but probably somebody wants to post a legit email to pd-announce which is in fact a reply to somebody's mail, e.g. because a thread turned into an announcment)
mfg.asd IOhannes
On Tue, 24 Jul 2007, IOhannes m zmoelnig wrote:
should we do some magic to avoid threads on PD-announce? i (think that i) could set-up a filter-rule that would automatically catch all emails with the "in-reply-to" header set and reject them. is this a good idea? are there any caveats? (dunno, but probably somebody wants to post a legit email to pd-announce which is in fact a reply to somebody's mail, e.g. because a thread turned into an announcment)
Perhaps you could consult the existing pd-announce archives and scan for in-reply-to... Most of the headers are missing from the public archives, but in-reply-to is one of the preserved fields.
zgrep -i in-reply-to 2007-07.txt.gz zgrep -i in-reply-to 2007-06.txt.gz zgrep -i in-reply-to 2007-05.txt.gz ...
will give you an idea of how many mails would be rejected.
An easier way to handle this is to put the whole pd-announce archive in mailbox format and look at it in a mail thread viewer, but this only covers replies to other pd-announce, so you still have to zgrep to figure out in-reply-to relationships with external sources of email.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sat, 21 Jul 2007, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
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.
Frank Barknecht _ ______footils.org_ __goto10.org__
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
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.
Frank Barknecht _ ______footils.org_ __goto10.org__
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
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
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 matju@artengine.ca 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
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
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
On 7/22/07, Thomas Grill gr@grrrr.org 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!
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
On Jul 22, 2007, at 10:51 PM, Mathieu Bouchard wrote:
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.
I think it's a good idea to start exploring how to make Pd a cleaner
language, but there are ways of softening the blow of drastic
changes. One thing that you could do to lighten the impact is to
make a separate library that has your versions of route, pack, etc.
Then if we strip out as much as possible from the Pd core language,
and stick it all into libraries, then it would be quite easy to
switch between the compatible versions and your new versions.
Another option is to use different names.
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | 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
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
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.
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
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