Patch data over MIDI

Discuss John Bowen Synths - Solaris
amongstmyselves
Posts: 43
Joined: Sun May 11, 2014 8:15 pm
Contact:

Patch data over MIDI

Post by amongstmyselves »

Hi,

I was wondering if there is a system exclusive way of getting all the patch data for a single patch sent down the MIDI output ? Initiated from an attached computer or from the Solaris ?

Cheers,

Steve
John Bowen
Site Admin
Posts: 2002
Joined: Sat Apr 07, 2007 3:00 am
Contact:

Re: Patch data over MIDI

Post by John Bowen »

Unfortunately, all we have for preset data over SysEx is a single parameter retrieve.
Here is what I have documented so far for SysEx:
Attachments
Solaris-SysEx.pdf.zip
(100.86 KiB) Downloaded 378 times
John Bowen
Site Admin
Posts: 2002
Joined: Sat Apr 07, 2007 3:00 am
Contact:

Re: Patch data over MIDI

Post by John Bowen »

I think Julian didn’t put much work into transferring complete preset data of MIDI because all of the presets are on the CF card, and it was a simple way to manage backup and storage with a CF reader and a computer.
amongstmyselves
Posts: 43
Joined: Sun May 11, 2014 8:15 pm
Contact:

Re: Patch data over MIDI

Post by amongstmyselves »

Thanks John. Fully understand that storage on the CF card is the best way. Reason for wanting to know was a possible piece of software to show the routing on a computer monitor. Send the patch down the line and see the layout on a large screen. Just an idea but with the single parameter request it would still work although a little slower.
John Bowen
Site Admin
Posts: 2002
Joined: Sat Apr 07, 2007 3:00 am
Contact:

Re: Patch data over MIDI

Post by John Bowen »

Well, I am very upset that there is not a data dump for an entire preset - ridiculous in this day and age of MIDI! I know there are a lot of parameters (over 1250!) per preset, so doing one at a time is just silly.
This is something that we need to change.
jgale
Posts: 78
Joined: Sat Sep 27, 2014 1:38 pm
Location: New York
Contact:

Re: Patch data over MIDI

Post by jgale »

John Bowen wrote:Well, I am very upset that there is not a data dump for an entire preset - ridiculous in this day and age of MIDI! I know there are a lot of parameters (over 1250!) per preset, so doing one at a time is just silly.
This is something that we need to change.
This would be nice and helpful in creating an integrated editor for a DAW!

Just having the individual controller information will be helpful. This was something that I was not aware of and will be useful in a project / Solaris VST tool that I am creating.

John
amongstmyselves
Posts: 43
Joined: Sun May 11, 2014 8:15 pm
Contact:

Re: Patch data over MIDI

Post by amongstmyselves »

I've been playing around a little with the single parameter sysex and getting strange results.

So I've managed to retrieve parameter data. No problem here. Then I use the sysex code to set a parameter with an incorrect result. In my test I retrieved the value for Oscillator 1 Mode. Some of the returned values are 00 for OFF, 05 for MM1, 08 for WT etc. So I attempt to send a parameter change and no matter which of the previously retrieved codes I send it always goes to OFF ?

Any others had experience with trying this ?

Steve
John Bowen
Site Admin
Posts: 2002
Joined: Sat Apr 07, 2007 3:00 am
Contact:

Re: Patch data over MIDI

Post by John Bowen »

amongstmyselves wrote:I've been playing around a little with the single parameter sysex and getting strange results.

So I've managed to retrieve parameter data. No problem here. Then I use the sysex code to set a parameter with an incorrect result. In my test I retrieved the value for Oscillator 1 Mode. Some of the returned values are 00 for OFF, 05 for MM1, 08 for WT etc. So I attempt to send a parameter change and no matter which of the previously retrieved codes I send it always goes to OFF ?

Any others had experience with trying this ?

Steve
Steve,
I recently started going through every parameter range, connecting 2 Solaris (Solari?), and have found a number of parameters (such as the Oscillator Type) that respond as you have described. My first thought was that Julian did not finish the NRPN code to set the list lengths in the Solaris, so that when it receives the command for Oscillator Type, it knows the proper parameter to adjust on the slaved unit, but doesn’t have a range with which to work. I have sent some of this information off to Holger, to ask him to see what the situation really is. So far, he hasn’t had time to check it.

