@Fauveboy Here is a simpler version, the -1 isn't actually needed: expr-trigger-test.pd

The first button who meets the condition sets the toggle to 1 and closes the spigot. The current number is stored in the [==]. Only this button can open the spigot again: If and only if the incoming number equals the stored one and the second condition is true (1 x 1 = 1), the spigot is opened. The [change] protects against redundancy.

So I've be experimenting by combining the two...and i'd like to share some results .
@whale-av when you mention an age to the xytog. I under stand that perhaps a counter that increments with every new button press and a decrement with every minus button press? but is that not what xytog is functioning as....or is that why if i press and hold a series of buttons one by one the last one i release then jumps back to the very first on pressed...

I dont think i fully understand where the values are stored exactly ? is it that a toggle pushed down maintains the co ord position and somehow we can recall this back?

@ingox I combined what you sent to manage and allocate a row of buttons still.

What happens with the two combined is if i hold press and hold 3 15 1 then push 6 15 1, 6 15 1 wont make it though the conditions until i let go of 3 15 1.

@whale-av if I use the logic patch alone 3 15 1 can be pressed and held, then 6 15 1 can be push and the note will jump to 6 15 1, If i then release 3 15 1, 6 15 1 is then triggered again.

@ingox when your patch is isolated and if i press and hold ie 3 15 1 every other button is ignored which means i can trigger parameters on the grid without it interfering with the values within the conditional range..... I wondered if its possible with this to push and hold 3 15 1, and update a list when another note is pushed within the conditional range and revert back to what is previously held like an analogue monophonic synth synth.....

i guess xytog is one solution to this ...?

also I'd just like to add that this process is much more enjoyable and less daunting with the your help so I'd like to say i really a appreciate the support in the responses
I'm getting here

@Fauveboy You're welcome! Here is a very simplified version of what David did, if you just want an independent representation of each button in Pd: expr-trigger-test2.pd

