something very relevant: if you assign bits or bytes to a control, and then change the control (type, paramter number, or simply delete it) then this assignment remains in place, but you can’t delete that assignment anymore, unless you remeber the type and number that control had.
What also would be of help: when you click on assigned bits, the app should show you to what control it has been assigned to.
Yup, I ran into the same problem. When I worked on my presets I have eventually done it in two steps. In the first step I use a convention when the names are always unique. eg. VCF KEY AMOUNT, VCA KEY AMOUNT. When all the SysEx work is done. I will start working on the layout, using groups, and nicer control names. It is a work around though. What I am thinking about is introducing an extra attribute ‘Category’ that could be used to categorize the parameters. And indeed, display the info about the page in the list.
This actually brings us closer to the original idea of the Instrument files. If there was a way to create and edit the Control directly in the Patch editor, one could work on the synths implementation without thinking about the layout, merely preparing a palette of the controls that could be used later.
something very relevant: if you assign bits or bytes to a control, and then change the control (type, paramter number, or simply delete it) then this assignment remains in place, but you can’t delete that assignment anymore, unless you remember the type and number that control had.
What also would be of help: when you click on assigned bits, the app should show you to what control , but certainly what parameter number, it has been assigned to.
In the mean time I run into that problem. Changed a parameter number, but totally forgot which one it originally was, then discovered I already had set the parsing… This time couldn’t guess the old values. So I sawed off the branch I was sitting on
Now I have a question on how to go on with “complex” parameters that are handled differently in SysEx vs. the Midi implementation.
The editor works fine for normal parameters reaching from 0-127 or 0-63 But the Shruthi handles negative values a little bit different in SysEx compared to the CC Midi values… i.e. the OSC Range goes from -24 to +24 and via Midi CC from 0 to 127. So on the Electra I scaled the Midi CC values from -24 to +24 for display.
In SysEx I get these Values for -24 (vs. CC Midi 0)
My noob question: Can I handle these values via the editor, editor + json rules or is this a case for lua to convert them into usable values to display?
@Martin,
The first series of tests are finished. I’ve made a really useful Blofeld Preset with patch request. The few remarks I have, are already documented. Brilliant Martin !
Next try-out will be a Matrix 1000, where I might run in the same remarks as @studiobischof made here above.
@NewIgnis@studiobischof I will dive into it today. I was busy with other stuff last few days. I will try to tackle all suggested points. And I will look at the shruti’s midi implementation.
I added the request via JSON anyway as for a the patch dump request for the SY85 is 29 bits long. Though I can see how the “add byte”-function is nice for synths with shorter requests
I could find no function to rename the request? First one is “Default Request” and next one created is “Additional Request #1” etc. I also could not find in the request names in the JSON tab.
(And to answer an earlier question “Why are there more request possible”: because some synths have different “structures”. The SY85/TG500 for examples has voices, performances, drum voices plus more.)
Line / byte numbering: at first I thought it was missing. But after you define the header you see the bytes beneath it starting at 0. Though this column was empty initially and it was not obvious you should click the empty column to set the header as the columns also have no headers.
No available yet, it is planned to be added though.
@L56 would you share your preset with me (a URL link)? I have TG500 next to me I would use it for further work on the Patch dump editor. I would be running into the same issues as your are then Thx!
@martin Sure, but it only has the cuttoff control for now. Well almost. My bits do not want to turn blue. Trying to figure out what I am doing wrong.
Edit: found it. Forgot to click the parameter on the left first. You said almost anyone could do this. I almost proved that statement. Almost everyone
From before I tried this new way I have a partial editor but that was made by parsing a simplified midi data sheet with a python script to output JSON arrays which I would then copy into the electra one editor. Don’t ask.
I took a look at Shruti’s implementation. And yes, the patch dump is using different representation for numeric values than the CC/NRPN does. It comes out of the fact that the SysEx patch dump is merely a transfer of Shruti’s memory image and the negative numbers are in two’s complement format. The CC/NRPN always uses range 0…127. I do not think there is way to handle this without Lua now. I will give it some thinking time, I am sure there might be a simple way to tackle that.
@martin I had some time to look into the shruthi midi implementation and the ambika again. It turns out that my ambika sends and recieves nrpns that have the same values as the structure in the sysex dump. So I can readout the sysex correctly via the editor and update my electra preset
The shruthis only sends midi cc’s out - they seem to have changed from nrpns to cc after some user complaints. So it looks like only the shruthi need this extra work to convert the sysex values to midi values that match the control in the electra… And if I sacrifice the bi-directional midi feedback between the shruthi and electra knobs I can use the nrpns controls on electra that are understood by the shruthi and work with the dumps correctly.
It would also help in the normal editor - maybe just a text like “Parameter linked to SysEx” or a dot next to the parameter device graphic. I had some trouble having a good overview which parameters I already linked… But working with the electra display and the patch editor search works nicely in the end.
And when creating some new parameters it would help to directly jump from the normal editor to the selected parameter in the patch editor for fast linking to the sysex…
And the Ambika preset with patch parsing is also online.
Update: Also with the complete mod matrix read out
@Martin, I had one problem: Not changing the patch editor back to “disable midilearn” when closing the editor left the electra unresponsive to patch request till I went back into the editor and switched on/off again. Maybe you can disable midilearn with closing the patch editor view.
It is actually expected behaviour. I just need to make it somewhat more obvious. When Electra is the MIDI Learn mode, it transforms all incoming data into special messages and sends them to the editor app. The actual message is not processed as in normal mode, ie. patch request not processed, controls not updated, etc. Writing this I think it would be quite handy if Electra showed info that it is in the MIDI Learn mode on the LCD.
It is possible to create categories of controls and assign them controls. Categories are meant to improve organization of controls in the preset. They do not, however, affect the preset data that is transferred to the controller. It means, the controller does not display / work with the categories.
As categories are meta information and therefore they are not part of the .epr export, I have added a new option to export whole project. The project is a single file containing the preset, Lua script, and meta info, such as categories, description, etc. If you want to make a local backup of your preset, exporting the project is the way to go.
Page names and categories are shown on the list of parameters in the Patch editor / Responses tab. This is to make it easier to get oriented and make distinction between controls that have identical name.