But the main problem is, we can’t even use NRPN correctly to control the Solaris! I had not had the chance to really check 2 units together for NRPN communication, and I’m very frustrated to see that there are several parameters so far that act like this - all incoming values just force a default to the lowest (zero) value (which is the Off position in the case of the Oscillator Types).
minorguy
Posts: 120
Joined: Fri Dec 05, 2014 12:09 pm
Location: San Jose, CA, USA
Contact:

Re: Patch data over MIDI

Post by minorguy »

I’ve spent some time with the NRPN and SysEx the past six months or so. There are lots of issues there. I just didn’t think there was a need to list them because I figured Holger would find them anyway. But since it came up, I can add some info.

The NRPN values that the Solaris sends out don’t correspond to the values you see in the UI or would expect to get. Instead, the range of the parameter is spread out over the total 14-bit range available. So for example, OSC fine tune has a range of 200 (-100 to +100). That divides the full range of 14-bit NRPN which is 16384. This means that for fine tune each step is roughly 82, with zero being at 8192. Since different parameters have different ranges, the step size will be different for each parameter. If you were to receive 9591 the fine tune would then be +18. Although this is not ideally how you’d like to see the values, it might be livable if you knew exactly the calculations done internally. But I think due to round-off error when dividing, it’s not always easy get from the NRPN value to the same value Solaris is displaying.

For the arp editor I was able to do it because there were only a handful of parameters and I spent some time adjusting to get them right. But I didn’t want to do that for 1000+ parameters in my other programs. So instead I don’t interpret the NRPN values. Instead I use SysEx because the SysEx values are easier to interpret and are not the same as NRPN. So whenever I receive an NRPN value, I ignore that value and then send a SysEx request for the same parameter and use the value I get from SysEx. (Actually I wait about 300ms for NRPN activity to settle down before requesting the SysEx value.) So I haven’t spent as much time with NRPN since SysEx values seem more reliable to me.

With SysEx there seem to be two types of parameters. I call them numerical and enumerations (or lists). Numerical values are just the values you would expect. For example if the OSC fine tune is set to +18 then you will receive value 18. Keep in mind these values are signed. (Using a 16-bit int I shift the value left by 2 to pick up the sign and then shift back 2 right.) Enumeration values are for parameters that are lists of things, such as OSC type, wave type, modulation destinations, etc. These SysEx values need to be divided by 4 to get the true value. I don’t know why these are different but I assume it has to do with the internal implementation. As you've discovered, the value you get is not necessarily the true value multiplied by 4. For OSC MM1 you might get 4 or 5 or 6. But in any case, you divide that by 4 and you get 1 which is the index for MM1.

How do you know which parameters are numerical and which are enumerations? Trial and error, although it’s mostly what you’d expect. But behavior is not always consistent. For example you will find that EnablePart buttons are odd. To turn one ON you need to send 0. To turn one OFF you don’t send 1 or 4. You send at least 8192. I just use 16383.

The modulation amount for oscillators can be a bit tricky. You’ve noticed that for oscillators (as well as filters) there are actually two different amount values. There is one for pitch and another one for all other destinations. These are remembered so that when you switch the modulation destination between, say, pitch and shape, the different values are not lost. And, there are separate NRPN indexes for each and both are saved to a preset file. For example OSC 1 mod amount 1 uses index 1107 for pitch and index 269 for all other destinations. But notice that on the Solaris when you select Shape as the destination the amount is shown as a percent in steps of 1. But when you select LinFM as the destination the amount is shown in steps of 0.1. This means the value that the Solaris sends for SysEx index 269 has a different range depending on whether the destination is currently set to Shape or LinFM…either 200 or 2000 respectively. (No, the Solaris will not use a range of 2000 for both cases.) So you need to interpret the value you get in the context of the current destination setting. Further, you might have noticed that when you switch the destination from LinFM to Shape, the value in the Solaris gets rounded to integer so that when you switch back to LinFM you lose the decimal. An editor has to be aware of this to stay in sync with the Solaris.

Parameters that have a range of 0 to 20 seconds cannot be read correctly. Note that the increment for these time values is 0.1 ms. Given the range of 0 to 20 seconds that is 200000 steps. But the allowable range of NRPN is only 16384. So NRPN cannot currently convey these values. Currently it seems the values just keep wrapping around as they go up. In other words if you receive a value of 300, that might mean 30ms or 1.67s or 3.31s, etc. This is the same situation for some frequency values such as in the EQ. SysEx would be able to send larger values but currently does not.

