from jit.cellblock to waveform~: focus isn't transferred

Jun 6, 2007 at 3:50pm

from jit.cellblock to waveform~: focus isn't transferred

Hi cycling,

The focus issues when using cellblock have been discussed before. The current approach is that to use keys outside cellblock the user has to click outside the cellblock.

When I click outside cellblock but instead of clicking the background I click a waveform~, the focus is not transferred to the keys object, even though waveform~ doesn’t need key input.

Guess cellblock calls for a new feature in max: every interface object should know what to do with key focus when it is clicked..

Best,
Mattijs

#32295
Jun 18, 2007 at 3:26pm

Hi, I’m sorry to raise this once more but it is a serious problem. Here is an example patch with steps to reproduce. Please have a look and tell me if this can be registered as a bug or a missing feature.

Mattijs

(note, there are loadmess’s in the patch)

#P newex 176 375 89 196617 loadmess set loop;
#P newex 243 396 146 196617 loadmess replace drumloop.aif;
#P newex 176 396 65 196617 buffer~ loop;
#P comment 22 149 276 196617 7) press space: nothing happens (!!);
#P comment 22 127 276 196617 6) click a cell in the cellblock , then click the waveform~;
#P comment 22 107 276 196617 5) press space: waveform~ color changes;
#P comment 22 87 276 196617 4) click background of patcher;
#P comment 22 67 276 196617 3) press space: nothing happens;
#P comment 22 48 276 196617 2) click a cell in the cellblock , focus tranfers to cellblock.;
#P newex 176 255 44 196617 del 100;
#P newex 176 235 30 196617 t b b;
#P newex 176 215 38 196617 sel 32;
#P newex 176 195 40 196617 key;
#P message 274 274 93 196617 brgb 255 255 255;
#P message 176 274 93 196617 brgb 100 100 255;
#P user waveform~ 176 296 200 74 3 9;
#W mode select;
#W mouseoutput continuous;
#W unit ms;
#W grid 1000.;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 100 100 255;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P user jit.cellblock 24 195 166 369 3 9 5 10 45 17 0 1 1 0 1 1 1 1 1 0 0 0 255 255 255 0 0 0 0 0 0 191 191 191 0 0 0 215 215 240 1 1 1 0 4 0 0 0;
#P comment 22 30 276 196617 1) press space: waveform~ color changes;
#P connect 5 0 6 0;
#P connect 6 0 7 0;
#P connect 7 0 8 0;
#P connect 8 0 3 0;
#P connect 17 0 2 0;
#P connect 4 0 2 0;
#P connect 3 0 2 0;
#P connect 16 0 15 0;
#P connect 7 1 4 0;

#105974
Jun 18, 2007 at 4:33pm

On 18 juin 07, at 17:26, Mattijs Kneppers wrote:

> Hi, I’m sorry to raise this once more but it is a serious problem.
> Here is an example patch with steps to reproduce. Please have a
> look and tell me if this can be registered as a bug or a missing
> feature.

I can confirm that clicking in the waveform~ object does not release
the focus. In the meantime, this workaround seems to solve the issue.

ej

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#N thispatcher;
#Q end;
#P newobj 411 425 60 196617 thispatcher;
#P window linecount 2;
#P message 411 385 228 196617 script new tutu number -112 -153 35 9 0
0 0 3 , script send tutu select , script delete tutu;
#P window linecount 1;
#P newex 176 375 89 196617 loadmess set loop;
#P newex 243 396 146 196617 loadmess replace drumloop.aif;
#P newex 176 396 65 196617 buffer~ loop;
#P newex 176 255 44 196617 del 100;
#P newex 176 235 30 196617 t b b;
#P newex 176 215 38 196617 sel 32;
#P newex 176 195 40 196617 key;
#P message 274 274 93 196617 brgb 255 255 255;
#P message 176 274 93 196617 brgb 100 100 255;
#P user waveform~ 176 296 200 74 3 9;
#W mode select;
#W mouseoutput continuous;
#W unit ms;
#W grid 1000.;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 100 100 255;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P user jit.cellblock 24 195 166 369 3 9 5 10 45 17 0 1 1 0 1 1 1 1 1
0 0 0 255 255 255 0 0 0 0 0 0 191 191 191 0 0 0 215 215 240 1 1 1 0 4
0 0 0;
#P connect 1 3 11 0;
#P connect 11 0 12 0;
#P connect 6 1 3 0;
#P connect 9 0 8 0;
#P connect 2 0 1 0;
#P connect 3 0 1 0;
#P connect 10 0 1 0;
#P connect 7 0 2 0;
#P connect 6 0 7 0;
#P connect 5 0 6 0;
#P connect 4 0 5 0;
#P window clipboard copycount 13;

#105975
Jun 18, 2007 at 4:56pm

Hi EJ,

Thanks for confirming and thanks for the workaround.

The only problem I have with the workaround is that after these script commands the patcher is registered as dirty. I get a ‘do you want to save’ dialog when I close the patch even though I didn’t change anything.

