something i have thought for a LONG time, and i guess a few others have too.
They are just too hard to use.
but they keep popping up in updates to pd, so it seems they are still being worked on.
couldn't that work be put to better use?
like, for instance, on a native PD state saving system???
On 11/12/2014 09:33 AM, i go bananas wrote:
something i have thought for a LONG time, and i guess a few others have too.
They are just too hard to use.
but they keep popping up in updates to pd, so it seems they are still being worked on.
couldn't that work be put to better use?
Yes, but as far as I can tell only in pd-l2ork, so if you are using vanilla, you got nothing to worry about (in other words, AFAICT no vanilla resources are being used by this aspect).
like, for instance, on a native PD state saving system???
You can always try pd-l2ork's preset_hub and preset_node (it's impossible to port to pd because it requires maintaining of the gl_list stack between operations).
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-l2ork has two internal objects for state-saving called [preset_hub] and [preset_node]. I haven't used them a ton but they seem to handle abstractions and locality gracefully (even without the need for $0).
As far as data structures, my changes hopefully make them easier to use. You can create scalars in object boxes. You can update their appearance by sending messages to [draw]. If you just want a single scalar to visualize something, you can essentially treat it as a kind of simplified 2d Gem. In that case you don't even have to understand about or even use gpointers.
-Jonathan
On Wednesday, November 12, 2014 9:36 AM, i go bananas hard.off@gmail.com wrote:
something i have thought for a LONG time, and i guess a few others have too.
They are just too hard to use.
but they keep popping up in updates to pd, so it seems they are still being worked on.
couldn't that work be put to better use?
like, for instance, on a native PD state saving system???
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Well, Miller has recently added the "text" field to [struct], so he does work on them, too.
-Jonathan
On Wednesday, November 12, 2014 11:59 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Pd-l2ork has two internal objects for state-saving called [preset_hub] and [preset_node]. I haven't used them a ton but they seem to handle abstractions and locality gracefully (even without the need for $0).
As far as data structures, my changes hopefully make them easier to use. You can create scalars in object boxes. You can update their appearance by sending messages to [draw]. If you just want a single scalar to visualize something, you can essentially treat it as a kind of simplified 2d Gem. In that case you don't even have to understand about or even use gpointers.
-Jonathan
On Wednesday, November 12, 2014 9:36 AM, i go bananas hard.off@gmail.com wrote:
something i have thought for a LONG time, and i guess a few others have too.
They are just too hard to use.
but they keep popping up in updates to pd, so it seems they are still being worked on.
couldn't that work be put to better use?
like, for instance, on a native PD state saving system???
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I stand corrected. Apologies for the noise. On Nov 12, 2014 12:19 PM, "Jonathan Wilkes via Pd-list" pd-list@mail.iem.at wrote:
Well, Miller has recently added the "text" field to [struct], so he does work on them, too.
-Jonathan
On Wednesday, November 12, 2014 11:59 AM, Jonathan Wilkes < jancsika@yahoo.com> wrote:
Pd-l2ork has two internal objects for state-saving called [preset_hub] and [preset_node]. I haven't used them a ton but they seem to handle abstractions and locality gracefully (even without the need for $0).
As far as data structures, my changes hopefully make them easier to use. You can create scalars in object boxes. You can update their appearance by sending messages to [draw]. If you just want a single scalar to visualize something, you can essentially treat it as a kind of simplified 2d Gem. In that case you don't even have to understand about or even use gpointers.
-Jonathan
On Wednesday, November 12, 2014 9:36 AM, i go bananas < hard.off@gmail.com> wrote:
something i have thought for a LONG time, and i guess a few others have too.
They are just too hard to use.
but they keep popping up in updates to pd, so it seems they are still being worked on.
couldn't that work be put to better use?
like, for instance, on a native PD state saving system???
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
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@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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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@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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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@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@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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
2014-11-13 13:45 GMT-02:00 Jonathan Wilkes via Pd-list <pd-list@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@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@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@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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@lists.iem.at mailto:pd-list@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@gmail.com <mailto:hard.off@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@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@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 _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
cheers
2014-11-17 2:50 GMT-02:00 Jonathan Wilkes jancsika@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@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@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@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@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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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:
- 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@yahoo.com mailto:jancsika@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, cheersWhat kinds of bugs are you running into? -Jonathan2014-11-13 13:45 GMT-02:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at <mailto:pd-list@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@gmail.com <mailto:hard.off@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@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@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 _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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:
- 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@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, cheersWhat kinds of bugs are you running into?
-Jonathan
2014-11-13 13:45 GMT-02:00 Jonathan Wilkes via Pd-list
pd-list@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@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@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@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
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@googlemail.com> wrote:
#yiv8787092339 body {font-size:13px;}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 possibleoperations. 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:
- 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.
- 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@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@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@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@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@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
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@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 pdobjects, 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:
- 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 causeproblems 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. Thismakes 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 bedecoupled from that behavior.
-Jonathan
cheers
2014-11-17 2:50 GMT-02:00 Jonathan Wilkes jancsika@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, >>>>>cheersWhat kinds of bugs are you running into?
-Jonathan
2014-11-13 13:45 GMT-02:00 Jonathan Wilkes via Pd-list
<pd->>>>>list@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@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@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@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
AFAICT there isn't any technical reason why Pd-l2ork couldn't be built and run on Windows. There might be some Linux-centric theming in the tcl files. But if someone wants to try to get it running on Windows I'll be happy to amend any problem code. -Jonathan
are there any indications somewhere on how to do it?
AFAICT there isn't any technical reason why Pd-l2ork couldn't be built
and run on Windows. There might >be some Linux-centric theming in the
tcl files. But if someone wants to try to get it running on Windows
I'll >be happy to amend any problem code.-Jonathan
Most of the build scripts for extended are still in the pd-l2ork git. It is a relatively simple matter of making sure:
- tkpath builds cleanly on Windows (which it should)
- tkdnd builds ok on Windows (which it should)
- Windows has xapian and tkxapian libraries (which it should)
- and then hunting any stray idiosyncrasies within the pd-l2ork's tk
scripts (there should no more than a few linked to the startup behavior).
Basically, it is a matter of someone spending a bit of time hunting these down and refining scripts as necessary to make everything buildable in as automatic of a way as possible (e.g. on Linux pd-l2ork uses a single command to build the entire monolithic deb or tarball installer).
HTH
Best,
Ico
On 11/29/2014 11:34 AM, João Pais wrote:
are there any indications somewhere on how to do it?
AFAICT there isn't any technical reason why Pd-l2ork couldn't be built and run on Windows. There might be some Linux-centric theming in the tcl files. But if someone wants to try to get it running on Windows I'll be happy to amend any problem code. -Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
re: presets
have refined my own preset system with the new text object. can probably refine further by instead of using predefined group of control values per line or message, to only put control name in message then prepend the $0- to the message text coming from preset file. anyways i used to use list split to read the preset located at line n of preset directory listing, this meant anytime i wanted to change preset using a number or a bang to go to next preset , the preset list had to go through the list split n number of times just to spit out the preset filename. now with the text object, all i gotta do is send it a number and it spits out the text at line n . in the casw of the preset directory file, it is a preset name. there are numerous placea where this comes in handy like for my drumloop collections now i can keep a text object filled with a huge list of drum loops and then browse through the list by index, once the correct loop is located, i can send a bang to open, could probably get fancy with canvas labels and bangs and make a clickable list. same with drum samples, could populate a group of toggles with sample names and then fill up a bank for a drumkit. the drumkit could be saved with all sample names, then the drumkit dir would index names of all drumkuts. updating the index is easy, anytime you save a new preset just update the preset dir text with filename of new preset. i like having the folder hard coded as well as extension.
I can't do any programming, but I could do testing of whatever is
necessary.
Most of the build scripts for extended are still in the pd-l2ork git. It
is a relatively simple matter of making sure:
- tkpath builds cleanly on Windows (which it should)
- tkdnd builds ok on Windows (which it should)
- Windows has xapian and tkxapian libraries (which it should)
- and then hunting any stray idiosyncrasies within the pd-l2ork's tk
scripts (there should no more than a few linked to the startup behavior).
Basically, it is a matter of someone spending a bit of time hunting
these down and refining scripts as necessary to make everything
buildable in as >automatic of a way as possible (e.g. on Linux pd-l2ork
uses a single command to build the entire monolithic deb or tarball
installer).HTH
Yes they were, according to Miller's paper. And then the motivation
stopped after a while... :)
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
:-)
I still want to do something with this, but am stuck as to what to do so (rather than just try things) I'm waiting until I see a clear path forward.
cheers M
On Fri, Nov 28, 2014 at 11:28:49PM +0100, João Pais wrote:
Yes they were, according to Miller's paper. And then the motivation stopped after a while... :)
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 :-)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I was exaggerating - I hope that there will be some developments in that
as well.
Joao
I still want to do something with this, but am stuck as to what to do so (rather than just try things) I'm waiting until I see a clear path forward.
cheers M
On Fri, Nov 28, 2014 at 11:28:49PM +0100, João Pais wrote:
Yes they were, according to Miller's paper. And then the motivation
stopped after a while... :)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
:-)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Billy Stiltner -
i go bananas -
IOhannes m zmölnig -
Ivica Bukvic -
Ivica Ico Bukvic
-
Jonathan Wilkes -
João Pais -
Miller Puckette