seejayjames

I see that when you select a cell using the mouse, the key focus shifts to the cellblock. This is OK and understandable, but it removes the possibility for keyboard controls elsewhere until you click outside. However, using "select" message doesn't put key focus there.

What I'm wondering is whether there's a nifty way to remove key focus from the cellblock without clicking. Maybe if one cell's output would be "select number box" or something, so the focus is removed from the cellblock? A specific keystroke to "exit focus" would be great. Though, I don't know where the focus would then go... anywhere is OK, preferably "nowhere" (like clicking on the background). This way one can edit/select cells for awhile, then easily remove focus and be able to use global keystroke commands.

Along those lines, is there any way to APPLY the focus to the cellblock without clicking on it (i.e., using a controller, metro, or a keystroke)? Though I'm not sure what that would mean, exactly, perhaps selecting cell 0 0 as a default or something.

jit-cellblock-key-focus-question

I've dealt with the same problem. The search for a solution has led me to believe that there is a basic decision to be made for the patch in question: when should the jit.cellblock have the focus and when not?

For myself, I don't mind to just click on the background to change focus, but this proves difficult for the people with whom I work, and when a pressed key has no effect at a crucial moment, this can upset a performance. There are three ways I've dealt with this:

1. Instruct the jit.cellblock to "ignore click" and navegate using the arrow keys which trigger commands ("select 0,1", "select 0,2", etc.) This works well with sequencial commands such as a cue-list. Drawback: in order to skip cells, the user has to press "esc" to close a gate at the outlet of the cellblock and step through the entries until he gets to the desired cell. Another drawback: this only works for short lists, for the "ignore click" option also disables the scrolling function.

2. Use the same "ignore click" option, and use the mousestate object to report on where the user is clicking. This can be translated into a select command. Drawback: obviously, any time you change the position of the jit.cellblock object or open another window, you will be getting erroneous information.

3. (this is what I now use) a while back, I wrote an object I call XPmouse. It emulates mouvements of the mouse, and the user can enter the x,y coordinates and left or right click. It is useful for installations using Max with other programs, but has little use in Max itself. It gave me a quick solution for this problem, however. Every time something comes out the outlet of a jit.cellblock, XPmouse is instructed to reposition the mouse outside the cellblock and click on the background. (It can then set the mouse back to where it was, if this is important.) Drawback: it does not do this after scrolling. As the name states, however, it only works in Windows XP

I've dealt with the same problem. The search for a solution has led me to believe that there is a basic decision to be made for the patch in question: when should the jit.cellblock have the focus and when not?
For myself, I don't mind to just click on the background to change focus, but this proves difficult for the people with whom I work, and when a pressed key has no effect at a crucial moment, this can upset a performance.  There are three ways I've dealt with this:

1. Instruct the jit.cellblock to "ignore click" and navegate using the arrow keys which trigger commands ("select 0,1", "select 0,2", etc.)  This works well with sequencial commands such as a cue-list.  Drawback: in order to skip cells, the user has to press "esc" to close a gate at the outlet of the cellblock and step through the entries until he gets to the desired cell.  Another drawback: this only works for short lists, for the "ignore click" option also disables the scrolling function.

2. Use the same "ignore click" option, and use the mousestate object to report on where the user is clicking. This can be translated into a select command.  Drawback: obviously, any time you change the position of the jit.cellblock object or open another window, you will be getting erroneous information.

3. (this is what I now use) a while back, I wrote an object I call XPmouse. It emulates mouvements of the mouse, and the user can enter the x,y coordinates and left or right click.  It is useful for installations using Max with other programs, but has little use in Max itself.  It gave me a quick solution for this problem, however.  Every time something comes out the outlet of a jit.cellblock, XPmouse is instructed to reposition the mouse outside the cellblock and click on the background. (It can then set the mouse back to where it was, if this is important.)  Drawback: it does not do this after scrolling.  As the name states, however, it only works in Windows XP


Thanks Dayton, those are some good solutions. I think I'll try the "ignore click" and maybe see about using mousestate. Since my cells are sizeable (I'm making a "beatbox" kind of matrix with settable number of channels/tracks/rows, and settable number of beats/cells/columns), it could be a bit of a trick to keep track of the dimensions etc., but some nifty math should make it OK for any arbitrary configuration. I'm keeping the overall size static at 768 pixels wide (this makes for even spacing with the most common measure-lengths, like 16, 12, etc.), so at least that won't be YAV "yet another variable" to deal with... ;)

Also I'll see about having certain cells output a code that will open/shut a gate, or ignore/respond to click. Perhaps I'll have a gate at the outlet that, if open, will automatically shift focus back outside (to an appropriate number box perhaps). So in this mode, users can click a single cell, but not stay "bound" in the cellblock (unless they want to).

Thanks Dayton, those are some good solutions. I think I'll try the "ignore click" and maybe see about using mousestate. Since my cells are sizeable (I'm making a "beatbox" kind of matrix with settable number of channels/tracks/rows, and settable number of beats/cells/columns), it could be a bit of a trick to keep track of the dimensions etc., but some nifty math should make it OK for any arbitrary configuration. I'm keeping the overall size static at 768 pixels wide (this makes for even spacing with the most common measure-lengths, like 16, 12, etc.), so at least that won't be YAV  "yet another variable" to deal with...  ;)

jit.cellblock key focus question