Instrument Files

Developers
1

I’m trying to create a Virus TI Instrument File.

How do I specify
In the Preset Web Editor, I can setup values like so:

image
image594×642 22.6 KB

So there are Display Value Parameters and MIDI Value Parameters
But in an Instrument File I seem to have only the latter, like this:

  "parameters": [
    {
      "categoryId": "OSC 1",
      "data": [
        "F0",
        "00",
        "20",
        "33",
        "01",
        "00",
        "6E",
        "00",
        "1E",
        {
          "type": "value"
        },
        "F7"
      ],
      "id": 21,
      "max": 7,
      "min": 0,
      "msg": "sysex",
      "name": "Mode",
      "type": "fader",
      "overlayId": 1
    },

How can I setup the Display Values in an Instrument File?

Thanks,
Joris

2

what do you mean by display values?
you mean fixed values i.e 1=Sine, 2=Saw etc?

if so these are called overlays, you defined an overlay and then it is referenced via the overlay id. this is so that can potentially be referenced by multiple parameters.

the electra one repo contains example instrument files (eif) which include overlays

3

I’m sorry my question was unclear. With ‘Display Values’ I mean these:

(they are just called VALUE in the GUI, I wanted to distinguish them from MIDI Values)

image
image594×642 26.6 KB

4

the idea (as I understand it) is that the instrument is a definition of what a particular instrument receives as data - not how its displayed.
the preset basically binds the instruments ‘protocol’ to a display.

obvious examples, we might use different display types for an instrument parameter (e.g. a slider, knob).
Id assume the ‘display values’ are. a property of those display attributes.

at the moment the support of instrument files is a little limited - we can import them in the editor, but not create them
similarly, Id prefer, we (as users) shared instrument files rather than presets - since I think generally these are more useful… but I cannot see that happening whilst we can only create in a text editor.

so perhaps its still ‘early days’ for the instrument schema?

also perhaps, the preset editor, could allow us one day to copy n’ paste part of one preset to another,
this would be useful if you want to retain display attributes.

1 Like
5

Well, an instrument file does hold the overlay and name of a certain ‘control’, it could as such also hold (what I call) ‘Display Value’. It would serve the concept of a Palette of controls, which only have to be dragged in place, right?

I do get it that the support Instrument Files are still limited. Especially as they can only be created using a text editor, and rather a lot of knowledge of JSON and the like. But I share your idea of a future in which mainly these Instrument Files are shared. It would allow for much more easy creation of Preset Files that would reflect certain custom setups more precise.

Let’s hope it is ‘early days’ (I think it is), for now I’m very much enjoying the Electra One as it is currently. :smiley:

1 Like
6

Here’s the story of the instrument files :slight_smile:

The idea of the instrument and preset files
When we started the Electra project we were primarily focused on the instrument files. The idea was (and still is) that an instrument served two purposes:

  1. Describe the MIDI implementation of a particular device, e.g. a Virus B. It could cover all incoming and outgoing MIDI messages, parsing, and assigment to the parameters.
  2. Provide a palette of controls. That would cover controls for all available parameters, groupped to categories, as well as all the overlays and value lists would be defined.
  3. Provide meta information about the device itself. Type of device, brand, make, labels, tags, etc.

The instrument file, however, would not carry information about such things such as a MIDI port or a MIDI channel. In other words there would not be anything specific to someones studio environment.

(so, both of you @thetechnobear and @joris.roling are right)

The second type of file was a preset. We saw (and still see) preset as a collection of controls of various devices for environment of a specific user. It means that in a preset devices are assigned to their MIDI ports and channels.

A user can build a preset in three ways:

  1. Create the controls ad hoc, e.g. using the MIDI learn
  2. Import an Instrument file and use the predefined controls from the pallete
  3. Combine both above ways

I think the concept is quite powerful. If you think about it, the Instrument file can be used for Electra but it could also serve as a source of information if somebody wanted to generate nice documents with a MIDI implementations of synths, etc.

Why more attention went to the preset files in the past
At the time when the first Electras were sold they mostly went to users who wanted it for a specific hardware synth. It it matched the synths I had in my studio at that time :slight_smile: Chroma, TX7, Virus B, MKS-50, Mopho, Bit99, etc. The instrument files were created and they were available directly in the web editor - the original version. I think only the very old Electra matadors such as @markus.schloesser, @xiizoo, @RobinC and a few others used it.

But as time went there were more and more people who wanted to use Electra for other synths and for VST. We realized that we do not have resources for making all the instrument files. But we also saw that vast majority of users was very preset-oriented. I could see many reasons for that. The most important ones were:

  1. Lots of other tools / devices are preset oriented. Therefore people think in the “preset-mode”
  2. It is easier and more fun to create a preset - you get something working back very soon. Working on an Instrument file has more overhead.

At that point Tomas and I decided to turn things around. We invested our time to improving the Preset editor. The idea was that it will be always possible to generate Instrument files out of presets at later stage.

Fun part was that @thetechnobear made a tool for such a conversion immediately after he got his Electra :slight_smile:

What could be done in (near and far) future
The situation is different now from what it used to be. There are over 80 public presets and there are many users who are interested in the Instrument files. It means there is quite some data that could be converted to the instrument files and new instrument files could be created. I am happy that this thing was brought back and that you guys see the beauty of that.

I removed the example instrument files from the github in the past and the JSON schema was never published. I will revisit what was done and will put it back to github. This might not be overnight. The reason is that the original instrument files were designed for the Preset format version 1. That format supported controls with a single value only (faders and lists). For those, it was kind of obvious to connect MIDI messages with a particular type of control that would be available in the palette. The current preset format (version 2) brings multi-value controls. With these it becomes more subjective and opinioned how the default controls on the palette should look like. e.g. one user may prefer ADSR as one control while someone else would like to have four faders. This might still need some thinking. I am very very open to a discussion about this. But as you know my time is not unlimited :slight_smile: If we were able to make some joint effort, it would be great.

7 Likes
7

I come from a heavy programming background (day job is writing software, I also created some Lemur templates and customized the Arduino code in my Linnstrument when I had it).

I am trying to do something that should not be too difficult – create an interface (generic term) to my Yamaha D5000 delay units. To do that, I need to first program the Patch button to send a ‘get current patch request’. Hmmm, I couldn’t find any direct examples of that. I needed to guess based on existing templates how to define it for the patch button.

Next is to parse the incoming sysex message. OK, I now I have to get into a text editor and type in JSON. Typing in quotes and parentheses and brackets makes me miss the days of programming in assembly language. :slight_smile:

Are there any good editors that would make this task less painful?

After that, I then need to map the controls to the parameters. All of this takes time. I understand that it’s not magic and it’s not plug-and-play. I guess what I am missing is the tools to make it faster and less error-prone.

8

Please make this a sticky or put it in documentation or something :slight_smile:. Very useful review of current state! I am just dipping my toes into this, as I got my E1 just couple of days back.

I see the immediate allure of presets as I was able to throw together a few sysex param changes and easily edit current patch in Korg Triton. But, I also realize that instrument file is what I want to make for it, since that’s the best way others can do what they want with it.

I am willing and able to contribute in any way that is helpful - be it writing some translation scripts, or helping with an editor, or whatever is good for the community.

Perhaps a youtube live session, or even a zoom/google meet session where we jump in and talk as a group? :slight_smile:

2 Likes
9

Just wanted to add that @thetechnobear’s script to convert epr to eif worked great for my simple preset. So, that should alleviate the effort in creating instrument files.

2 Likes
10

I can definitely see why users just prefer to create presets directly

even if we have ‘instrument editor’ support, we’d not want to force users to have to create an instrument definition, before they add a field in the preset editor - it 'd be a two step process rather than the simple one it is today.

I do wish in the preset schema included a instrument defintion, so they were always consistent. ( i.e a preset parameter references an instrument defintion)
this would make translation between the two much simpler.

then the preset editor, would insert these when importing - or create a ‘temporary/fake’ instrument for parameters that were being added directly (not from an instrument)

however, I recognise that the preset data would only include the instrument definitions that it used (so its only partially complete) , since we do not want to send more data than is required.

of course things like macro parameters would also not exist in instrument defs.

2 Likes
11

The JSON schema for the instrument file is now available at:

The example/test instrument is in the tests folder within the schemas

Consider this to be the initial kickoff. ADR, DX7envelope types still needs to be added. Fork and pull request me as you wish :slight_smile:

I will try to generate the documentation tonight but the descriptions and examples in the schema should provide sufficient info for the developers.

3 Likes
12

Thank you so much @martin, very nice!
I left you some github issues, please have a look.

Question: Is this schema already currently supported in the Web Editor? Or does that need to be done?

13

yup, it is supported. Will review stuff on the github

14

Twenty characters of awesome!

15

Great @martin

Could you explain me defaultValue with respect to to midiValue and displayValue ?

16

sorry @joris.roling wanted to respond on gh but was busy with another talk.

The value object is described at:

https://docs.electra.one/developers/presetformat.html#value-2

the defaultValue is default for the display value. Therfore it exists within the value.min and value.max. If the value.min/max are left empty they default to the message.min/max.

eg.

value.min = -64
value.max = -63
value.defaultValue = 0

message.min = 0
message.max = 127

the defaultValue = 0 represents a midi value 64. I hope this helps.

17

Great stuff @martin, very clear!

18

Is this still the current thinking on instruments vs presets? I’ve had an electra for a bit over a year and I have to say the setup and programming of it has held me back a bit given the workflow. I really like the idea of having an instrument or multiple instruments as a library of controls to be placed into a preset. I’d like to know if this is still the intent and what sort of priority this might have. I’ve been tempted to create some sort of templating setup to generate presets from multiple instrument definitions.

If there is any way to contribute, I have some time on my hands and this would be interesting to learn.

2 Likes
19

Go ahead, we’re all hear to learn from each other, and eventually make better music, better sounds, better presets or just have a good time.

20

My original idea was that the Electra project would be mostly about having many instrument files and users building presets out of them. Each preset being tailored to users’ setups. That idea was liked by a few but mostly not understood by the majority of users. I totally understood that, making a preset is much more straight-forward process and also it gives immediate value step by step when working on it. Creating presets (templates) is also something common that users know from other MIDI controllers.

Now, with close to 250 presets in our database. I am making changes to the preset editor that should bring the Instrument idea back. Just done the other way around. It means, there would be an option to generate an instrument file out of existing preset. I have added control “categories” and “preset values” to the editor recently. These are the foundation for generating the instrument definition. The only obstacle on the way to this goal is the Lua functions now. All device specific Lua functions must be kept in “device specific context”. If this is not done carefully, having a preset with multiple instruments (with Lua) may result in collisions of the Lua functions.

1 Like