[PD-dev] proposed new "list" and "string" atom-types

[carmen]

On Wed, Jul 20, 2005 at 12:07:22PM -0700, Miller Puckette wrote:
> > 
> > How is polymorphism a key feature of Pd ? e.g. why does [pipe] only allows 
> > floats, and not other kinds of atoms ?
> 
> Oops!  I must have been in a hurry that day.  On the dolist it goes.

imo the limitations are of the available atom types, not [pipe] (which is probably my favorite object and amazingly its one of tte internals)

example: because length varies, my sequencer joins lists via an odd delimiter to push through pipe, since afaik there is no other auto-sorting nonlinear message scheduler in PD.. sequence data is actually stored in a list of lists (with yet another unique-or-it-breaks delimiter), like:

   {234 {x 114.0} {vol 0.89} {filename /samples/blahblah.wav} {stretch 0.7} {loop 0.44 0.96}}
  == (in pd-compatible mode):
   234^x|114.0^vol|0.89^filename|/samples/blahblah.wav^stretch|0.7^loop|0.44|0.96

its absolutely imperative that the entire message is pushed around as one chunk, since the namespace of the storage object is often already changed by the time it would want to read it back (say if just a integer array key was sent thru the pipe, without the s2l nonsense) afaik the only other solution to play multiple parts, would involve dynamically creating lots of qlists or structs...ok, so pipe supports fixed-length lists so i could pass the namespace as a symbol and yadda, but is pd not a messaging system, it should allow robust message passing...

 after its fed through pipe and peeled apart off it goes, and everythign works great - symbol-creation overhead, its requisite memleaks, and the requirement of toxy (since the built in GUI sucks) zexy (to get around the flat list limitation) cyclone (for prepend/append) and PDContainer (for storage) aside. and since DSP and arrays are broken on amd64, all the messages are sent off to sooperlooper and OM anyways...of course i'd love to use PD for more than just a host for 3rd party objects...and have sharable patches...i think the biggest move towards this would be embeddable lists, strings, acceptable internal storage objects..and beyond that the ability to create user-supplied views & controllers for the 'data' modeled via patching together struct definitions or what have you.

speaking of which, PDContainer is the most suitable thing to storing data, since it accepts list as array keys, so at least the above message can stored, albeit as a bunch of smaller items..

almost cheers, C