[PD] data structures......

João Pais jmmmpais at googlemail.com
Fri Nov 28 23:28:51 CET 2014


I haven't been using Pd regularly for a while now. But as I remember, the  
biggest disadvantage of data structures isn't really that they're "buggy"  
(i.e. have some issues that usually don't happen in other pd objects, as  
Jonathan listed), but that there are very few possible operations. Any  
patching requires lots of work to do things that on other parts of Pd  
happen very easily. Looking at the ftm library, could be a way of a goal  
of what could be done using data structues (not even to mention the audio  

Also, because of the gui issues, data structures can't really be relied  
upon for non-slow (i.e. medium and fast) graphics. It just takes lots of  
cpu (at least it does on my windows machines).

There is also the steep learning curve, but I've seen gradually more  
people working with them, so that generates a positive loop. I don't know  
if my tutorial helped much (based on the ones of F Barknecht and G  
Karman), but every step counts.
One can also have a look at my abstractions in extra/jmmmp, several of  
them are made with data structures - including [matrixctrl], quite useful  
as a gui for [iemmatrix/mtx_mul~].
(btw, I was just trying to upload my tutorial to puredata.info, but the  
website gave an error. I'll keep trying)

Jonathan, when will your new features be available in Pd Extended? I could  
try to update my tutorial with them. I'm not using linux anymore, so I  
won't be working with pdl2ork.



> On 11/23/2014 11:26 PM, Alexandre Torres Porres wrote:
>> don't even remember cause I stopped messing with it because of them,  
>> but I did discuss about them sometime ago here on the >>list, with joão  
>> pais, the bottom line is that they were indeed buggy like that and that  
>> you had to cope with it.
> Well, there are a few areas I can think of:
> 1) changing contents of [struct] when you have scalars in a canvas.  Pd  
> goes through and conforms the scalars to the new [struct] definition,  
> >but the old definition sticks around, too.  This seems to cause  
> problems in some cases, and possibly crashes when you have array fields  
> inside >the [struct]-- especially if you make changes to the [struct]  
> for that array.
> 2) scalars inside a gop.  These are prone to all kinds of weirdness,  
> though it's unclear what constitutes a bug here:
> * there's a red gop rectangle for putting objects which you want to show  
> up on the parent, but scalars get scaled and displaced as a function of  
> >subpatch's window dimensions and x/y ranges/sizes.  This makes it  
> difficult to tell where the scalar will appear inside the gop, as well  
> as blasting >the scalar off into the nether regions of the subpatch if  
> you decide to turn on gop.
> * iemguis outside of the gop rectangle won't show up, but scalars will
> * while the gop rectangle does not affect the appearance of a scalar, it  
> _does_ affect the scalar's widgetbehavior.  Thus you can click a scalar  
> >only if it's within the gop boundaries.  You can drag a scalar outside  
> of the boundaries, but once you release the button you can't drag it  
> back.  >(Same with a "Put" menu array.)
> * text appearance is limited by tk canvas implementation.  So the x/y  
> units setting of a gop canvas will affect polygon appearance, but the  
> text >itself won't rescale at all.
> * canvas "clear" method clears out the gop settings (at least I think it  
> does).  The "coords" and "donecanvasdialog" methods take an enormous  
> >list of positional arguments that are impossible to remember
> * x/y margins apparently have no effect on scalars, although Pd lets you  
> set them
> It's difficult to figure out how to make that scalar behavior in gops  
> more sensible.  It's tricky because gop currently acts like a "viewport"  
> >somewhat in the svg or opengl sense, yet it doesn't clip or even  
> respect the "size" attributes if the subpatch is open.  "Put" menu array  
> sizing >and [table] widgetbehavior are affected by this, so if scalar  
> gop appearance were simplified then garrays would have to be decoupled  
> from that >behavior.
> -Jonathan
>> cheers
>> 2014-11-17 2:50 GMT-02:00 Jonathan Wilkes <jancsika at yahoo.com>:
>>>>>> On 11/16/2014 10:55 PM, Alexandre Torres Porres wrote:
>>>> my two cents is that the data structures are still a bit buggy to  
>>>> work on. Just hoped they'd be more stable, other >>>>than that, can't  
>>>> relate to the commotion, cheers
>>> What kinds of bugs are you running into?
>>> -Jonathan
>>>> 2014-11-13 13:45 GMT-02:00 Jonathan Wilkes via Pd-list  
>>>> <pd-list at lists.iem.at>:
>>>>> It's certainly possible.  There's a Pd-l2ork script for creating a  
>>>>> "vanilla" tarball >>>>>with the l2ork changes in it, so I guess you  
>>>>> could try dropping the src and extra >>>>>from that into libpd's  
>>>>> pure-data directory and see what happens.
>>>>> But I don't know much about libpd.
>>>>>>>>>> -Jonathan
>>>>> On Thursday, November 13, 2014 4:38 AM, i go bananas  
>>>>> <hard.off at gmail.com> >>>>>wrote:
>>>>> in relation to Pd-l2ork,
>>>>>>>>>> guys, what's the status of having a 'libpd' for l2ork???  is  
>>>>>>>>>> that possible?
>>>>>>>>>> sorry for going off topic...but it is something i have wanted  
>>>>>>>>>> to ask for ages.
>>>>> On Thu, Nov 13, 2014 at 6:33 PM, i go bananas <hard.off at gmail.com>  
>>>>> >>>>>wrote:
>>>>>> IOhannes,  
>>>>>> that's kinda what i thought....
>>>>>> but really, come on...pd's interface is it's weakest point.  When  
>>>>>> miller started >>>>>>working on the data structures, libpd and all  
>>>>>> that didn't even exist.  But now, >>>>>>we can just farm out that  
>>>>>> sort of stuff to other programs.  
>>>>>> Compared to the amount of effort it takes to learn them, and how  
>>>>>> effective >>>>>>they actually are, data structures are just too  
>>>>>> un-economical.
>>>>>> in nearly 15 years of their existence, i think i can still count on  
>>>>>> both hands >>>>>>how many good implementations of them i have seen.
>>>>>> look, i LOVE pd and couldn't live without it....but it just seems  
>>>>>> like any minute >>>>>>spent on data structures is a minute that  
>>>>>> could be way better spent on other >>>>>>stuff.
>>>>>> On Thu, Nov 13, 2014 at 3:54 AM, IOhannes m zmölnig  
>>>>>> >>>>>><zmoelnig at iem.at> wrote:
>>>>>>> On 11/12/2014 03:33 PM, i go bananas wrote:
>>>>>>>> couldn't that work be put to better use?
>>>>>>> depends on your definition of "better".
>>>>>>> if i understand correctly, "data structures" have been _the_  
>>>>>>> motivation
>>>>>>> for writing Pd (as opposed to continue with max), so i think we  
>>>>>>> owe them :-)
>>>>>>> gfmrdsa
>>>>>>> IOhannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141128/7f2a9fab/attachment-0001.html>

More information about the Pd-list mailing list