Add a parameterNumber to a SysEx control message.. how?

To speed up the workflow of creating synth presets, especially when they are SysEx and not CC driven, I would love to make a function I could use in a SysEx message that contains or is dependent on the parameter Number of the control. Haven’t found a way yet. Someone?

Example of a more generic Sysex for a control with parameter number 8

Instead of giving the control with parameter Number =8 the following SysEx :

[
  "42",
  {
    "type": "function",
    "name": "getChannelByte"
  },
  "24",
  "41",
  "8",
  {
    "type": "value"
  },
  "00"
]

I’d rather use a function that recalls that parameter Number

[
  "42",
  {
    "type": "function",
    "name": "getChannelByte"
  },
  "24",
  "41",
  {
    "type": "function",
    "name": "getParamNumber"
  },
  {
    "type": "value"
  },
  "00"
]

Reason for doing so: I could copy the same SysEx over and over again to a variety of controls.

3 Likes

That is coming soon :slight_smile: The message will be defined on the device level. Understand, users will be able to define more messages like this and refer to them in the controls.

The beauty of that is that it will save memory a lot and it will allow updating controls on incoming sysex too.

The idea was there from the very beginning of the project, but it was kind of hard to do without proper device editor UI.

3 Likes

I’ve been giving it a second thought based on your remark. I might try out one other thing that will simplify the coding for SysEx driven synths, and that is not using the controls as a Sysex, but rather as a virtual control with a function that in itself will send out the SysEx. The downside of it is that incoming SysEx messages would still not be interpreted. Patch parsing of course would be made to work.

It is on my wish list of 2023 to tackle one of the really complex synths with the Electra One. That would be the Korg Trinity series, the Roland XV.s or the Yamaha SY77/TG77. Right now I’m inclined to start with the Trinity series as being the leadt complex of these three and that will already trigger a set of new requests for the Electra ! :wink:

Happy new year!

1 Like

I use half your solution frequently. I have virtual controls and then based on the parameter number a specific sysex or regular MIDI message is constructed and sent.

It does allow a lot of reuse of functionality and I have used other data/controls to dynamically change the parameter number, name, color etc so you can build up a display that is reacting in real time and reflecting the current state if the system.

Incoming parsing is of course made more complex.

1 Like

New Year’s Resolution (up for grabs by hungry programmers):
Someone (with the programming chops) pauses specific synth-related development, and more general programming development, and dedicates a few hours a week to developing and publishing a set of tutorials (needn’t be video, tho - ignoring the fiddlyness - likely very valuable) for those of us who hardly know the difference between Lua and Lula: to do similar work to your own. Hundreds of often resourceful synth-owners - instead of the appreciable boatload of wizards presently putting plentytime into developing the E1-platform - given usable instruction sets might produce a sea-change in the platform’s development. Could backfire a bit - considering newbies by the hundreds expecting support. E1 not showing its hand in this effort until a usable tutorial body-of-knowledge is presentable might prevent that…

One heady resolution…

1 Like

I totally understand that point and I will do my best to improve this in 2023.

It has been kind of difficult so far, I pushed things hard to reach a feature set that would offer decent functionality, given the capability of the device. I do feel that it is getting there.

I have an idea of making a set of interactive tutorials online - web pages that describe the concepts but also allow users interact with Electra right from the tutorial page. Technically, everything is ready. And I will ask a few users from this forum to help me with the content. They know Electra far better than I do :slight_smile:

Nevertheless, I would also like to say, that in last few months most of the efforts went into making the editor more user friendly, making it possible to work with complex SysExes in visual way, observe MIDI traffic, etc. All this is documented at Preset Editor | Electra One Documentation.

I agree, whole thing can be made more playful, and benefits of having more people being involved and understanding the device are obvious.

2 Likes

I have spent time thinking about this and didn’t want to post in haste. I tend to solve my preset needs with LUA because I am a programmer.

Martin has spent a lot of time making the web UI and editor very full featured and easy to use.

My guess is that your question is really this:

I am a person with a piece of gear that does not already have a working template and I just bought an Electra One. How do I create an editor for my gear?

My proposal is to initially create a set of pages as worked examples of specific techniques that someone could cut and paste into their own preset.

The second prong of attack is harder. How to provide a methodology of reading a sysex dump and mapping parameters to controls. This might need an actual set of videos along with possibly some semi-generic code to parse an arbitrary sysex dump into a parameter map.

I may have more concrete thoughts as I think about it and work on my existing presets

4 Likes

Consider that an Electra One preset typically has two jobs. The first job is to send and receive data to the target device. The second job is to provide an interface to the user to allow them to see and edit that data.

That second job has a lot of common actions and controls and techniques that can be shared among presets.

The first job is quite specific to the target device and even with the newer UI often requires a user to know something about the gory details. Again, a persistent user with help from the forum should be able to get the basics of a sysex dump apart and displayed.

3 Likes

Agree, given the degree of freedom synth development teams have had in using SysEx, there are way too many different uses made in the past. If we want to make tutorials about the specific uses of SysEx we will need to make those tutorials almost per brand and per generation within a brand. But we must start somewhere… i’ll also need to think about it.

2 Likes

There might be some merit showing how to parse a simple, uncompressed sysex into the parameter map (ignoring what each value means), and also showing how to parse a ‘4 bits across 2 bytes’ format, and a packed ‘7 bits + 7 bytes’ format as well as common ways 14 bit (positive and negative) values are transmitted and parsed.

2 Likes

Yes indeed. I’m in to participate

2 Likes

This weekend, I might try taking a full preset that I have, strip out all the extras and just leave the patch.onResponse() (plus support functions of course) to show how incoming sysex of whatever format is parsed and stored in the parameter.map. In theory, if I packaged that example with a zip of a patch dump, a user could hook up the Electra One to a computer, use MIDI-Ox or Sysex Librarian and send the patch to the Electra One and see the result.

If that small amount of code was well documented, that might show the basics of “hey, here’s the dump, here’s where we pull the patch number and name, here’s the mapping to these parameters, etc”

I’ll try to make this a priority over everything else I want to get done in the studio.

3 Likes

I put up an initial example showing how I processed a system exclusive scheme that packs 7 bytes of data into 8 bytes of MIDI sysex. I’ll continue to clean up/tweak the example over the next few days.

The point of posting it now is to see if anyone finds something like this useful. If not, what’s missing/needed to make it more useful? I know most folks do not want to delve into LUA right at first. Creating a ‘JSON only’ version might make it more useful, I don’t know.

Inside the LUA code is the bulk of the tutorial text. I tried to fully document what was being done. People can certainly do things like put in additional print() statements to show more detail in the logs as they explore it.

I didn’t want to re-document everything in Martin’s on line documentation nor try to each the details of LUA programming. Martin’s existing docs should be a first stop to understand core concepts like the Parameter Map and the basics of the other functions and controls used.

2 Likes