Bpatcher scripting dirtying the main patch…

Nov 22, 2007 at 5:41pm

Bpatcher scripting dirtying the main patch…

I have a bpatcher (my new min.sec/hr.min.sec) which will make the main
patcher dirty, because I script an object inside. I think its either a
bug or something unavoidable. I’d like to know why. It complies to the
other problem I had to circumvent with this object.
When scripting inside a bpatcher the coordinates are relative to the
main patcher and not relative to the bpatcher.
These two effects might have the same reason: A bpatcher is as if it its
a part of the main patcher, but all the rest is just “invisible”…???

Is this true or is it a bug?

The other question related to it, is: will the bpatcher of Max 5 behave
in the same way?

To reproduce, place my latest St.ools in the search path and open the
patch below.

This will not dirty the patcher. As soon as I change the size of
min.sec, it will be dirtyed and asks for saving…
Expected result: leave the dirty status of the main patcher as it is…

Look at the scripting subpatcher of min.sec to see how I get the
position correct. js was the rescue… ;-)
I would not mind if scripting within bpatchers would work more like
expected and position relative to the bpatcher. I’d happily adpat and
simplyfie any broken patch if this behaviour is changed…

I don’t know of any other abstractions which do similar tricks. Breaking
my patches is fine with me. It will be less hassle in the future…

Stefan

#P bpatcher 105 131 349 157 0 0 min.sec.pat 0;
#P objectname box2;
#P window setfont “Sans Serif” 9.;
#P number 105 87 35 9 9 255 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P message 105 109 40 196617 size $1;
#P connect 0 0 2 0;
#P connect 1 0 0 0;
#P window clipboard copycount 3;


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#34716
Nov 22, 2007 at 5:55pm

Stefan Tiedje schrieb:
> These two effects might have the same reason: A bpatcher is as if it its
> a part of the main patcher, but all the rest is just “invisible”…???

It seems to work like that. If I send a clean command to the thispatcher
object inside the bpatcher (triggered by the size message). The main
patcher will be set clean, even if I did changes in the main patcher
before changing the size in the bpatcher it will clean the main patcher…
(which is not wanted, it should not affect the dirty status of the main
patcher at all…)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#117581
Nov 22, 2007 at 6:16pm

Hi Stefan,

Can you include you min.sec.pat? Or is there somewhere else I can go to find it?

Zachary

#117582
Nov 22, 2007 at 6:17pm

forget it, didn’t read your post closely enough. Sorry.

#117583
Nov 22, 2007 at 7:35pm

Stefan, this has been on my GIANT GRIPE LIST forever.

It blows my mind about the coordinate system being changed, which is
so counterintuitive its crazy (imo). I also get the “scripting causes
dirty” issue as well. You have to to a thispatcher -> clean message or
whatnot. My older performance patches basically had LOTS of cruft
working around these issues. :(

Id love to see this behaviour changed in Max 5.

On Nov 22, 2007, at 12:41 PM, Stefan Tiedje wrote:

> I have a bpatcher (my new min.sec/hr.min.sec) which will make the
> main patcher dirty, because I script an object inside. I think its
> either a bug or something unavoidable. I’d like to know why. It
> complies to the other problem I had to circumvent with this object.
> When scripting inside a bpatcher the coordinates are relative to the
> main patcher and not relative to the bpatcher.
> These two effects might have the same reason: A bpatcher is as if it
> its a part of the main patcher, but all the rest is just
> “invisible”…???
>
> Is this true or is it a bug?
>
> The other question related to it, is: will the bpatcher of Max 5
> behave in the same way?
>
> To reproduce, place my latest St.ools in the search path and open
> the patch below.
>
> This will not dirty the patcher. As soon as I change the size of
> min.sec, it will be dirtyed and asks for saving…
> Expected result: leave the dirty status of the main patcher as it
> is…
>
> Look at the scripting subpatcher of min.sec to see how I get the
> position correct. js was the rescue… ;-)
> I would not mind if scripting within bpatchers would work more like
> expected and position relative to the bpatcher. I’d happily adpat
> and simplyfie any broken patch if this behaviour is changed…
>
> I don’t know of any other abstractions which do similar tricks.
> Breaking my patches is fine with me. It will be less hassle in the
> future…
>
> Stefan
>
> #P bpatcher 105 131 349 157 0 0 min.sec.pat 0;
> #P objectname box2;
> #P window setfont “Sans Serif” 9.;
> #P number 105 87 35 9 9 255 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P window linecount 1;
> #P message 105 109 40 196617 size $1;
> #P connect 0 0 2 0;
> #P connect 1 0 0 0;
> #P window clipboard copycount 3;
>
>
> —
> Stefan Tiedje————x——-
> –_____———–|————–
> –(_|_ —-|—–|—–()——-
> — _|_)—-|—–()————–
> ———-()——–www.ccmix.com
>