(Still don't know exactly why you would want them to be interdependent... )

@ingox Hmm......

____@whale-av if I use the logic patch alone 3 15 1 can be pressed and held, then 6 15 1 can be push and the note will jump to 6 15 1, If i then release 3 15 1, 6 15 1 is then triggered again.

That does not happen in my model...... but then it has no real data.
It is likely that holding an xy button sends a continuous stream of messages....... but?

Maybe time to post your input messages for those key presses. Maybe the problems originate in the "sent" OSC message order?
Could you put a print from your OSC receive object, and do those key presses and then Screenshot the terminal so that we can see the exact input?

I will think about implementing aging for the [xytog] abstractions. Yes, they hold the last z value (0/1) for every xy coordinate and then send again when they receive a bang from [s update]..... but only if their value is 1 (and the bang is only sent when a button is released...... z=0). However, at the moment they send their output in the order that they execute the command, which is the order of their creation. Hence an aging value is necessary for stepping backwards.
David.

This stores the order of all pressed keys and always plays the most recent one: monophonic-keys.pd

just to give some context of the design. Im taking influence from applications such as mlr:

and digital synthesis with parameter control ….
I was imaging i need the buttons working independantly in some areas as different co-ord will have different functions and jobs that can’t intervene with each other

these are the print messages from the serialosc object:

I really wanted to try the monophonic keys.pd but the array objects arn’t recognised ? I tried including a table so see if it would be recognised to store the values in there?

I want to link this design he’s using velocity to compare to a previous value I wasn’t sure if it would be helpful yet? I think its applied differently because of the live signal and the way it receive data…

@Fauveboy [array] is part of vanilla. i think it can be done in a similar way with [coll].

Here is a version for extended (using coll): monophonic-keys-extended.pd

@Fauveboy Thanks for the osc messages. They don't look like any key was held though?..... just a series of pushes?

What are you calling velocity?.... x? y? z?...
x/y combination = note z = velocity........?
or
x = note y= velocity z = on/off..........?

If x/y combination is note then how will that be translated? Octave/semitone? other?
What I am asking is....... are the xy positions relevant...... or are they just a lot of buttons to be translated for different uses?
David.

Sorry heres some held buttons, yes its x ( col) and y (row) combination. Z is the state which is on (1) / off (0).

I think they’re relevant I’m using a row (x) to lay out the chromatic scale and y to indicate x values on a particular row. For example I can then have the octave above in the next row, or another instrument.
So i think I mean they’re a lot of buttons to be translated

I've also attached held notes for the monosynth. When I press 4 15 1 i then press and hold a couple of buttons above. If i release 4 15 0 mono synth doesn’t see this until i release the top note 9 15 0. But If i release in the other direction. Hopefully it can be seen where i release 11 15 0 it will depend to 6 15 0 / mono 6. Is that because messages are already written in an ascending order in coll ? is possible to write into coll as the buttons are pressed perhaps and reverse / delete whats in the list was buttons are released?

I thinkI just realised @ingox that im not sure if i making sense where im reporting the monophonic results im getting I guess its only required to "record" notes pressed if you're using polyphony? ...for another post

@Fauveboy In the meantime..... age tagged toggles........logic_age.zip
As toggles are set to false it will always then output the value of the previous toggle still held (true, obviously)........ released toggle and value first... last still held toggle and value next..... (see terminal print).
David.
PS....... just seen your post above. Have you got a chess playing mainframe I can borrow!

My first impression is that the data is picked up from the xy buttons by only 16 wires at the top (x) and 16 at the left (y) which is why some data in the same column / row is not sent until another button is released....... it isn't seen until the other button is out of its line......
This is what was worrying me.... and explains the differences between expected osc and what you are getting............. but maybe not......aargh!
Once I can find a mainframe, or sleep a whole night with my eyes open on your printout, I will understand or I will go mad.

I see lights in the buttons. How do they react? Do they receive osc messages to control them. It seems so, unless the buttons are set to "latch" in that photo. I don't see any fingers.
Oh!...... ok, just found the monome doc...... understood.

Sorry, so many questions.

I’m not sure I do have a chess playing main frame…

Heres another print out out from the monome. perhaps I gave false impression of its out put?

These are random button presses from th monomer 256 grid.

The trouble we’ve been having is isolating and then allocating the buttons for a particular job.

Is there any info i can fill you in on or is has the monome doc helped?

serialosc receives button press data which can trigger an LED

because logic_age is a solution for polyphony i think for the behaviour…it would be like hold a chord and releasing notes

This also sends the note-off for the previous note:
monophonic-keys.pd
monophonic-keys-extended.pd

i also made an analog version, where only a higher note is played:
analogmono-keys.pd
analogmono-keys-extended.pd

the monophonic keys seems most effective because it now doesn't jump to zero when the notes released as did the previous one, it meant note zero would launch when the last note was released....if you can see in the attachment the note off happens when the gate is closed. when the trigger is on it opens an envelope gate and the note at the time is released...i just released does this mean the envelope gate needs to be triggered for every new note for each new button press?

@Fauveboy You can get the triggers of the note changes from the noteon/off number boxes. The toggle only indicates if any key is pressed or not. You can see how they behave in the print result of the posted patches.

the envelope in this attachment is what ive been using between the button press and the signal. Where I previously used the toggle indicating on or off to to open the envelope gate should it look something ore like this?

@Fauveboy You can do it like this:

sorry i mean like this works

can i just add Im using one sample to trigger all the notes Ive organised the sample like so
the screen shot illustrates, twelve notes evenly distributed. Ive bounced it out and stored the file in an array of course. I've then used a phasor which counts from 0 to 1 playing the length of the sample. I 've used the off set you see 0.09 + 1 to try to evenly divid the sampled notes so that on every interger value note pressed re positions the phasor signal cycle.... it doesn't however divide precisely. How is this the wrong maths for the job?