[PD] [PD-announce] the end of type restrictions
matju at artengine.ca
Sat Jul 21 19:59:06 CEST 2007
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
> 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
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
More information about the Pd-list