[PD] data structures......

João Pais jmmmpais at googlemail.com
Sat Nov 29 13:50:25 CET 2014

that's a pity. although you're not the person to ask, are there plans to  
make pdl2ork available on windows?

> Hi Joao,
> Those features won't be available in Pd-extended-- the GUI part depends  
> on a library called tkpath >which Pd-extended doesn't use.
> The tentative plan is to port Pd-l2ork's GUI to Qt, leveraging  
> QGraphicsview or QML.  The features I've >added should be common to any  
> modern 2d API that does "managed" graphics.  That includes Qt, >SVG,  
> probably GTK as well, but unfortunately not Tk.
> -Jonathan
> On Friday, November 28, 2014 5:28 PM, João Pais  
> <jmmmpais at googlemail.com> wrote:
> Hello,
> 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 part).
> 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.
> Best,
> Joao
>> 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/20141129/9f3eaf79/attachment-0001.html>

More information about the Pd-list mailing list