Re: [PD] Data structures - delete specific scalar?

[Roman Haefeli]

On Sun, 2018-05-20 at 15:31 +0200, Christof Ressi wrote:
> this has been on my wish list for a while and I want to do a PR. do
> you guys have suggestions which kind of interface you would prefer?
> these come to my mind:
> * [delete] object: send it a pointer and it will delete the scalar

I thought this one to be the most natural, since there is also an
[append] object.

> * [delete ( message for canvases

There are no other uses where  a method uses a pointer as argument, are
there?

> * [delete( message for [pointer]: deletes the scalar of the currently
> stored pointer.

Sounds good, too, and seems what has the most thumb-ups yet.

> I tend towards the last option, since [pointer] is already used to
> traverse a subpatch, so [delete( could go well with [traverse(,
> [bang( and [next(. the canvas messages would also makes sense to me.
> having a dedicated object seems rather overkill.

You're probably right.


Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Data structures - delete specific scalar?

[Roman Haefeli]

On Sun, 2018-05-20 at 05:40 -0700, Derek Kwan wrote:
> Roman Haefeli  writes:
> 
> > Hey all
> > 
> > Following up a thread from 2011:
> > https://lists.puredata.info/pipermail/pd-list/2011-04/088306.html

> If I'm not mistaken, this relates to a thread I started in Jan 2017
> and
> I think this bit from Christof Ressi might prove releavant to these
> discussions so hopefully this link could help with the current
> discussion:
> 
> https://lists.puredata.info/pipermail/pd-list/2017-01/117295.html

Oh yes. I didn't find this one when using search machines. This
basically answers my questions. Thanks.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Data structures - delete specific scalar?

[Alexandre Torres Porres]

2018-05-20 10:31 GMT-03:00 Christof Ressi :
>
> * [delete( message for [pointer]: deletes the scalar of the currently
> stored pointer.
>

+1
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Data structures - delete specific scalar?

[Christof Ressi]

that's the hack I've described in link provided by Derek :-)

I think there a two major issues with Pd's GUI:
* the Tk canvas (I believe) doesn't offer any kind of spatial partitioning, so 
it has to check each item if it's visible (or maybe just draws all of them).
  OTOH, Qt offers the QGraphicsScene framework which lets you work with 
thousands of objects quite efficiently (I recently used it for a tile map 
editor and it works really well)
* the collision detection is done in the Pd core, so for every mouse 
interaction the whole glist has to be traversed until the right object is 
found. Pd could use a different data structure to group the objects by position 
but I don't know if it would be worth the effort.

I think the long term goal is to have a completely generic GUI interface and 
let a decent GUI framework handle all the complexity, but the developer willing 
to implement this is yet to be found...

that being said, the Pd GUI works well enough for me most of the time. if it 
doesn't, it probably means it's not the right tool for the job and something 
like PyQt will be the better choice. how does the saying go: "If your only tool 
is a hammer then every problem looks like a nail".


> Gesendet: Sonntag, 20. Mai 2018 um 15:44 Uhr
> Von: "João Pais" <jmmmp...@gmail.com>
> An: pd-list@lists.iem.at, "Ingo Stock" <m...@ingostock.de>
> Betreff: Re: [PD] Data structures - delete specific scalar?
>
> Just thought of this after sending the previous mail. I can't try this  
> hack, but it might work. To delete a scalar:
> - get the scalar's x/y coordinates
> - use mouse messages to select and delete anything over that pixel.
> 
> Drawbacks:
> - will delete anything else over that pixel (affects the selectable area  
> of any scalar)
> - the canvas will need to be traversed again before getting a pointer (as  
> the scalar list will need to be redone)
> 
> It might work, but only under certain circumstances.
> 
> Joao
> 
> > as I recall, in a mail Miller said that it wasn't easy to implement a  
> > "delete" (or "previous" etc.) methods, because it would mix up the  
> > pointer structures. But most likely I'm remembering incorrectly.
> >
> > The lag with scalars is a real thing, as with any other canvas with lots  
> > of gui objects running in tcl/tk - including that in scalars you have  
> > extra lag if you move the mouse over them, even without clicking.  
> > Switching off the mouse detection on demand would make things faster.
> >
> > I have a patch with more than 33548 scalars, and it takes several  
> > minutes to open in my desktop; on my laptop, it just stays there with  
> > cpu at 100% without opening.
> >
> > Best,
> >
> > Joao
> >
> >> Thanks for your testing!
> >>
> >> The lag appears on my computer already with the patch i sent with the
> >> 1050 scalars. It shows when i open the patch, create any object, say a
> >> [float] and try to move it around.
> >>
> >> With more scalars it can become even worse. You can test it with the
> >> attached patch. First select width and height and then click create. It
> >> creates a rectangle made of width x height one-pixel-scalars.
> >>
> >> With about 100 x 100 pixel, clearing the patch becomes increasingly
> >> slow. With 640 x 256 pixel, it took more than nine minutes on my
> >> computer to clear the subpatch or even to close the window, so be  
> >> warned! ;)
> >>
> >> The reason for the lag is afaik, that all interface objects are
> >> constantly redrawn by Tcl, so it is not limited to scalars.
> >>
> >> best, ingo
> >>
> >>
> >> On 05/19/2018 11:23 PM, Roman Haefeli wrote:
> >>> On Sat, 2018-05-19 at 17:00 +0200, Ingo Stock wrote:
> >>>> On 05/19/2018 11:56 AM, Roman Haefeli wrote:
> >>>>> Yeah. It's not very elegant and gets expensive pretty quickly. I
> >>>>> was
> >>>>> wondering about alternative strategies, like moving non-used
> >>>>> scalars
> >>>>> out-of-the-way and later re-use them. It's cumbersome to implement,
> >>>>> but
> >>>>> probably less drastic than the clear-all-and-rebuild method.
> >>>>
> >>>> Can only answer to this: There are several methods to make scalars
> >>>> invisible. Anyhow, in my experience the method to clear the subpatch
> >>>> and
> >>>> recreate everything works quite well and is imho the clean approach
> >>>> to
> >>>> do it, as al

Re: [PD] Data structures - delete specific scalar?

[João Pais]

Just thought of this after sending the previous mail. I can't try this  
hack, but it might work. To delete a scalar:

- get the scalar's x/y coordinates
- use mouse messages to select and delete anything over that pixel.

Drawbacks:
- will delete anything else over that pixel (affects the selectable area  
of any scalar)
- the canvas will need to be traversed again before getting a pointer (as  
the scalar list will need to be redone)


It might work, but only under certain circumstances.

Joao

as I recall, in a mail Miller said that it wasn't easy to implement a  
"delete" (or "previous" etc.) methods, because it would mix up the  
pointer structures. But most likely I'm remembering incorrectly.


The lag with scalars is a real thing, as with any other canvas with lots  
of gui objects running in tcl/tk - including that in scalars you have  
extra lag if you move the mouse over them, even without clicking.  
Switching off the mouse detection on demand would make things faster.


I have a patch with more than 33548 scalars, and it takes several  
minutes to open in my desktop; on my laptop, it just stays there with  
cpu at 100% without opening.


Best,

Joao


Thanks for your testing!

The lag appears on my computer already with the patch i sent with the
1050 scalars. It shows when i open the patch, create any object, say a
[float] and try to move it around.

With more scalars it can become even worse. You can test it with the
attached patch. First select width and height and then click create. It
creates a rectangle made of width x height one-pixel-scalars.

With about 100 x 100 pixel, clearing the patch becomes increasingly
slow. With 640 x 256 pixel, it took more than nine minutes on my
computer to clear the subpatch or even to close the window, so be  
warned! ;)


The reason for the lag is afaik, that all interface objects are
constantly redrawn by Tcl, so it is not limited to scalars.

best, ingo


On 05/19/2018 11:23 PM, Roman Haefeli wrote:

On Sat, 2018-05-19 at 17:00 +0200, Ingo Stock wrote:

On 05/19/2018 11:56 AM, Roman Haefeli wrote:

Yeah. It's not very elegant and gets expensive pretty quickly. I
was
wondering about alternative strategies, like moving non-used
scalars
out-of-the-way and later re-use them. It's cumbersome to implement,
but
probably less drastic than the clear-all-and-rebuild method.


Can only answer to this: There are several methods to make scalars
invisible. Anyhow, in my experience the method to clear the subpatch
and
recreate everything works quite well and is imho the clean approach
to
do it, as all the scalars are redrawn every frame any way.

There are other limits to the use of data structures. Depending on
your
computer, when you get above 800 scalars or so, the patch becomes
laggy.


Thanks for your considerations. That is exactly the kind of info that I
was looking for. I don't share the experience with the limit of 800,
though, but this is presumably related to the computer/CPU.


Consider the attached patch:


Nice and illustrative example patch.


 On load 1050 scalars are created, which is
already quite heavy on my computer.


I'm not sure I understand correctly. Just having the patch open is
heavy on your box? Or interacting with it?


Anyhow, deleting a scalar by
clicking on it works fine, using the clear and redraw method.>>


It works fine for me, too. Then I measured the time it takes to redraw
different numbers of squares. It seems computation time is roughly
proportional to the number of redrawn objects (1: 0.08ms, 500: 3.9ms,
1000: 7.6ms). So there is a penalty of this method with larger numbers
of scalars.


Hiding scalars by making them invisible doesn't help with the lagging
problem. Therefore i would recommend the clear and redraw method any
day. ;)


I don't experience any lags by making specific scalars invisible. It
takes 0.007ms to make a single scalar invisible within a subpatch of
1050 squares. See my modified version of your patch.

Roman


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Data structures - delete specific scalar?

[João Pais]

as I recall, in a mail Miller said that it wasn't easy to implement a  
"delete" (or "previous" etc.) methods, because it would mix up the pointer  
structures. But most likely I'm remembering incorrectly.


The lag with scalars is a real thing, as with any other canvas with lots  
of gui objects running in tcl/tk - including that in scalars you have  
extra lag if you move the mouse over them, even without clicking.  
Switching off the mouse detection on demand would make things faster.


I have a patch with more than 33548 scalars, and it takes several minutes  
to open in my desktop; on my laptop, it just stays there with cpu at 100%  
without opening.


Best,

Joao


Thanks for your testing!

The lag appears on my computer already with the patch i sent with the
1050 scalars. It shows when i open the patch, create any object, say a
[float] and try to move it around.

With more scalars it can become even worse. You can test it with the
attached patch. First select width and height and then click create. It
creates a rectangle made of width x height one-pixel-scalars.

With about 100 x 100 pixel, clearing the patch becomes increasingly
slow. With 640 x 256 pixel, it took more than nine minutes on my
computer to clear the subpatch or even to close the window, so be  
warned! ;)


The reason for the lag is afaik, that all interface objects are
constantly redrawn by Tcl, so it is not limited to scalars.

best, ingo


On 05/19/2018 11:23 PM, Roman Haefeli wrote:

On Sat, 2018-05-19 at 17:00 +0200, Ingo Stock wrote:

On 05/19/2018 11:56 AM, Roman Haefeli wrote:

Yeah. It's not very elegant and gets expensive pretty quickly. I
was
wondering about alternative strategies, like moving non-used
scalars
out-of-the-way and later re-use them. It's cumbersome to implement,
but
probably less drastic than the clear-all-and-rebuild method.


Can only answer to this: There are several methods to make scalars
invisible. Anyhow, in my experience the method to clear the subpatch
and
recreate everything works quite well and is imho the clean approach
to
do it, as all the scalars are redrawn every frame any way.

There are other limits to the use of data structures. Depending on
your
computer, when you get above 800 scalars or so, the patch becomes
laggy.


Thanks for your considerations. That is exactly the kind of info that I
was looking for. I don't share the experience with the limit of 800,
though, but this is presumably related to the computer/CPU.


Consider the attached patch:


Nice and illustrative example patch.


 On load 1050 scalars are created, which is
already quite heavy on my computer.


I'm not sure I understand correctly. Just having the patch open is
heavy on your box? Or interacting with it?


Anyhow, deleting a scalar by
clicking on it works fine, using the clear and redraw method.>>


It works fine for me, too. Then I measured the time it takes to redraw
different numbers of squares. It seems computation time is roughly
proportional to the number of redrawn objects (1: 0.08ms, 500: 3.9ms,
1000: 7.6ms). So there is a penalty of this method with larger numbers
of scalars.


Hiding scalars by making them invisible doesn't help with the lagging
problem. Therefore i would recommend the clear and redraw method any
day. ;)


I don't experience any lags by making specific scalars invisible. It
takes 0.007ms to make a single scalar invisible within a subpatch of
1050 squares. See my modified version of your patch.

Roman







___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->  
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Data structures - delete specific scalar?

[Derek Kwan]

Roman Haefeli  writes:

> Hey all
>
> Following up a thread from 2011:
> https://lists.puredata.info/pipermail/pd-list/2011-04/088306.html
>
> I would like to know whether it is impossible to delete a specific
> scalar, by pointer. If so, why is that? Does it use a design that makes
> it difficult to allow this? To my untrained eye there is no apparent
> reason why it is possible by editing the GUI graphically/manually, but
> not per message.
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list

If I'm not mistaken, this relates to a thread I started in Jan 2017 and
I think this bit from Christof Ressi might prove releavant to these
discussions so hopefully this link could help with the current discussion:

https://lists.puredata.info/pipermail/pd-list/2017-01/117295.html

Derek

-- 
Derek Kwan
www.derekxkwan.com

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Data structures - delete specific scalar?

[Ingo Stock]

Thanks for your testing!

The lag appears on my computer already with the patch i sent with the
1050 scalars. It shows when i open the patch, create any object, say a
[float] and try to move it around.

With more scalars it can become even worse. You can test it with the
attached patch. First select width and height and then click create. It
creates a rectangle made of width x height one-pixel-scalars.

With about 100 x 100 pixel, clearing the patch becomes increasingly
slow. With 640 x 256 pixel, it took more than nine minutes on my
computer to clear the subpatch or even to close the window, so be warned! ;)

The reason for the lag is afaik, that all interface objects are
constantly redrawn by Tcl, so it is not limited to scalars.

best, ingo


On 05/19/2018 11:23 PM, Roman Haefeli wrote:
> On Sat, 2018-05-19 at 17:00 +0200, Ingo Stock wrote:
>> On 05/19/2018 11:56 AM, Roman Haefeli wrote:
>>> Yeah. It's not very elegant and gets expensive pretty quickly. I
>>> was
>>> wondering about alternative strategies, like moving non-used
>>> scalars
>>> out-of-the-way and later re-use them. It's cumbersome to implement,
>>> but
>>> probably less drastic than the clear-all-and-rebuild method. 
>>
>> Can only answer to this: There are several methods to make scalars
>> invisible. Anyhow, in my experience the method to clear the subpatch
>> and
>> recreate everything works quite well and is imho the clean approach
>> to
>> do it, as all the scalars are redrawn every frame any way.
>>
>> There are other limits to the use of data structures. Depending on
>> your
>> computer, when you get above 800 scalars or so, the patch becomes
>> laggy.
> 
> Thanks for your considerations. That is exactly the kind of info that I
> was looking for. I don't share the experience with the limit of 800,
> though, but this is presumably related to the computer/CPU.
> 
>> Consider the attached patch:
> 
> Nice and illustrative example patch.
> 
>>  On load 1050 scalars are created, which is
>> already quite heavy on my computer. 
> 
> I'm not sure I understand correctly. Just having the patch open is
> heavy on your box? Or interacting with it?
> 
>> Anyhow, deleting a scalar by
>> clicking on it works fine, using the clear and redraw method.>>
> 
> It works fine for me, too. Then I measured the time it takes to redraw
> different numbers of squares. It seems computation time is roughly
> proportional to the number of redrawn objects (1: 0.08ms, 500: 3.9ms,
> 1000: 7.6ms). So there is a penalty of this method with larger numbers
> of scalars.
> 
>> Hiding scalars by making them invisible doesn't help with the lagging
>> problem. Therefore i would recommend the clear and redraw method any
>> day. ;)
> 
> I don't experience any lags by making specific scalars invisible. It
> takes 0.007ms to make a single scalar invisible within a subpatch of
> 1050 squares. See my modified version of your patch.
> 
> Roman
> 
> 
> 
> 
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 
#N canvas 275 264 835 329 10;
#X floatatom 694 131 5 0 639 1 width #0-setWidth #0-width, f 5;
#X floatatom 694 112 5 0 255 1 height #0-setHeight #0-height, f 5
;
#N canvas 68 127 697 295 \$0-pixelgrid 0;
#X coords 0 255 640 0 640 255 2 0 0;
#X restore 42 37 pd \$0-pixelgrid;
#N canvas 584 116 613 300 \$0-pixel 0;
#X obj 64 75 unpack s p f, f 13;
#X floatatom 292 232 5 0 0 1 x - #0-x, f 5;
#X floatatom 415 232 5 0 0 1 y - #0-y, f 5;
#X obj 131 141 f;
#X obj 186 141 f;
#X floatatom 337 191 5 0 0 1 width #0-width -, f 5;
#X floatatom 460 191 5 0 0 1 height #0-height -, f 5;
#X obj 64 185 f;
#X obj 64 163 t b b;
#X obj 105 185 f;
#X obj 292 188 max 0;
#X obj 292 210 min;
#X obj 415 188 max 0;
#X obj 415 210 min;
#X obj 64 53 struct \$0-pixel float x0 float y0 float x1 float y1;
#X obj 64 207 set \$0-pixel x0 y0 x1 y1;
#X obj 241 141 f;
#X obj 296 141 f;
#X obj 146 185 f;
#X obj 187 185 f;
#X obj 149 97 get \$0-pixel x0 y0 x1 y1;
#X obj 64 97 sel change;
#X obj 397 166 sel;
#X obj 274 166 sel;
#X obj 64 229 drawpolygon 919 1 x0 y0 x1 y1;
#X obj 131 119 bang;
#X connect 0 0 21 0;
#X connect 0 1 15 4;
#X connect 0 1 20 0;
#X connect 3 0 7 1;
#X connect 4 0 9 1;
#X connect 5 0 11 1;
#X connect 6 0 13 1;
#X connect 7 0 15 0;
#X connect 8 0 7 0;
#X connect 8 1 9 0;
#X connect 8 1 18 0;
#X connect 8 1 19 0;
#X connect 9 0 15 1;
#X connect 10 0 11 0;
#X connect 11 0 1 0;
#X connect 12 0 13 0;
#X connect 13 0 2 0;
#X connect 14 0 0 0;
#X connect 16 0 18 1;
#X connect 16 0 23 1;
#X connect 17 0 19 1;
#X connect 17 0 22 1;
#X connect 18 0 15 2;
#X connect 19 0 15 3;
#X connect 20 0 3 1;
#X connect 20 1 4 1;
#X connect 20 2 16 1;
#X connect 20 2 23 0;
#X connect 20 3 17 1;
#X connect 20 3 22 0;
#X connect 21 0 8 0;
#X connect 21 1 25 0;
#X connect 22 1 12 0;
#X connect 23 1 10 0;
#X connect 25 0 3 0;
#X connect 25 0 4 0;
#X connect 25 0 16 0;
#X connect 25 0 

Re: [PD] Data structures - delete specific scalar?

[Roman Haefeli]

On Sat, 2018-05-19 at 17:00 +0200, Ingo Stock wrote:
> On 05/19/2018 11:56 AM, Roman Haefeli wrote:
> > Yeah. It's not very elegant and gets expensive pretty quickly. I
> > was
> > wondering about alternative strategies, like moving non-used
> > scalars
> > out-of-the-way and later re-use them. It's cumbersome to implement,
> > but
> > probably less drastic than the clear-all-and-rebuild method. 
> 
> Can only answer to this: There are several methods to make scalars
> invisible. Anyhow, in my experience the method to clear the subpatch
> and
> recreate everything works quite well and is imho the clean approach
> to
> do it, as all the scalars are redrawn every frame any way.
> 
> There are other limits to the use of data structures. Depending on
> your
> computer, when you get above 800 scalars or so, the patch becomes
> laggy.

Thanks for your considerations. That is exactly the kind of info that I
was looking for. I don't share the experience with the limit of 800,
though, but this is presumably related to the computer/CPU.

> Consider the attached patch:

Nice and illustrative example patch.

>  On load 1050 scalars are created, which is
> already quite heavy on my computer. 

I'm not sure I understand correctly. Just having the patch open is
heavy on your box? Or interacting with it?

> Anyhow, deleting a scalar by
> clicking on it works fine, using the clear and redraw method.>>

It works fine for me, too. Then I measured the time it takes to redraw
different numbers of squares. It seems computation time is roughly
proportional to the number of redrawn objects (1: 0.08ms, 500: 3.9ms,
1000: 7.6ms). So there is a penalty of this method with larger numbers
of scalars.

> Hiding scalars by making them invisible doesn't help with the lagging
> problem. Therefore i would recommend the clear and redraw method any
> day. ;)

I don't experience any lags by making specific scalars invisible. It
takes 0.007ms to make a single scalar invisible within a subpatch of
1050 squares. See my modified version of your patch.

Roman





#N struct 1003-square float x float y float id float vis;
#N canvas 1 99 1107 655 12;
#N canvas 1 88 450 300 \$0-display 0;
#X scalar 1003-square 2 2 0 0 \;;
#X scalar 1003-square 14 2 1 0 \;;
#X scalar 1003-square 26 2 2 0 \;;
#X scalar 1003-square 38 2 3 0 \;;
#X scalar 1003-square 50 2 4 0 \;;
#X scalar 1003-square 62 2 5 0 \;;
#X scalar 1003-square 74 2 6 0 \;;
#X scalar 1003-square 86 2 7 0 \;;
#X scalar 1003-square 98 2 8 0 \;;
#X scalar 1003-square 110 2 9 0 \;;
#X scalar 1003-square 122 2 10 0 \;;
#X scalar 1003-square 134 2 11 0 \;;
#X scalar 1003-square 146 2 12 0 \;;
#X scalar 1003-square 158 2 13 0 \;;
#X scalar 1003-square 170 2 14 0 \;;
#X scalar 1003-square 182 2 15 0 \;;
#X scalar 1003-square 194 2 16 0 \;;
#X scalar 1003-square 206 2 17 0 \;;
#X scalar 1003-square 218 2 18 0 \;;
#X scalar 1003-square 230 2 19 0 \;;
#X scalar 1003-square 242 2 20 0 \;;
#X scalar 1003-square 254 2 21 0 \;;
#X scalar 1003-square 266 2 22 0 \;;
#X scalar 1003-square 278 2 23 0 \;;
#X scalar 1003-square 290 2 24 0 \;;
#X scalar 1003-square 302 2 25 0 \;;
#X scalar 1003-square 314 2 26 0 \;;
#X scalar 1003-square 326 2 27 0 \;;
#X scalar 1003-square 338 2 28 0 \;;
#X scalar 1003-square 350 2 29 0 \;;
#X scalar 1003-square 362 2 30 0 \;;
#X scalar 1003-square 374 2 31 0 \;;
#X scalar 1003-square 386 2 32 0 \;;
#X scalar 1003-square 398 2 33 0 \;;
#X scalar 1003-square 410 2 34 0 \;;
#X scalar 1003-square 2 14 35 0 \;;
#X scalar 1003-square 14 14 36 0 \;;
#X scalar 1003-square 26 14 37 0 \;;
#X scalar 1003-square 38 14 38 0 \;;
#X scalar 1003-square 50 14 39 0 \;;
#X scalar 1003-square 62 14 40 0 \;;
#X scalar 1003-square 74 14 41 0 \;;
#X scalar 1003-square 86 14 42 0 \;;
#X scalar 1003-square 98 14 43 0 \;;
#X scalar 1003-square 110 14 44 0 \;;
#X scalar 1003-square 122 14 45 0 \;;
#X scalar 1003-square 134 14 46 0 \;;
#X scalar 1003-square 146 14 47 0 \;;
#X scalar 1003-square 158 14 48 0 \;;
#X scalar 1003-square 170 14 49 0 \;;
#X scalar 1003-square 182 14 50 0 \;;
#X scalar 1003-square 194 14 51 0 \;;
#X scalar 1003-square 206 14 52 0 \;;
#X scalar 1003-square 218 14 53 0 \;;
#X scalar 1003-square 230 14 54 0 \;;
#X scalar 1003-square 242 14 55 0 \;;
#X scalar 1003-square 254 14 56 0 \;;
#X scalar 1003-square 266 14 57 0 \;;
#X scalar 1003-square 278 14 58 0 \;;
#X scalar 1003-square 290 14 59 0 \;;
#X scalar 1003-square 302 14 60 0 \;;
#X scalar 1003-square 314 14 61 0 \;;
#X scalar 1003-square 326 14 62 0 \;;
#X scalar 1003-square 338 14 63 0 \;;
#X scalar 1003-square 350 14 64 0 \;;
#X scalar 1003-square 362 14 65 0 \;;
#X scalar 1003-square 374 14 66 0 \;;
#X scalar 1003-square 386 14 67 0 \;;
#X scalar 1003-square 398 14 68 0 \;;
#X scalar 1003-square 410 14 69 0 \;;
#X scalar 1003-square 2 26 70 0 \;;
#X scalar 1003-square 14 26 71 0 \;;
#X scalar 1003-square 26 26 72 0 \;;
#X scalar 1003-square 38 26 73 0 \;;
#X scalar 1003-square 50 26 74 0 \;;
#X scalar 1003-square 62 26 75 0 \;;

Re: [PD] Data structures - delete specific scalar?

[Alexandre Torres Porres]

2018-05-19 6:56 GMT-03:00 Roman Haefeli :

> On Sat, 2018-05-19 at 00:02 +0200, Ingo Stock wrote:
> > to my knowledge it is not possible to delete a single scalar.
>
> Thanks for the confirmation. I'm also wondering whether this will
> always be like this or if it would be a trivial feature to add.
>

I can't see why it has to stay like this, I'd move past that and ask how we
could implement it, then try to work on a pull request :)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Data structures - delete specific scalar?

[Ingo Stock]

On 05/19/2018 11:56 AM, Roman Haefeli wrote:
> Yeah. It's not very elegant and gets expensive pretty quickly. I was
> wondering about alternative strategies, like moving non-used scalars
> out-of-the-way and later re-use them. It's cumbersome to implement, but
> probably less drastic than the clear-all-and-rebuild method. 
Can only answer to this: There are several methods to make scalars
invisible. Anyhow, in my experience the method to clear the subpatch and
recreate everything works quite well and is imho the clean approach to
do it, as all the scalars are redrawn every frame any way.

There are other limits to the use of data structures. Depending on your
computer, when you get above 800 scalars or so, the patch becomes laggy.

Consider the attached patch: On load 1050 scalars are created, which is
already quite heavy on my computer. Anyhow, deleting a scalar by
clicking on it works fine, using the clear and redraw method.

Hiding scalars by making them invisible doesn't help with the lagging
problem. Therefore i would recommend the clear and redraw method any day. ;)

best wishes, ingo
#N canvas 142 116 1107 655 12;
#N canvas 1 88 450 300 \$0-display 0;
#X coords 0 0 422 362 422 362 2 0 0;
#X restore 48 42 pd \$0-display;
#X msg 655 376 clear;
#X obj 655 399 s pd-\$0-display;
#X obj 677 560 pointer;
#X msg 677 537 traverse pd-\$1-display \, bang;
#X obj 677 514 \$0;
#N canvas 523 298 476 332 \$0-square 0;
#X obj 36 57 struct \$0-square float x float y float id;
#X obj 36 34 filledpolygon 778 338 1 0 0 0 10 10 10 10 0;
#X obj 36 80 unpack s p f;
#X obj 36 149 get \$0-square id;
#X obj 59 218 array set \$0-state;
#X obj 36 172 t b b f;
#X obj 59 195 0;
#X obj 36 264 s \$0-create;
#X obj 36 103 sel click;
#X obj 36 126 pointer;
#X obj 36 241 del;
#X text 70 241 <- Without this delay the patch crashes quite often...
;
#X connect 0 0 2 0;
#X connect 2 0 8 0;
#X connect 2 1 9 1;
#X connect 3 0 5 0;
#X connect 5 0 10 0;
#X connect 5 1 6 0;
#X connect 5 2 4 1;
#X connect 6 0 4 0;
#X connect 8 0 9 0;
#X connect 9 0 3 0;
#X connect 10 0 7 0;
#X restore 519 54 pd \$0-square;
#X obj 519 264 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X obj 519 376 array get \$0-state;
#N canvas 1 115 211 251 list-drip 0;
#X obj 42 39 inlet;
#X obj 42 154 list store;
#X obj 42 85 until;
#X obj 42 108 f;
#X obj 72 108 + 1;
#X msg 42 131 get \$1 1;
#X obj 85 86 0;
#X obj 42 177 outlet;
#X obj 109 177 outlet;
#X obj 42 62 t b b a;
#X connect 0 0 9 0;
#X connect 1 0 7 0;
#X connect 1 1 8 0;
#X connect 1 1 2 1;
#X connect 2 0 3 0;
#X connect 3 0 5 0;
#X connect 3 0 4 0;
#X connect 4 0 3 1;
#X connect 5 0 1 0;
#X connect 6 0 3 1;
#X connect 9 0 2 0;
#X connect 9 1 6 0;
#X connect 9 2 1 1;
#X restore 519 399 pd list-drip;
#X obj 563 445 f;
#X obj 593 445 + 1;
#X obj 623 445 0;
#X obj 519 353 t b b b;
#X obj 519 422 t f b;
#X obj 519 445 sel 1;
#X obj 519 468 f;
#X msg 542 169 const 1;
#X obj 519 491 t f f f;
#X obj 519 583 append \$0-square x y id;
#X obj 519 100 loadbang;
#X obj 519 537 * 12;
#X obj 571 537 * 12;
#X obj 519 514 mod 35;
#X obj 571 514 div 35;
#X obj 519 560 + 2;
#X obj 571 560 + 2;
#X obj 519 330 r \$0-create;
#X obj 519 284 s \$0-create;
#X obj 519 215 s \$0-create;
#X obj 609 264 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X obj 609 284 s \$0-clear;
#X obj 655 353 r \$0-clear;
#X obj 584 100 r \$0-reset;
#X obj 691 264 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X obj 691 284 s \$0-reset;
#X msg 606 169 resize \$1;
#X obj 519 146 t b b f;
#X obj 542 192 array define \$0-state;
#X obj 519 123 1050;
#X floatatom 604 124 5 0 0 0 - - -, f 5;
#X text 621 55 <- Deleting happends inside here;
#X text 655 123 <- Changing the number of squares also clears and redraws
\, so it happends really fast.;
#X connect 1 0 2 0;
#X connect 3 0 19 3;
#X connect 4 0 3 0;
#X connect 5 0 4 0;
#X connect 7 0 28 0;
#X connect 8 0 9 0;
#X connect 9 0 14 0;
#X connect 10 0 11 0;
#X connect 10 0 16 1;
#X connect 11 0 10 1;
#X connect 12 0 10 1;
#X connect 13 0 8 0;
#X connect 13 1 5 0;
#X connect 13 2 1 0;
#X connect 13 2 12 0;
#X connect 14 0 15 0;
#X connect 14 1 10 0;
#X connect 15 0 16 0;
#X connect 16 0 18 0;
#X connect 17 0 38 0;
#X connect 18 0 23 0;
#X connect 18 1 24 0;
#X connect 18 2 19 2;
#X connect 20 0 39 0;
#X connect 21 0 25 0;
#X connect 22 0 26 0;
#X connect 23 0 21 0;
#X connect 24 0 22 0;
#X connect 25 0 19 0;
#X connect 26 0 19 1;
#X connect 27 0 13 0;
#X connect 30 0 31 0;
#X connect 32 0 1 0;
#X connect 33 0 39 0;
#X connect 34 0 35 0;
#X connect 36 0 38 0;
#X connect 37 0 29 0;
#X connect 37 1 17 0;
#X connect 37 2 36 0;
#X connect 39 0 37 0;
#X connect 40 0 37 0;


signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Data structures - delete specific scalar?

[Ingo Stock]

Hi Roman,

to my knowledge it is not possible to delete a single scalar. The method
to get rid of a scalar is to clear the subpatch and recreate everything.

best wishes, ingo


On 05/18/2018 11:36 PM, Roman Haefeli wrote:
> Hey all
> 
> Following up a thread from 2011:
> https://lists.puredata.info/pipermail/pd-list/2011-04/088306.html
> 
> I would like to know whether it is impossible to delete a specific
> scalar, by pointer. If so, why is that? Does it use a design that makes
> it difficult to allow this? To my untrained eye there is no apparent
> reason why it is possible by editing the GUI graphically/manually, but
> not per message.
> 
> Roman
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Data structures - delete specific scalar?

[Roman Haefeli]

Hey all

Following up a thread from 2011:
https://lists.puredata.info/pipermail/pd-list/2011-04/088306.html

I would like to know whether it is impossible to delete a specific
scalar, by pointer. If so, why is that? Does it use a design that makes
it difficult to allow this? To my untrained eye there is no apparent
reason why it is possible by editing the GUI graphically/manually, but
not per message.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list