Many parameters are not supported, or at least the NRPN indexes are not documented. Examples: transpose, FX channel info, outputs 3 thru 8 and S/PDIF, play mode, univoice, unitune, BPM, note priority, preset name, and more.

There’s more but I don’t want to dump too much. The Solaris sounds and plays great regardless! :D

Jim
Last edited by minorguy on Wed Dec 09, 2015 3:21 pm, edited 1 time in total.
Solaris #249
John Bowen
Site Admin
Posts: 2002
Joined: Sat Apr 07, 2007 3:00 am
Contact:

Re: Patch data over MIDI

Post by John Bowen »

Jim,
Thanks for the additional info! I will communicate this to Holger.
minorguy
Posts: 120
Joined: Fri Dec 05, 2014 12:09 pm
Location: San Jose, CA, USA
Contact:

Re: Patch data over MIDI

Post by minorguy »

Just a few extra notes I had related to the NRPN list:

Master0PitchWheelRange1 – 5: Pitch range UP.
None0 – 8: Mod Wheel on/off
None0 – 9: Mod Wheel max
LFO1Frequency0 – 138: This is called “Rate” on the Solaris UI.
Osc1ModCMix1 – 268: Control Strength. Same for all other instances of “CMix”
Osc1ModControl1 – 280: These are the mod control sources.
Osc1Mode0 – 289: This is called Oscillator “Type” on the Solaris UI.
Osc1WaveSel01 – 290: MM1 wave
Osc1Tune0 – 296: Oscillator Fine tune. (Coarse tune is 886)
Fil1Mode0 – 584: Actually Filter “Type” in the Solaris UI.
Fil1Sel0 – 585: This is filter Mode.
Pan1OutSw0 – 731: Enable Part 1 switch
Pan2OutSw0 – 735: Enable Part 2 switch
Pan3OutSw0 – 739: Enable Part 3 switch
Pan4OutSw0 – 743: Enable Part 4 switch
Seq0Track – 864 thru 867: No idea what these are.
Assign0Button1 – 876: Assign button 1. (I don’t know what the other assign indexes 873, 874, and 875 are. Looks like nothing.)
Assign0Button2 – 877: Assign button 2
Master0PitchWheelRange2 – 890: Pitch range DOWN.
Ribbon4InSource0 – 895: Touch offset.
None0 – 928: Oscillator 1 “Low” switch.
None0 – 929: Oscillator 2 “Low” switch.
None0 – 930: Oscillator 3 “Low” switch.
None0 – 931: Oscillator 4 “Low” switch.
None0 – 932: Rotor 1 “Low” switch.
None0 – 933: Rotor 2 “Low” switch.
EGReset – 1035: Undocumented.
Master0Playmode0 – 1036: Actually this is the Legato parameter.

Osc1WaveSel1 – 1146: WT Wave
Osc1WaveSel1 – 1147: CEM Wave
Osc1WaveSel1 – 1148: WAV Wave
Osc1WaveSel1 – 1149: VS Wave
Osc1WaveSel5 – 1150: Mini Wave
***The other OscXWaveSel parameters follow the same pattern. Note that the numbers in the name after the “Sel” are not correct.***

None0 – 1167: Filter1 Obie Mode
Fil1Sel5 – 1168: Filter1 Comb Mode
None0 – 1170: Filter2 Obie Mode
Fil2Sel5 – 1171: Filter2 Comb Mode
None0 – 1173: Filter3 Obie Mode
Fil3Sel5 – 1174: Filter3 Comb Mode
None0 – 1176: Filter4 Obie Mode
Fil4Sel5 – 1177: Filter4 Comb Mode

Analog0Out34 – 2002: Analog 3/4 output. Undocumented. Always returns zero.
Analog0Out56 – 2003: Analog 5/6 output. Undocumented. Always returns zero.
Analog0Out78 – 2004: Analog 7/8 output. Undocumented. Always returns zero.
SPDIFOut – 2005: S/PDIF output. Undocumented. Always returns zero.


A semi-interesting little bit:
Note that some NRPN names start with “Pan”. I think this is a little window into how the Solaris works. I expect that the VCA and Pan are really two separate modules that are combined in the UI just to make the UI simpler. But the Pan module really comes after the corresponding VCA and includes the pan position and enable-part switch. Ever wonder how you can feed the output of the VCA back into a mixer when the output would seem to be stereo? Because the output of the VCA is really mono. That feeds into the mono input of the Pan module which then outputs stereo to the hidden master VCA.
Solaris #249
Post Reply

Who is online

Users browsing this forum: No registered users and 28 guests