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 <[email protected]
<mailto:[email protected]>>:
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
<[email protected] <mailto:[email protected]>>:
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
<[email protected] <mailto:[email protected]>> 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
<[email protected]> 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
<[email protected]> 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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] <mailto:[email protected]> mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
