[PD] [PD-announce] the end of type restrictions

[Miller Puckette]

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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list