Stefan Tiedje

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"...???

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

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

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...

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"...???

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


bpatcher-scripting-dirtying-the-main-patch

> 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 

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...)

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

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

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 

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 

> The other question related to it, is: will the bpatcher of Max 5 

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

> 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 

> 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 

> #P bpatcher 105 131 349 157 0 0 min.sec.pat 0;

> #P number 105 87 35 9 9 255 3 3 0 0 0 221 221 221 222 222 222 0 0 0;

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. :(

> 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
>


> 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 

https://cycling74.com/twiki/bin/view/Share/StefanTiedje

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

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

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

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

> It blows my mind about the coordinate system being changed, which is

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 

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 

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... ;-)

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 

I just ran into this bug. Wrecked my day.

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 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 ?) ?

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 ?) ?

+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.

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).

https://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.

- 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).
https://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.


> 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...

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...

Bpatcher scripting dirtying the main patch...