CACHEUI - a lightweight GUI library with DMX, MIDI, & OSC

CacheUI v2.0, by Imaginex, is a fast, lightweight UI widget library with simple mapping features for MIDI, DMX, OSC, and Keyboard devices.

** Works in 088 & 099. **Built with Python **Based on Peter Sistrum’s cache select techniques.

For a full list of features and instructions, visit this link: [url][/url]


  • Lightweight | 0ms cook-time gui elements when not engaged; ultra low ms cook-time when engaged. (Thank you P.Sistrum!)
  • Mappable | Learn & forget tool for MIDI, OSC, DMX, and keyboards devices.
  • Customize style | Use custom parameter page to change styles of UI elements.
  • Settings menu | View and delete mapped channels and devices.
  • UI Library | buttons, value fields, sliders, and tab menu.

2017 | Extended library, custom params, and 099 compatibility. - Eric Mintzer, Lucas Morgan
2017 | Added mapping tools for midi, osc, dmx, and keyboard devices. - Eric Mintzer
2014 | Initial release of technique and asset library. - Peter Sistrum

“Please share if you make cool modifications!”

Imaginex is releasing this software tool under a GNU LGPL V3.0 software license. This gives users the ability to use, modify, and redistribute, as long as you leave attribution and original license in the final product.

[size=50]tags: python, gui, cache, ui, custom parameters, params, dmx, midi, osc, keyboard, learn, forget, map, menu[/size] (1.27 MB)
cacheUi_v1.0.tox (359 KB)

1 Like

Looks cool, the mapping if nifty.

You might be able to squeeze more performance out if you convert your scripts to tscript as well. I noticed entering a value in a value field was particularly slow (around 1ms on the slider horz).

The cache top system is quite fast, but the overhead of all the ops controlling the logic ends up putting the engaged slider horz at 0.1 - 0.3ms, which can add up. I think there’s room to simplify elements like the text cache lookup that might give you quite a bit of time savings. I always try to figure out ways to do things with less ops and no scripting, which unless I do something completely strange, will be in the top contenders for lowest cook time methods.

Nice share!

Elburz, Good eyeball on the valuefield; this should definitely be faster.

The python methods for controller-based value changes can also be improved. Generally, It was a tough balance of human-readability vs performance and I ultimately decided to avoid tscript. I think an even faster route would be to use overideCHOPs from controller data, and scripting will automatically connect & disconnect this node depending on if it is mapped or not. Avoided this for simplicity reasons… for now.

The sliders are actually quite fast (without the value field). I am clocking under .08ms which is about 3x faster than the default sliderCOMP.

Definitely would love to see these methods expanded upon. Here’s a list of these limitations and more that can be improved (and shared :slight_smile:


  • Many values changing via external controller runs slowly due to python loops.
  • Data Inputs have limited amount of sources (DMX limited to 1 universe, MIDI to 1 controller, OSC to 1 port, Keyboard doesn’t do special chars)
  • Value input is slow on click; especially first click[/list]

The eternal battle!

UIs are still a toughie. Thanks for sharing it. :slight_smile:

CacheUI v2.0 is here! Scroll up to the original post to download the new version.

Now includes compatibility with 099, many more design options in the parameters page, and various speed and bug improvements. Get it while its hot, and read more about what’s new and how to use it here: [url][/url]

Backwards compatibility warning: Old cacheUI elements will no longer become color coded when mapped. You must upgrade your cacheUI elements to the new version for the color coding to continue working.

nice work emintzer!

I was looking at the “Learn” pop up window and you might consider a refactor here to use the table COMP. I love this thing, especially for these kinds of UI elements. They tend to be very fast and lightweight, and are really all just based on look-up tables.

Here’s a quick pass at what the initial stages of a refactor would look like:
container_table_example.tox (2.98 KB)

A quick note: I was making this one on an old mac book pro tonight and noticed inconsistent behavior here. Sometimes they act like windows where they cost nothing, other times they’re a little slower. Not sure what the difference is exactly - on windows it should be very snappy.

Great suggestion Ragan! Will be adding this to the next update. Thanks!