Patch Parsing tool - testing and help needed

Hi Martin,

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.

1 Like

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.

2 Likes

Hi Martin,

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 :smirk:

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 :slight_smile: 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)


For -1 (vs. CC Midi 61)

For +1 (vs. CC Midi 66)

etc.

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?

Thanks for some clarification again :slight_smile:

1 Like

@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 ! :ok_hand:

Next try-out will be a Matrix 1000, where I might run in the same remarks as @studiobischof made here above.

1 Like

@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.

2 Likes

Thanks @martin!
I will try to use NRPNs instead of CCs for the OCS Range. Maybe that does the trick…
The documentation is here Mutable Instruments | Shruthi - User Manual

I tried it with My SY85

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 :slight_smile:

  • 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.

Just release a minor update:

  1. non-existent controls / parameters are shown when the bits/bytes are hovered or selected. It provides a way to remove them.
  2. Received SysEx message can be cleared now.
1 Like

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 :slight_smile: 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. :slight_smile:

1 Like

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.

1 Like

Thanks for the feedback!
Maybe a little “LUA Rule Module” in the editor for value transformations.

works well; took me 2 minutes to correct the ‘lost controls’

1 Like

@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 :partying_face:

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.

@martin One nice sysex feature would be to see the already linked parameters in the patch editor - maybe as a greed light in the parameter list

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…

(updated the post)

1 Like

Just published the new Shruthi Preset with Patch Request :partying_face:
Update: Also with the complete mod matrix read out!

And the Ambika preset with patch parsing is also online.
Update: Also with the complete mod matrix read out :slight_smile:

@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.

Thanks again for the great sysex simplifier!

4 Likes

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.

1 Like

Another update based on your feedback:

  1. 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.
  2. 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.
  3. 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.

ok, a few screenshots to get you going:

  1. Exporting preset and the project

  2. Importing presets and projects. Note, the app will handle upload of both preset and project files.

  3. A new option to edit Categories


  4. Assigning a category to a control

  5. Using page names and catagories in the Patch editor

Please note, I am still a bit relaxed about the UI/UX, I will tackle that at the later stage.

3 Likes

Ah, ok, got it about the midi learn mode! For UX sake: Is there a reason to have it activated besides the patch editor?