Mattijs

We're currently busy with some advanced interface design and we ran into another bpatcher problem.

When piling 11 (or more) bpatchers on the same position inside another bpatcher, it can take very long to delete one of them. When they are not on the same position there is no problem.

The time to delete one of the bpatchers shouldn't depend on their position in the containing bpatcher.

Mac OS 10.4.8, Max 4.6.2, confirmed on Mac Pro and PPC

Please follow the steps inside the OpenMe patch below to reproduce.

Problem description:
When piling 11 (or more) bpatchers on the same position inside another bpatcher, it can take very long to delete one of them. When they are not on the same position there is no problem.

Expected behaviour:
The time to delete one of the bpatchers shouldn't depend on their position in the containing bpatcher.

Hope you can confirm,
Mattijs Kneppers & Bas van der Graaff


bugreport-deleting-bpatchers-with-script-takes-very-long-but-only-when-piled-up

I have this issue sometimes when even closing my patch, max takes 

forever to quit. My patch scripts loading of some bpatchers/ 

abstractions. Ive yet to figure out why, because it is inconsistent, 

but ive seen times close to 3 minutes to simply close my performance 

patch. Ive gotten used to simply force quitting occasionally.

On Mar 21, 2007, at 11:43 AM, Mattijs Kneppers wrote:

> We're currently busy with some advanced interface design and we ran 

> When piling 11 (or more) bpatchers on the same position inside 

> another bpatcher, it can take very long to delete one of them. When 

> they are not on the same position there is no problem.

> The time to delete one of the bpatchers shouldn't depend on their 

> Mac OS 10.4.8, Max 4.6.2, confirmed on Mac Pro and PPC

> Please follow the steps inside the OpenMe patch below to reproduce.

> #P hidden newex 145 30 83 196617 r ToThisPatcher;

> #P hidden newobj 145 50 61 196617 thispatcher;

I have this issue sometimes when even closing my patch, max takes  
forever to quit. My patch scripts loading of some bpatchers/ 
abstractions. Ive yet to figure out why, because it is inconsistent,  
but ive seen times close to 3 minutes to simply close my performance  
patch. Ive gotten used to simply force quitting occasionally.

