[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