DSP Robotics Support

Christmas are on the way, so here is a small contribution, that some of you may find useful. I was inspired by Nubeat7 (his multifunction slider concept showed me how certain things work), and Trog helped to solve typical to expect cross-situations.

This editbox will help to limit "clones" in your projects, which is good for gui performance and project size. Such single editbox can be used for storing and dealing with multiple values (single mode, cross mode, including/excluding policy), and it also should work better with preset manager (1 preset related prim vs 10 preset related prims). Only 1 ruby module inside, so no problems with multiple units.

While I did simple tests with "100+ presets" and it seems to be fine - it will require harder testing, under streamy load. Also - I tested it only with small arrays (16 elements), I guess the upper limit for usability may be around 30-50.

Generally it is more or less final version, I included some additional notes and thoughts. Check if there are any bugs (typical usage, preset system related). Be careful with optimizations (trigger order and distribution, relationships).

Merry Christmas!

Updated version.
Randomizers are now trimmed to fit the 6 digit preset format.

So many downloads, so many views, and no comments nor simple "thank you". As if such little editbox, that allows undo/redo and cross-randomization, and multi-parameter handling at once - was so simple thing to do (not difficult, but not the simplest too). As Trog pointed recently - people grab what they can, and leave (when they still can ...). Maybe instead of views and download stats - there should be some replacement text, like "thank you" counter? I admit - I did not see any forum, that would approach it this way.

Anyway, another useful tool. Context menu, that can be used for multiple triggering. Trog - any issues to pay attention to? At least one thing is ambiguous (rclick triggers work on background guis)

my apologies for the 'hit and run' ...

between holiday stuff and getting new health insurance coverage ... its' been knutz

hope to open presents later tonite

Thanks!

That's rather nice! - I like the way that the context menu stays open for multiple clicks; very useful alternative to the usual 'click once - closes' contexts menus.
Would be nice maybe to add properties for the button size, and some kind of string or string array to give each button a label (or maybe I missed how that is done? - not on my "big" PC this morning).

tester wrote:t least one thing is ambiguous (rclick triggers work on background guis)

It's strange that this isn't mentioned in the user guide - it must be a common enough requirement. But it is simple to do - just connect primitives for R-Down, R-Up, Double clicks etc. to your mouse area. It doesn't matter if the trigger outputs are not used, the primitives will still "capture" the mouse events and prevent them from "falling through" to layers beneath.

I have a module in my toolbox that I often use - just a container with one each of every mouse action primitive. I just make a trigger output for the ones I'm going to use, and leave the others unconnected just to "catch" the unused mouse events.

Ruby is similar - mouse events look through each GUI layer to find a module with the "mouseLDown(x, y)" etc. methods, and act upon only the first one that they find.

I'm minimalist, there are no optiopns nor labels. What you can set right now for the context menu - is the "area size for single button" and "size of button within it's area". Then you need to stretch the parent view, to fit the whole area.

As for adding more buttons vertically or horizontally - you just need to copy row or column of modules, and wire modules respectively (adding multiplier part if there are going to be more rows/columns there), to have automatic XY coordinates of placement. Thus - it is good to name the output trigger node, to know which one is it.

As for buttons - you may sync them, and create a template within single one, with all gradients, clickshifts, texts and so on. It does not matter whether you will edit labels inside buttons or create an array, and push inside buttons "string get at" - you would need then to set labels or IDs anyway.

Things to do (for me):
- the spread of clicks; depending on where you activate your context menu - clicks should be redirected somewhere else - via multiplexer for example
- button activators/deactivators; so you could use uniform context menu, and if at certain places some functions are not available - these buttons will be greyed out and blocked.

These two things will make the context menu dependent on gui area. If you wish to have uniform context menu on whole gui - you just need to rewire XY coordinates for menu appearance for general gui vs mouse position. Then - you may need to focus on keeping the menu within gui boundaries.

The menu is thought to open and be available for multiple clicking (related to single parameter - randomizers, undo/redo, and so on). Having not too much space on gui - it's better that way.

As for labels - I would use symbols for typical functions, like copy, paste, randomize, clear, block (exclude/include), undo/redo (first/last), and so on. It may look like this: <, >, r, c, e,... If you use standarized symbols across your applications, then it should be easy to remember.

*

I encountered one problem. If I shift a subgui on a main gui, then I have no way to get XY coordinates of that subgui in relation to main gui. Alternative option is to provide XY coordinates manually (via float prims connected), and then they can be used.

On attached schematic - there are 4 test "buttons".

In the bottom lineset with 3 of them - first tp the left is "reference" (fixed position with floats), and two other are shifted right on gui. Second to the left is blocked when menu is activated, and third - has no such blockade, it just tests mouse clicks when menu is on. If you activate the menu on first button (rclick), and then move your mouse so that in the bacground you have second or third button - then you may do the test. As you can see - rclick is received by third button (the one without blockade), thus - it may be a problem on your schematic if you use rclickers for other functions.

It's strange that this isn't mentioned in the user guide - it must be a common enough requirement. But it is simple to do - just connect primitives for R-Down, R-Up, Double clicks etc. to your mouse area. It doesn't matter if the trigger outputs are not used, the primitives will still "capture" the mouse events and prevent them from "falling through" to layers beneath.

I'm blocking triggers on main gui when context menu is activated. Otherwise, r-clicking on context menu would affect some r-clicking on main gui.

Added trigger handling. If you call context menu in 1st place - triggers are sent to module 1, if you call context menu in 2nd place - triggers are sent to module 2. Example trigger "1a" is moved outside.

This approach uses buses. If buses used for greenery interfere with streamy part (glitches), then another way would be to send it via arrays. It is not so complicated, but no need to explore it if there are no requests.

Third thing to do here will be - to activate selective context menu elements (depending when you open the menu), so that you can have all "on board", but part not used for particular clickers - will be greyed and blocked. Thus - you will get complete context menu system for your apps.

...and this is so or else final functional version. Visual improvements (like onclick blinks, separate horizontal scaling) are up to you.

So - things to remember.
1. Wiring the "call" button/area: only things in the first layer (to send xy coordinates) and triggers, plus - optional wiring on mouse clickers.
2. Within destination module where triggers are used (whether this is an editbox or some sort of field) - assign triggers
3. Within context menu: "which ones" definition and naming your labels.

I think it' should be simple to use.

p.s.: in order to call the menu on second field, while it is open around another one - just do mouseover on the menu. It is better that way, because context menu may cover functional buttons while using, and then it would cross-interfere. But I think this is why right clicker works while left is blocked - to allow calling an object from other point of space while it is still active on that part of the space.