I would say so. Look at the help file for jit.lcd to see how to specify co-ordinates for a line in a window/pwindow.

An idea how you may do it.....

All you would need then is something like a coll object to store a list of values to add to your current position. For example if a 'C' is a right movement, the new position could be:

(X(old) + Increment, Y(old) + 0)

If you number each midi note accordingly e.g A = 1, A* = 2, B = 3 etc etc the list could be used for every octave (may also need to look at the modulus (%) function).

So for the 'C' note example the line in the coll may say:

4, 10, 0;

where 4 = note number 10 = x change 0 = y change.

to increment the 4th note of the chromatic scale (C) by 10 in the X direction and 0 in the Y direction (unpack the values and use accordingly).

Not saying its the only/best solution but hope that gives you an idea.

Andy

Yeah I think Coll is a good choice as well, I make extensive use of that in my MAX patch. Im just not sure how hard it is to draw lines in a jitter matrix, bcs I haven't even looked at the tutorials.

I would def start at the bottom left, use % 12 to analyze what the note is, and then access the col to see if I increment the X or Y position....I guess what im asking is...once I decide the note is a D (for example) and I want to increment the X position by Z pixels, how hard is it to make jitter SLOWLY draw a line from current position, up Z pixels? If it's not toooo hard I will dive into the tutorials right away.

Right I see.

I suppose it depends upon how you want it to be controlled. The jitter part of all this is easy as it is really just a matter of updating and drawing a line - which is a simple command. The logic part is the tricky bit.

If you want it to move in set increments you will need to consider that a note could be pressed at any time (I'm assuming that you want this to be part of a performance tool?). If this is the case do you want to:

a) have the line constantly moving - if so the chosen note just changes the direction of movement.

In this scenario the movement will need to be calculated continuously at regular intervals - e.g use a metro to add/subtract appropriate values to/from the position indefinitely (every 20ms for example) and just alter the polarity of the added/subtracted value for x and y to specify direction.

or

b) have the line move the a set amount per note played in a direction specified by the note - in which case does the note interrupt the current movement or does it wait until the movement from the previous note before it takes effect?

In this scenario the same metro setup will be needed to bang through the calculation but you will need to set it to move 'x' amount of times until the desired distance has been achieved. So moving 100 pixels over 100 ms will require a metro at 10ms to add 10 to the current position each time - test it to see if 100 has been added and then turn off the metro. (maybe use in conjunction with a counter - which can be rest to zero if a new note is played if thats the way you want to work it)

Any good?

Andy

I got it working at least. Just storing move up down left or right positions in a coll and calling them into an accum.

Its nothing fancy and the output isnt too interesting yet, but oh well.

Right now I am sending a setcell x y val $1 command to jit.matrix 1 char 1 120 120

the val $1 is controlling the "whiteness" of the fill...is there anyway to make it a color? I cant get that to work, its only a grayscale.

Here is the patch: