I'm running into a number of issues while trying to make my Stream Deck more responsive (i.e. reflecting information from applications). The ability to set images really seems to be the biggest holdback, in that you're required to place the image into a clipboard to programmatically set it, and there's no way to programmatically create clipboards. When trying to set 64 different buttons, this means having to linearly cycle through each, which is super slow, or risk having an image buffer clipboard overwritten mid process.
In order to create these buttons, I'm generating temp images in Image Magick that are set to a clipboard, written to the Deck, then deleted. Attempting to run these asynchronously would be fine, except that they're all forced to use the same image buffer clipboard, potentially colliding.
There are a number of potential solutions for this, all of which seem like they'd be useful features in general:
Expand the image dropdowns to allow for filepaths instead or requiring hard coded images or clipboards
Allow Stream Deck buttons to be set with file paths
Allow for local clipboards that are unique and volatile
Allow for programmatic creation, deletion, and selection of clipboards
I've already come up with workarounds for the following, but they'd be great to have as well:
A service that can create a preview image of any file type from a path, that matches what Finder's thumbnail view would show (I compiled a CLI Swift App using NSWorkspace.shared.icon to get this)
Programmatic creation of backgrounds, overlays, borders, scaling, etc. for images that do not require manual selection from the MacOS Color Picker or other non-programmable drop downs
I'm loving Keyboard Maestro, and the limitations have forced me to get creative at points, but some other limitations have just made it difficult to efficiently use at this scale. If I could safely distribute the image creation and manipulation into threads, it would make the entire process so much smoother.
I think I may have mentioned this to @peternlewis before. Good time to mention it again!
Forgive me if I've misunderstood the issue you're facing, but if you're concerned about clipboard clashes, wouldn't it be enough to have one clipboard per SD button? If you have a regular SD, that would be 15; with an XL, 32. Bloated, but manageable.
Can I ask what it is you're doing that requires so many button images to be set at the same time? Are you trying to simulate profile changes via KM?
@noisneil - I've always felt that the Stream Deck was needlessly static and unresponsive in Elgato's implementation, but I'm trying to avoid fully replacing their software, so I'm doing a full set of buttons per application, with a mix of Python, Applescript, SQLite and KBM to handle the logic. The issue with doing 32 buffers (err 79 for me, 2 XLs and a regular) is that you still can't programmatically set the buffer, it's a drop down. I'm having the same issue with a lack of programmability on the event triggers, and had to make hundreds of fake rows and columns by manipulating the XML of an exported KBMacro. Instead of just having a single event that would programmatically trigger the appropriate action by a parameter (something KMLink would be able to do), I had to make receptors for R203C1, R204C1, etc, which is likely eating up a lot of system resources checking those thousands of placeholder buttons.
If I made the additional clipboard buffers, I'd have no way to call the specific buffer without also making 32 (79...) copies of any read / write buffer actions, and that all gets crazy messy. Local clipboards, or adding programmability to some of the image features would totally fix this.
My end goal is to make profiles with multiple button rows serving as drawers that change the contents of the other buttons. For example, Resolve would have the 7 pages and home button on the bottom row, selecting edit would show top picks for edit on the first two rows, and groups on the third row, and highlight Edit on the fourth (and dynamically update via the Python API in case I changed pages in the GUI). Selecting a 3rd row subgroup would change the first two rows, and so on. Keeping track of usage for each category, I could dynamically update what populates the first two rows when no subgroup is activated.
This is somewhat resource intensive, and I'm adding borders, tints, etc, so being able to thread the creation and eventual deletion of these temp buttons would be extremely beneficial. I've successfully prototyped the 4th and most of the third row, but getting keypresses is also needlessly convoluted if you want to have dynamic buttons and reuse functions as much as possible. Being able to receive the ID for any button pressed (without needing individual receptors for each) would be a game changer.