Mattijs

Quote: Emmanuel Jourdan wrote on Mon, 18 June 2007 18:33
—————————————————-
> On 18 juin 07, at 17:26, Mattijs Kneppers wrote:
>
> > Hi, I’m sorry to raise this once more but it is a serious problem.
> > Here is an example patch with steps to reproduce. Please have a
> > look and tell me if this can be registered as a bug or a missing
> > feature.
>
> I can confirm that clicking in the waveform~ object does not release
> the focus. In the meantime, this workaround seems to solve the issue.
>
> ej
>
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #N thispatcher;
> #Q end;
> #P newobj 411 425 60 196617 thispatcher;
> #P window linecount 2;
> #P message 411 385 228 196617 script new tutu number -112 -153 35 9 0
> 0 0 3 , script send tutu select , script delete tutu;
> #P window linecount 1;
> #P newex 176 375 89 196617 loadmess set loop;
> #P newex 243 396 146 196617 loadmess replace drumloop.aif;
> #P newex 176 396 65 196617 buffer~ loop;
> #P newex 176 255 44 196617 del 100;
> #P newex 176 235 30 196617 t b b;
> #P newex 176 215 38 196617 sel 32;
> #P newex 176 195 40 196617 key;
> #P message 274 274 93 196617 brgb 255 255 255;
> #P message 176 274 93 196617 brgb 100 100 255;
> #P user waveform~ 176 296 200 74 3 9;
> #W mode select;
> #W mouseoutput continuous;
> #W unit ms;
> #W grid 1000.;
> #W ticks 0;
> #W labels 1;
> #W vlabels 0;
> #W vticks 1;
> #W bpm 120. 4.;
> #W frgb 33 0 0;
> #W brgb 100 100 255;
> #W rgb2 0 95 255;
> #W rgb3 0 0 0;
> #W rgb4 0 0 0;
> #W rgb5 190 137 255;
> #W rgb6 100 100 100;
> #W rgb7 100 100 100;
> #P user jit.cellblock 24 195 166 369 3 9 5 10 45 17 0 1 1 0 1 1 1 1 1
> 0 0 0 255 255 255 0 0 0 0 0 0 191 191 191 0 0 0 215 215 240 1 1 1 0 4
> 0 0 0;
> #P connect 1 3 11 0;
> #P connect 11 0 12 0;
> #P connect 6 1 3 0;
> #P connect 9 0 8 0;
> #P connect 2 0 1 0;
> #P connect 3 0 1 0;
> #P connect 10 0 1 0;
> #P connect 7 0 2 0;
> #P connect 6 0 7 0;
> #P connect 5 0 6 0;
> #P connect 4 0 5 0;
> #P window clipboard copycount 13;
>
>
—————————————————-

#105976
Jun 18, 2007 at 5:31pm

On 18 juin 07, at 18:56, Mattijs Kneppers wrote:

> Thanks for confirming and thanks for the workaround.
>
> The only problem I have with the workaround is that after these
> script commands the patcher is registered as dirty. I get a ‘do you
> want to save’ dialog when I close the patch even though I didn’t
> change anything.

Then send clean to thispatcher :)

ej

#105977
Jun 18, 2007 at 5:37pm

Quote: Emmanuel Jourdan wrote on Mon, 18 June 2007 19:31
—————————————————-
> On 18 juin 07, at 18:56, Mattijs Kneppers wrote:
>
> > Thanks for confirming and thanks for the workaround.
> >
> > The only problem I have with the workaround is that after these
> > script commands the patcher is registered as dirty. I get a ‘do you
> > want to save’ dialog when I close the patch even though I didn’t
> > change anything.
>
> Then send clean to thispatcher :)

Ok, but what if I did change something? If I simply send clean to thispatcher I will lose my previous dirty state.

Is there a way to query the current dirty state from thispatcher?

Mattijs

#105978
Jun 18, 2007 at 5:59pm

On 18 juin 07, at 19:37, Mattijs Kneppers wrote:

> Ok, but what if I did change something? If I simply send clean to
> thispatcher I will lose my previous dirty state.
>
> Is there a way to query the current dirty state from thispatcher?

From js:

function bang()
{
outlet(0, this.patcher.wind.dirty);
}

ej

#105979
Jun 18, 2007 at 9:09pm

#105980
Jun 19, 2007 at 8:22am

Great, thanks. This will provide a fine workaround for the moment.

Mattijs

Quote: Emmanuel Jourdan wrote on Mon, 18 June 2007 19:59
—————————————————-
> On 18 juin 07, at 19:37, Mattijs Kneppers wrote:
>
> > Ok, but what if I did change something? If I simply send clean to
> > thispatcher I will lose my previous dirty state.
> >
> > Is there a way to query the current dirty state from thispatcher?
>
> From js:
>
> function bang()
> {
> outlet(0, this.patcher.wind.dirty);
> }
>
> ej
>
—————————————————-

#105981
Jun 19, 2007 at 8:33am

#105982

You must be logged in to reply to this topic.