Still working on my MIDI step sequencer, I want to use an array to let the user draw velocity values for each of the steps in the sequence. Is there any way to prevent the user from drawing outside the boundary of the array? The array is defined to have a lower limit of 0 and an upper limit of 127 (the valid range of values for velocity in a MIDI note msg). I can clip the values, of course, to fall within the range of 0 to 127, but it would be nice if I could prevent invalid values from being drawn in the first place.

@dfkettle This could work:

clip-array2.pd

Thanks! It does exactly what I want. Where can I learn more about "ping" and other Pd messages? I never would have guessed that a "ping" msg is sent when you update an array. I found this page on the web site and downloaded the zip file containing examples, but couldn't find any example for "ping".

https://puredata.info/community/pdwiki/PdInternalMessages

And why is the [delay] needed?

@dfkettle I can only explain it in the way i understand it: Pd consist of the core and the graphics implementation. Between these two messages are been send. [r pd] receives these messages. You can see this when you connect [r pd] to [print], open a preferences dialog and click ok. The same way you can send messages to pd using [s pd].

So [clip-array2] is a hack and is activated at random times when interacting with the patch. Whenever the array is changed by mouse action it sends a ping, that is way it works.

I don't know if this is documented. I learned about it from this forum.

@ingox @dfkettle The ping hack probably doesn't work when writing the array on OSX..... but does in Purr Data....... so that might be a problem for the sharing of the patch.
https://forum.pdpatchrepo.info/topic/12892/how-can-i-trigger-a-message-when-any-array-value-is-changed
The problem can be solved for OSX with the experimental mouse plugin...... you will find it in the same thread.
Plugins need to be where Pd can find them as it starts up though....... so they must be in the bin folder or another that is "known" to Pd.
That means if you distribute the plugin you will need a "readme" to tell people how to use it as [declare -path] in your patch will not tell Pd where it is until after Pd has started.

See also @jancsika 's note about the array size and ping (same thread)........ (GUI_BYTESPERPING).
David.

@dfkettle Another way could be to build an array with data structures...

@whale-av I don't have access to a Mac, so I wouldn't be able to test it. I wouldn't want to distribute an experimental plugin if I couldn't test it myself. Is the Pd architecture different on Mac, Windows and Linux? The "ping" message doesn't exist on Mac? What about Linux?

@dfkettle I use windows...... so I don't know why "ping" doesn't work on a mac and I don't know what other systems it might work on or not.

Plugins will work for all systems as they are run by the wish application...... not Pd.
Plugins are only run (added to the tcl code for wish) when they are found by Pd as it starts.
They don't change anything in the Pd program.
If you delete a plugin, or move it somewhere that Pd does not search (see Pd Path Preferences) then when you restart Pd it is back to normal......... so no permanent damage can be done by a plugin.

The wish application is used by Pd for window drawing, building the window menu tree etc.
You can look at the tk/tcl code used by Pd in the Pd/tcl folder...... it is fascinating.......
David.

@dfkettle In case it helps I have made a very simple plugin to use with a slightly modified version of @ingox's patch. It allows the patch to set the limits as the mouse button is released and should work on all platforms.
It does not require a [receive] object so the only error reported is that Pd does not know the message.
maybe.zip

It could be that using @ingox's original patch and setting the plugin to send "ping" instead of "mouseup" would work on other platforms.
That would probably also entirely suppress error messages but until you get some feedback on the forum we will never know.
David.