Where is the SYSEX documentation?

Well, the new Kyra VST Editor from Sigabort is the integration that should have been done from the start.
I just hope there will be a new Firmware update to address some of the bugs.

www.sigabort.co/midisynth
 

Hi, I am the author of Edisyn: I'm basically a team of 1, plus a few contributors. The Kyra sysex documentation situation is simple: Waldorf hadn't written it down yet. There's a lot of reasons for this that aren't worth discussing here. Anyway after a lot of pestering I engaged in a some back-and-forth with both Waldorf and with the original Kyra developer, and built the editor in real time in discussion. At this point if you ask nicely they'll give you the available single-mode sysex docs; various parameter values can be found in Edisyn's source. For the multimode sysex, at the end of Edisyn's Kyra Multi editor source code I have put down some documentation sufficient to get you up and running. If you have any issues or questions, just drop me a line.

I've seen Edisyn and appreciate the work you've done getting the SYSEX info. I've already used some of it to extend my own patch evolver software. Mine is based on "PFarm" from decades ago which set up a 32-cell pool. (4 rows of 8 cells) In my software, you click an empty cell to load the current synth patch. Switch patches on the synth and click other cells to load additional patches. Then click "Evolve". Non-empty cells are randomly picked for cross-breeding. Random crossover points are picked along the SYSEX genome and the new patch is created as a cross between the previous two and put into an empty cell. Repeat until the pool is filled with parents and offspring, then evaluation starts. Keep the good ones, right-click to discard the bad ones (opening empty cells), and click evolve again. Clicking a full cell sends that cell's patch to the synth to listen. Very clean and simple.

(I'm not the original author of Pfarm. I just copied and enhanced his patch evolving interface ideas.)

I tried using your Edisyn morphing and genetic algorithm options but found that they were not intuitive so it was difficult to use your process to evolve new patches. I will have to give it another go at some point since you have so many options. It's great you are into this sort of thing as I have been for a long time. I've implemented my patch evolver successfully on 8 of my synths. There isn't much to it.

I also discovered that you have an off-by-one error on Edisyn's page of mod-matrix parameters. They don't display the text that the synth is displaying. (They're off by one.)

There is a bug with the Kyra that messes up CC74, which is commonly used for MPE. When the same patch is stored in every multi-part, as it is when using your very helpful Pseudo-MPE button, Kyra mistakenly modulates ALL parts when CC74 MIDI is sent on a SPECIFIC channel. My solution was to write a script that will take a bank of patches and modify every one by adding a modulation matrix CC19 -> filter 1 frequency entry, and also changing the pitch bend range to maximum (1 octave) while it's in there. Then I changed my Linnstrument to send CC19 rather than CC74. It works, though it uses up a mod matrix slot. It is not sounding like there is any will to fix this issue. The workaround is far from ideal and is inaccessible to anyone but programmers. It's a shame. They were SO close to making a really good MPE synth.

Feel free to incorporate any of these ideas into Edisyn. None of them are particularly difficult. I believe I have my number of randomized crossover points set to 25.

getbytesfrom1stpatch = true
for(byteindex = start to end of relevant patch bytes)
   if byteindex == one of the 25 crossover points
       getbytesfrom1stpatch == not(getbytesfrom1stpatch)
   if getbytesfrom1stpatch == true
      newpatch[byteindex] = 1stpatch[byteindex]
   else
      newpatch[byteindex] = 2ndpatch[byteindex]
   

I'm a computer science professor and my dissertation long ago was in evolutionary computation: so I obviously have a lot of interest in evolving patches. Suffice it to say that Edisyn's hillclimber uses a different evolution method (close to what's commonly known as a mu,lambda evolution strategy) but it's tuned to move rapidly through the patch space while (hopefully?) reducing the number of junk patches presented to the user. There's a special version you might be interested in, for the DX7 only, which uses a deep-learned variational autoencoder to try to compress the space to reduce the junk patches even more. The closest method in the hill-climber to what PFarm is doing is Edisyn's constrictor -- you might look into that. But I sense that it's not the evolution but other factors which you are finding counterintuitive.

The morpher is totally different from all of this -- it's just morphing in real time. I posted a video to the kyra facebook group a while back showing it in action on the Kyra, you might look that up.

Could you be more specific about the one-off error? I don't have a Kyra, I have to borrow it from a friend to check things. Is it an error in the sources? The destinations? The matrix slots? Etc.

BTW, have you reported the CC74 bug to Waldorf?

Right, the evolution aspect I get, or maybe shouldn't need to get. I'm talking about UI.

For example, there are four cells to hold patches to morph. How do I get patches into each of those cells so start the process? I don't recall if I managed it or only managed two, but the process was not intuitive.

On my evolver, every empty cell initially contains a button that says "ClickToGetPatch" and pulls the current patch into that cell. It spells it out about as blatantly as possible. Once a patch is in a cell its name is displayed and clicking the cell sends it back to the synth for audition. "Click cell to send, right-click to delete" is the text I put somewhere around the frame if I remember right. I also include a counter that shows how many iterations a particular cell has survived. 

Sorry, I don't mean to be a downer on Edisyn. It is a useful piece of work that you've worked hard on and it has been helpful. Your choice of synths was great, I have many of those synths. And if you hadn't written Edisyn with the PseudoMPE and sysex, I would not have bought a Kyra.

As far as the off-by-one error ... checking ...

Just now I loaded a patch and pulled it in to Edisyn. I display slot 6 of the patch's mod matrix on Kyra's display. I select Channel Pressure in Edisyn as the first mod source for slot 6. The Kyra now displays the Pitch bend as the first source for slot 6, which is one off from Channel Pressure. So I am guessing one array is zero-based and one is one-based.

I just checked, destinations are also off by one in the same direction. I selected Osc 1 detune and Kyra is now set to Course tune, so the Kyra is one less.

Amounts of the modulations are correct.

Oh I forgot, my patch evolver also does the pitch bend max range tweak and the CC74->CC19 tweak on the fly as well. I think I'll need to implement your PseudoMPE button for auditioning.