Forums > MaxMSP

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

June 6, 2007 | 3:50 pm

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


June 18, 2007 | 3:26 pm

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;


June 18, 2007 | 4:33 pm

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;


June 18, 2007 | 4:56 pm

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


June 18, 2007 | 5:31 pm

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


June 18, 2007 | 5:37 pm

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


June 18, 2007 | 5:59 pm

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


June 18, 2007 | 9:09 pm


June 19, 2007 | 8:22 am

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


June 19, 2007 | 8:33 am


Viewing 10 posts - 1 through 10 (of 10 total)