I have some questions/ideas regarding the new performance page feature:
is en extension to the web editor to edit/create performance pages planned?
to me it makes sense to extend the Preset JSON to have additional ‘performance’ top level object, containing the JSON for the default performance page for this preset (if there is any)
if the performance page refers to controls by id, it essentially means a performance page belongs to a particular preset. Shouldn’t that somehow be made explicit in its JSON using a separate top level object “presetname” (referring to this preset)
will there be a ‘load preloaded performance page’ command? (analogous to the ‘load preloaded preset’ command?
The primary idea behind the performance page was to make it independent from the preset. To allow users to get a preset from the public library (ie. someone else’s preset) and make a customized page without modifying the original preset. The feature is new and I am sure it will keep evolving over the time. I do not have a definite answer to your question. I kind of feel that what you describe could still be a regular preset page. Providing I will allow use of references in the presets (which will most likely happen).
Yes, that makes sense. I thought about quite a lot but decided not to place that link in place in the initial release. I was thinking about using the projectId but then I realized that users may create (intentionally) more copies of the preset and still want to share the same performance for them. But I agree, using the control ids without context of the preset is somewhat loose.
hmm, did not think about that option
I’m not sure if you’ve seen it yet, but there’s a new page that describes the Performance page from a less technical perspective: Performance | Electra One Documentation
It’s not really a regular preset page because I indeed would like users themselves to make their own performance pages (even thoughI may offer a default one). Also, I like the button/swipe shortcut for the performance page so would like to use that too.
Yes, projects are opaque and may change so that’s probably not a smart thing to use. Maybe use the preset name instead, and actually do not check it (it’s just for reference, so if you find a stray performance page you can find the corresponding preset page back). Also, when supporting performance page editing in the webeditor, clearly associate/store them with the corresponding preset.
hmm, did not think about that option
[/quote]
Would be nice (so I can actually support them properly within the remote script, with the same efficiency as the preset itself.
P.S.: Did you have any more thoughts on how to allow users to manage the preloaded presets on the E1 through the web editor?
