It would be really nice if there was a richer interface for the UI controls. Right now they are single directional, I.e. The control is an input to the pattern but the pattern cannot feed back to the UI - E.g. If you want to set a default value somewhere in the middle of the scale.
It would also be nice to be able to set a specific range (Min / max) for the value rather than 0>1 and to display this more meaningful value next to the slider.
For the bi-directional portion, the sliders could simply be changed from a function to an exported variable with a specific name (E.g: export var sliderSpeed = 0.5;) which would also allow the initial value to be specified. For the minimum / maximum, you could also use specially named variables or perhaps a special comment format. (JSON after a triple slash? export var sliderSpeed = 1000; /// { minimum: 500, maximum: 2000 }) You could even use this format to add additional UI information such as the units)
The function format can still be used in addition to this change, the function could still be called whenever the slider is changed and could take two parameters - A fractional (0>1) value and the scaled value (min>max).
PS: I appreciate that you’ll want to keep the firmware closed source, in particular around your proprietary scripting language - But have you considered open sourcing the UI portion?
Just wanted to say I think this is a great idea, one that I’ve asked for before. I’ve done a little work in environments (Adobe Flex, Java) that call this 2-way data binding.
I recently realized however that there’s a complication makes this a lot more challenging. The UI control values are persisted into the flash memory which has a limited lifetime of between 10K and 100K writes. When they’re stored in response to user input, no big deal. If the code is changing the values, however, Wizard will need to come up with a reasonable strategy akin to a write-behind cache. A recent thread dives into a related issue in detail.
Pixelblaze is mostly a SPA, so I’ve always considered the UI to pretty much be open source already. I’ve used the inspector/console to hack my own features in as well as occasional TamperMonkey scripts. Also, if you search the forums you’ll see curl commands for uploading a new SPA to make your edits permanent.
That’s a fair point about the persistence and flash durability issue that I hadn’t considered. I’ll read through the other thread properly tomorrow as it’s now late here, but for this particular use case (initial value) I think it can be ignored if the behaviour is changed slightly.
Instead of having full two-way data binding, only update the control when the pattern is first loaded. I.e. Only use this feature for the initial / default value. I can’t think of many (Any?) situations where you’d want a pattern to change a control mid-way through the execution - Except for validation against other sliders. (E.g. making sure that a minimum slider is always less than a maximum slider for a pair of range controls - But that is better solved with a new control type)
While I appreciate that we can already hack features in to the front end, it would be a lot easier if the source wasn’t minified - A source map would be a great first step towards this. I’d rather spend my time on features, as opposed to creating workarounds or debugging in the dark.