Hi Mark,
updated schema is pushed to the ElectraOne repo. I have not done the descriptions, etc. Will keep updating it, feel free to send PRs. Thx!
1 Like
thanks will check it out tomorrow.
heads up… as minor issue
Ive noticed that the Virus.epr which I converted from the version 1 preset has invalid overlay entries according to the new schema.
I think the schema is correct, as you can see below … so perhaps an oddity in the editor or conversion process? (see value is a string not int)
{
"id": 12,
"items": [
{
"value": 0,
"label": "Off"
},
{
"value": "127",
"label": "On"
}
]
},of course the good news, is its shows the schema is doings its job 
p.s. a useful online schema validator
(i.e. one that tells you where the json and schema mismatch, rather than just its not valid 
)
1 Like
I’ve been writing some code to create presets, and been using the schema to help me do so.
I’ve noticed a few things in the schema whilst Ive been writing this code.
potId on control & (sub) inputs ?!
I’m a little confused about this in the schema (& its example)
I thought pot id should only be a the input level…
what does it mean to have both…
if we look (in schema example) we see control id = 13
{
"id":13,
"pageId":1,
"bounds":[
0,
216,
316,
146
],
"controlSetId":2,
"potId":1, <--------- WHY? individual inputs have pot mapping
"type":"adsr",
"name":"ADSR",
"color":"F49500",
"inputs":[
{
"potId":1, <-- e.g here, and below ---v
"valueId":"attack"
},
{
"potId":2,
"valueId":"decay"
},
{
"potId":7,
"valueId":"sustain"
},
{
"potId":8,
"valueId":"release"
}optional values?
there also seem to be some things in the schema that are optional but Id expect to be mandatory
control.name
control.page_id - although, appears page are optional? I would always expect one page.
min/max on value/message?
colour
colour is a string, due to it being “FFFFFF”
perhaps it should be numeric… we can use in code 0xFFFFFF
general thoughts?
schema enums
if the schema is now the master source, (so can be edited, rather than generated), perhaps we could add enumerated values
this allows developers to see the permitted values.
example usage are:
control.type = fader,dial
control.mode = momentary
message.type = cc7,sysex etc)
control mode, was the one I was unsure on… and made me wonder if json schema could contain
also… if there really are limited colour values (?), we could detail these.
(from above link, seems numbers can also have ranges)
strip example from schema?
I quite like the fact the schema has example, but it makes it extremely verbose.
(because the example is repeated/broken down at each level)
this makes it pretty difficult to edit it… as its hard to get an overview.
also…the example, is only worthwhile if you keep it up to date at all levels.
I wonder if we should remove it from the schema.
and perhaps just have a separate ‘schema-example.json’ which contains it…
Im not that versed with json schema, so Im not sure what the common practice is when schemas get quite large like this
Hi Mark,
I will do that enums, options, required, etc. The schema that is in github now is really just a generated one for the start.
Inputs is valid syntax. The fact that potId is present means that some of my demo presets still have it in there. I will clean it up.
It came from the generator. I think these needs to be edited manually.
I think hex is supported as of JSON5. I am not there yet. That is why I picked the string notation for it.
Yup, I agree. It is actually my next step in editing the JSON schema.
I kind of like the examples, but I agree we can keep it outside the schema itself. I added number of pads examples to the github. Will do the same with other control types. That should be sufficient.
1 Like
another dev documentation ‘typo’
0x00 Preset file
this is incorrect (in all places its mentioned eg sysex and text)
0x01 is used for preset
lots of progress being made here though
EDIT:-------
I seem to be getting invalid sysex back when requesting info
F0 00 21 45 7F 7B 22 76 65 72 73 69 6F 6E 54 65 | !E {"versionTe|
78 74 22 3A 22 76 31 2E 31 2E 36 22 2C 22 76 65 |xt":"v1.1.6","ve|
72 73 69 6F 6E 53 65 71 22 3A 31 30 30 31 30 30 |rsionSeq":100100|
36 30 30 2C 22 73 65 72 69 61 6C 22 3A 22 45 4F |600,"serial":"EO|
31 2D 31 32 33 34 35 36 22 7D F7 |1-123456"} |
im getting 7F7B, when Im expecting (as per spec) to get
0x01 0x7F
edit 2:
ok, to be clear : above we can see that whats happening is the response is missing 0x01
(the 7B, is the {, as expected)
I seem to be having problems with other requests… 
so need to go check what the web editor is doing…
An update JSON schema for preset pushed to the github. There are still a few bits missing, but far improved from the original generated version. The sysex data object still needs to be done. @thetechnobear please test it with your presets.
I am a bit puzzled here. 0x00 is used for Preset file.
0000 F0 00 21 45 01 00 7B 22 76 65 72 73 69 6F 6E 22 | !E {"version"|
0010 3A 32 2C 22 6E 61 6D 65 22 3A 22 4C 69 73 74 20 |:2,"name":"List |
0020 64 65 6D 6F 22 2C 22 70 72 6F 6A 65 63 74 49 64 |demo","projectId|
0030 22 3A 22 54 6A 51 71 64 72 4D 69 4F 59 71 52 32 |":"TjQqdrMiOYqR2|
0040 5A 4D 46 58 72 52 61 22 2C 22 70 61 67 65 73 22 |ZMFXrRa","pages"|
This is correct. the 0x01 is missing there. Electra previously used just 7F as the mark for the electra info message. The query (0x01) command was added to the request but I forgot to add it to the response. I will fix it.
Due to limited resources for calculation of anti-aliased graphics, only six colours are supported now. They are listed in Preset format description | Electra One Documentation and they are in the JSON schema enum now too.
1 Like
the web editor is sending 0x01 0x01
F0 00 21 45 01 01 7B 22