#117584
Nov 23, 2007 at 10:02am

Zachary Seldess schrieb:
> Hi Stefan,
>
> Can you include you min.sec.pat? Or is there somewhere else I can go to find it?

As there are more dependencies, I recommend to download my whole
collection of St.ools just updated on

http://www.cycling74.com/twiki/bin/view/Share/StefanTiedje

have fun, there is also a hr.min.sec… both are ment as number box
replacement for times…

let me know if anything is missing…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#117585
Nov 23, 2007 at 10:53am

vade schrieb:
> It blows my mind about the coordinate system being changed, which is
> so counterintuitive its crazy (imo).

My workaround finally is pretty simple, a js is getting the coordiantes
and you just add those to your x/y values. An even better solution could
be if there would be a way to have a “script replace” command which
would keep the position where it was, maybe a “script inplace
myobject…” which would act exactly the same as the paste replace you
do by hand. It would replace the object and move it to its old place…

> I also get the “scripting causes dirty” issue as well. You have to to
> a thispatcher -> clean message or whatnot.

I just made another observation, which makes me think, the clean/dirty
status of a patcher isn’t really done “clean”. I had the dirty issue
also with all the objects whith variable number of inlets/outlets. (Some
help files of mine will have a clean messege banging the main patcher on
loadbang).

Now I made a test, if I place the clean message into the subpatcher, the
main patcher remains clean as well. That simplifies the issue a lot,
because an instantiated subpatcher doesn’t dirty the main patch anymore.
But it seems odd and certainly is counter intuitive… (That’s why it
took so long to find a solution… ;-)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#117586
Dec 18, 2007 at 8:41pm

Quote: vade wrote on Thu, 22 November 2007 11:35
—————————————————-
> Stefan, this has been on my GIANT GRIPE LIST forever.
>
> It blows my mind about the coordinate system being changed, which is
> so counterintuitive its crazy (imo).

I just ran into this bug. Wrecked my day.

grr,

mz

#117587
Dec 19, 2007 at 12:56am

Hi,

i am working on some gui that makes use of multiple layers of bpatchers (scripting/moving nested bpatchers) and encountered these problems as well.

Id have two questions (besides if Max5 is going to solve the problems):

Is there a neat way of retrieving bpatcher-offsets (in addition to the position) using js (scrollorigin maybe) ?

Is there anything one could do in general to avoid messing up the display whenever sth. is scripted (not even visible) in a nested bpatcher (sth. like preventing max from redrawing while scripting ?) ?

cheers,
M

#117588
Dec 19, 2007 at 5:24am

Quote: vade wrote on Thu, 22 November 2007 11:35
—————————————————-
> Stefan, this has been on my GIANT GRIPE LIST forever.
>
> It blows my mind about the coordinate system being changed, which is
> so counterintuitive its crazy (imo).

+vote from me to change this in Max 5. Like Stefan, I will gladly go fix any of my broken patches when you correct this rather serious flaw with bpatcher. And you can always put in a “backward compatibility absolute coordinate system” checkbox in the inspector, right?

Fix this and the redrawing problems, and we can finally start scripting inside a bpatcher without jumping through unnecessary hoops.

-Adam

#117589
Dec 19, 2007 at 2:08pm

Yes, this is on my wishlist too, has been on it for a long time:

- scripting with bpatchers is awkward, especially in realtime, since there’s no way of knowing when one is finished deleting, so the same object names cannot be used since this may generate naming errors.
- building a modular system always causes your patch to dirty.
- nested bpatches (bpatchers in bpatchers etc.) can cause crashes when you save one. Don’t know if this has been fixed tho.
- the coordinate system is counterintuitive.
- when having multiple bpatchers with gui objects in them, the gui objects don’t repaint when losing focus (many yellow triangles). This sometimes happen at other times too. When you save a bpatcher, white rectangles may appear on your main patch where subpatchers inside the bpatcher are (outside of the visible area).

http://www.cycling74.com/forums/index.php?t=msg&goto=98929&rid=5118&S=8583f6c0389df174bc76d07bc46c595a#msg_98929

In general, i’d say a more complete gui solution would help, like the presentation mode in max 5. I don’t know what features this has though…i hope for panels and tabs with proper (2d middle mousebutton) scrolling support. Snapping, grid and better image/button options would be nice too. I’d rebuild my entire Gui if something like this was available.

#117590
Dec 20, 2007 at 5:27pm

Marlon_Schumacher schrieb:
> Is there a neat way of retrieving bpatcher-offsets (in addition to
> the position) using js (scrollorigin maybe) ?

You could retrieve the position of an “anchor” object and script
according to its position. It should reflect the offset…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#117591

You must be logged in to reply to this topic.