>
> Hi,
>
> We're currently busy with some advanced interface design and we ran  
> into another bpatcher problem.
>
> Problem description:
> When piling 11 (or more) bpatchers on the same position inside  
> another bpatcher, it can take very long to delete one of them. When  
> they are not on the same position there is no problem.
>
> Expected behaviour:
> The time to delete one of the bpatchers shouldn't depend on their  
> position in the containing bpatcher.
>
> Mac OS 10.4.8, Max 4.6.2, confirmed on Mac Pro and PPC
>
> Please follow the steps inside the OpenMe patch below to reproduce.
>
> save as 'GuiHolder'
>
> #P bpatcher 7 29 95 20 0 0  1;
> #P objectname Gui1;
> #P bpatcher 7 239 95 20 0 0  1;
> #P objectname Gui11;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P hidden newex 145 30 83 196617 r ToThisPatcher;
> #N thispatcher;
> #Q end;
> #P hidden newobj 145 50 61 196617 thispatcher;
> #P bpatcher 7 92 95 20 0 0  1;
> #P objectname Gui10;
> #P bpatcher 7 113 95 20 0 0  1;
> #P objectname Gui9;
> #P bpatcher 7 134 95 20 0 0  1;
> #P objectname Gui8;
> #P bpatcher 7 155 95 20 0 0  1;
> #P objectname Gui7;
> #P bpatcher 7 176 95 20 0 0  1;
> #P objectname Gui6;
> #P bpatcher 7 197 95 20 0 0  1;
> #P objectname Gui5;
> #P bpatcher 7 218 95 20 0 0  1;
> #P objectname Gui4;
> #P bpatcher 7 71 95 20 0 0  1;
> #P objectname Gui3;
> #P bpatcher 7 50 95 20 0 0  1;
> #P objectname Gui2;
> #P hidden connect 10 0 9 0;
> #P window clipboard copycount 13;
>
>
> save as 'OpenMe':
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P comment 308 87 214 196617 5: repeat steps 1 and 2: no problem  
> this time;
> #P comment 212 88 85 196617
> #P toggle 196 88 15 0;
> #P newex 196 105 27 196617 + 1;
> #P newex 196 124 47 196617 gate 2 1;
> #P comment 308 43 175 196617 3: reopen the patch (without saving);
> #P comment 172 263 282 196617
> deleting takes a looong time;
> #P message 155 44 20 196617 11;
> #P newex 196 144 21 196617 t 0;
> #P newex 233 144 32 196617 * 50;
> #P newex 196 165 43 196617 + 1000;
> #P newex 155 65 40 196617 uzi;
> #P newex 185 213 83 196617 s ToThisPatcher;
> #P newex 185 192 151 196617 sprintf script move Gui%i 5 %i;
> #P message 155 263 14 196617 1;
> #P newex 155 301 83 196617 s ToThisPatcher;
> #P newex 155 281 130 196617 sprintf script delete Gui%i;
> #P bpatcher 2 21 124 292 -50 -50 GuiHolder 5;
> #P objectname VFXGui;
> #P comment 178 44 81 196617
> #P connect 7 2 5 0;
> #P connect 7 2 14 1;
> #P connect 8 0 5 1;
> #P connect 14 1 9 0;
> #P connect 9 0 8 0;
> #P connect 10 0 8 0;
> #P connect 14 0 10 0;
> #P connect 15 0 14 0;
> #P connect 16 0 15 0;
> #P connect 5 0 6 0;
> #P connect 2 0 3 0;
> #P connect 4 0 2 0;
> #P connect 11 0 7 0;
> #P window clipboard copycount 19;
>
>
> Hope you can confirm,
> Mattijs Kneppers & Bas van der Graaff
>
>
> --
> SmadSteck - http://www.smadsteck.nl
> Interactive audiovisual sampling soft- and hardware
>

Quote: vade wrote on Wed, 21 March 2007 12:59

----------------------------------------------------

> I have this issue sometimes when even closing my patch, max takes 

> forever to quit. My patch scripts loading of some bpatchers/ 

> abstractions. Ive yet to figure out why, because it is inconsistent, 

> but ive seen times close to 3 minutes to simply close my performance 

> patch. Ive gotten used to simply force quitting occasionally.

Did you try the patch we included? It illustrates very clearly that this strangely depends on whether bpatchers are placed on the same location.

Quote: vade wrote on Wed, 21 March 2007 12:59
----------------------------------------------------
> I have this issue sometimes when even closing my patch, max takes  
> forever to quit. My patch scripts loading of some bpatchers/ 
> abstractions. Ive yet to figure out why, because it is inconsistent,  
> but ive seen times close to 3 minutes to simply close my performance  
> patch. Ive gotten used to simply force quitting occasionally.
>

I have to admit I have not taken a look, but my bpatchers are not 'on 

top' of one another, but side by side, always. I script them to load 

as modules and be neatly uh, placed. Even with that I get 3 minute 

On Mar 21, 2007, at 2:17 PM, Mattijs Kneppers wrote:

> Quote: vade wrote on Wed, 21 March 2007 12:59

> ----------------------------------------------------

>> I have this issue sometimes when even closing my patch, max takes

>> forever to quit. My patch scripts loading of some bpatchers/

>> abstractions. Ive yet to figure out why, because it is inconsistent,

>> but ive seen times close to 3 minutes to simply close my performance

>> patch. Ive gotten used to simply force quitting occasionally.

> Did you try the patch we included? It illustrates very clearly that 

> this strangely depends on whether bpatchers are placed on the same 

> Interactive audiovisual sampling soft- and hardware

