Seems like it’s not really my E1 day today, sorry…
I tried to continue working on my Preset as I stumbled over another issue. There is a not really reproducible relation between the Parameter No. and the SysEx data that should be sent.
I have set up a SysEx command which always stays the same but the output changes when the Parameter No. changes. Sometimes even the length of the SysEx command changes.
I shoot a screencast which shows the behaviour. I am using the dedicated controller that is highlighted in the editor on the E1 and a MIDI Monitor shows the output. First the working example on the “Resonance” controller, then the other that behaves kind of weird.
Is this a bug or am I missing something? BTW: I read about that in some cases I need to implement the Parameter numbers into the JSON data which from my experience applies to commands containing two value bytes. These smaller commands doesn’t contain the Parameter No. in their JSON data.
Yes Parameter number is not required with single byte values.
Maybe look at the raw json.
Can you share the preset?
Why are you selecting the parameter number in the left pane? Doesn’t that imply changing the parameter number of the current selected control?
Shouldn’t you just click on the parameter you want to change?
What are you monitoring actually? what program is that?
I am on windows so cannot monitor and edit unless using a midiloopback …
From what I read and learned through my experiences so far is that a parameter number should be unique and every control needs to have a dedicated one. If you have two controls using the same parameter number they work simultaneously when one is moved. At least in my case, please correct me if I got or’m doing something wrong.
So I decided to give each control a unique parameter number in a preset, starting from 1 to … whatever.
I have setup this particular control with the correct SysEx message for my destination parameter on the instrument like I did a hundred times before in other presets. In most cases I work with copies to use the existing SysEx command and just change the few bytes that need to be changed to a new parameter destination. After that I assign a different parameter number so that it works independently. That used to work before as I created my other presets on previous firmware versions.
As you can see in the video, the output of the SysEx command changes just when I change the parameter number. And just a few parameter numbers seem to let the original SysEx data output untouched so that the control works with the parameter destination. And remember: just the output changes. The data in the JSON view always stays the same like shown in the screenshot above the MIDI Monitor display.
I am monitoring simply the output of Electra One with a very helpful MIDI Monitor (Mac only). I can’t imagine living without such a tool because it just saves tons of time for issues like this.
We probably have to wait until Martin shares his thoughts on this topic.
Sharing a preset when reporting an issue is always handy. It is easier to reproduce then.
I just tested that and I cannot reproduce that yet. I was observing the output on the USB device port though. It works as expected. I can see that your MIDI Monitor monitors “To Montage”. Can you check output on Electra Controller Port 1, like this:
yes, that is correct. Just one small correction. The parameter number should be unique per message type. ie. sysex parameter number 1 and cc parameter number 1 are considered to be two different parameters.
Do you see the same data when you use the MIDI console in the webapp?
@hape I am looking at the issue and I just noticed that the preset has controls with the same ids on different pages. In that specific example you sent, the sysex control with parameter number 3 is located on the second page.
The trouble is that in such situation - when parameter number is the same but other message bytes differ - E1 sends out the first message linked to that parameter. I will still research it more, I just wanted to share what I found so far.
I will also think about how to display the parameters on some overview that would allow to detect this easily. For now, pressing a space bar will show such information for current page.
Hi @martin, thanks so much for sharing this information.
I was further developing my pages today to cover more Elements on the next pages with the same parameters. As I moved forward with higher (and of course unused) parameter ID’s I never had any issue. I was about to share this experience with you within the next minutes but you were quicker.
I just got back to page 1 and tried the parameter ID’s that didn’t work yesterday and now they work because I deleted the previously kind of “left over” controls on the next pages. So I can confirm that it works now at least after just two tests but I am sure that was the reason. Apologies for that but I wasn’t aware of this and by far not able to get to this solution. I was thinking of a kind of cache that maybe stores used parameter ID’s and wasn’t cleared after I thought I deleted all controls with the same ID’s. But during my issues I just focussed on my page 1 and forgot about the others on the next pages.
During my intensive work today I always stumbled over the fact that not all default values were being set correctly after updating the layout to E1 as mentioned in the other post here…
I wonder if there is a workaround i.e. to place one control button on the E1 page that calls up all default values on this particular page.
Since you mentioned today the differences in the display hardware on different unit series I also wonder if the touch sensitivity of the display has been changed with one of the recent firmware updates. Since I needed to double tap a lot today to check my work I have the feeling that it is harder to set the defaults using a double tap than it was before. Is that possible?