I have to admit I have not taken a look, but my bpatchers are not 'on  
top' of one another, but side by side, always. I script them to load  
as modules and be neatly uh, placed. Even with that I get 3 minute  
shutdown times :(

>
> Quote: vade wrote on Wed, 21 March 2007 12:59
> ----------------------------------------------------
>> I have this issue sometimes when even closing my patch, max takes
>> forever to quit. My patch scripts loading of some bpatchers/
>> abstractions. Ive yet to figure out why, because it is inconsistent,
>> but ive seen times close to 3 minutes to simply close my performance
>> patch. Ive gotten used to simply force quitting occasionally.
>>
>
> Hi vade, thanks for the info.
>
> Did you try the patch we included? It illustrates very clearly that  
> this strangely depends on whether bpatchers are placed on the same  
> location.
>
> Mattijs
> --
> SmadSteck - http://www.smadsteck.nl
> Interactive audiovisual sampling soft- and hardware
>

Quote: vade wrote on Wed, 21 March 2007 16:30

> I have to admit I have not taken a look, but my bpatchers are not 'on 

> top' of one another, but side by side, always. I script them to load 

> as modules and be neatly uh, placed. Even with that I get 3 minute 

Then this might be a different issue. A patch I am currently working also has a longer shutdown than startup time. This started only recently but I don't know what caused it.

> On Mar 21, 2007, at 2:17 PM, Mattijs Kneppers wrote:

> > Quote: vade wrote on Wed, 21 March 2007 12:59

> > ----------------------------------------------------

> >> I have this issue sometimes when even closing my patch, max takes

> >> forever to quit. My patch scripts loading of some bpatchers/

> >> abstractions. Ive yet to figure out why, because it is inconsistent,

> >> but ive seen times close to 3 minutes to simply close my performance

> >> patch. Ive gotten used to simply force quitting occasionally.

> > Did you try the patch we included? It illustrates very clearly that 

> > this strangely depends on whether bpatchers are placed on the same 

> > Interactive audiovisual sampling soft- and hardware

Quote: vade wrote on Wed, 21 March 2007 16:30
----------------------------------------------------
> I have to admit I have not taken a look, but my bpatchers are not 'on  
> top' of one another, but side by side, always. I script them to load  
> as modules and be neatly uh, placed. Even with that I get 3 minute  
> shutdown times :(

>
>
> On Mar 21, 2007, at 2:17 PM, Mattijs Kneppers wrote:
>
> >
> > Quote: vade wrote on Wed, 21 March 2007 12:59
> > ----------------------------------------------------
> >> I have this issue sometimes when even closing my patch, max takes
> >> forever to quit. My patch scripts loading of some bpatchers/
> >> abstractions. Ive yet to figure out why, because it is inconsistent,
> >> but ive seen times close to 3 minutes to simply close my performance
> >> patch. Ive gotten used to simply force quitting occasionally.
> >>
> >
> > Hi vade, thanks for the info.
> >
> > Did you try the patch we included? It illustrates very clearly that  
> > this strangely depends on whether bpatchers are placed on the same  
> > location.
> >
> > Mattijs
> > --
> > SmadSteck - http://www.smadsteck.nl
> > Interactive audiovisual sampling soft- and hardware
> >
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
>
>
>
>
----------------------------------------------------


Quote: Mattijs wrote on Wed, 21 March 2007 17:04

> Then this might be a different issue. A patch I am currently working also has a longer shutdown than startup time. This started only recently but I don't know what caused it.

https://cycling74.com/forums/index.php?t=msg&th=25227&start=0&rid=3579&S=5e6718714d05216e0fea6454cb8f532b

But that is clearly a different issue. The original question of this thread still stands.

Anyone, please let me know if you can reproduce the problem with the patch in the first post.

Quote: Mattijs wrote on Wed, 21 March 2007 17:04
----------------------------------------------------

> Then this might be a different issue. A patch I am currently working also has a longer shutdown than startup time. This started only recently but I don't know what caused it.
>
> Mattijs

In the mean time I found out. Check https://cycling74.com/forums/index.php?t=msg&th=25227&start=0&rid=3579&S=5e6718714d05216e0fea6454cb8f532b
But that is clearly a different issue. The original question of this thread still stands. 

bugreport: deleting bpatchers with script: takes very long, but only when piled up