Two MIDI bytes (lsb, msb) are required for each 14 bit data word. Bits 0-
6 are sent first, followed by bits 7-13 in the next MIDI byte. All data
words are signed 2’s complement values with sign-extension out to the
most significant bit (bit 13). This convention applies to all data words,
regardless of the parameter’s value range.
So far, so good.
I have two adjacent parameters - Loop Start Coarse and Loop Start Fine.
Loop Start Coarse is +/- 999,000 samples, while Loop Start Fine is +/- 999 samples.
Offsetting the ‘fine’ value from the ‘coarse’ one is handled internally to the Morpheus, so all I need to worry about is configuring two faders to send values in the range of -999 to +999.
The issue - the exact same setting works OK for Loop Start Coarse, but for Loop Start Fine, it only works for positive values - if I move the ‘fine’ fader into the negative, the values jump around and start to effect the ‘coarse’ value unpredictably.
I suspect I need to do something clever to the sysex byte in the fader’s sysex settings, but I’ve been experimenting blindly with no luck.
Everything defaults to the unsigned numbers as they are most commonly used. The option to select the way of expressing the negative values (2’s compl and sign bit) will appear when you define a control that has negative numbers in its value range. eg:
The Sign Mode is the way of expressing the negative value
The Bit Width tells E1 how many bits are used. That means, where the sign bits will be placed.
If you set things as they are shown on the screenshot, the MIDI value of given parameter will be internally stored as 2’s complement number.
The next step is to arrange how it will be transferred in the SysEx message. You can do that by using the “Edit SysEx Data”
I use a bogus “18h” constant byte as the first bytes to send. It is a E-mu manufacturer byte. This should be replaced with appropriate bytes for Morpheus.
Then there are two value bytes. They are used to include the LSB and MSB portion of the parameter value.
Thanks for this Martin. This is precisely how I have both my faders configured, same for Coarse and Fine. Coarse worked as expected, but Fine has a problem like I said.
However I am beginning to suspect the problem is a bit more complex.
I’ve fired up Soundiver on an old laptop, and looked at the sysex output from the GUI faders for the same Morpheus parameters.
Based on this it appears that Morpheus needs to receive the sysex strings for Coarse and Fine together - if you adjust the Fine parameter, then a Coarse parameter message restating the current value needs to be sent immediately afterwards, and vice-versa.
If this is not done, I think Morpheus assumes a zero offset value for the missing parameter, however this logic also extends to assuming the sign bit = zero, which is a problem if the current parameter value is actually negative (hence a sign bit = one).
This is my theory based on the Coarse and Fine messages appearing together. It might explain the weird snafu, and I can at least confirm both parameters send 14-bit signed values with the sign as the most significant bit.
Now I need to figure out how to get one control to send its own and one other parameter value - something to do with linked parameters I think??
Having experimented further, I’ve found that the two parameters - Coarse and Fine - react happily to sysex parameter changes when both have values that are in the negative or positive range of travel.
However, if Morpheus receives a parameter value for Coarse whose sign bit is positive, while the Fine value is negative (or vice versa), then weird things start to happen.
I am increasingly certain the Soundiver implementation of these controls (sending the two parameter values together on change of either) was a workaround for a bug in the Morpheus’ internal sysex parsing code.
In other words, I think I’ve found a bug in a 30 year old bit of firmware!
Have you managed, via lua, to always send both sysex messages?
The solution can be to make 2 virtual controls, linked to a user function.
The user function, which is the sale for both controls, should then retrieve the values of those two parameters and send them in the desired order as sysex
No I have not experimented with LUA yet. For the meantime I have implemented both Coarse and Fine controls with the buggy Morpheus behaviour as a given.
Right now I am trying to figure out the best way to implement the Function Generator controls, as these parameters do not break down conveniently in a way to make best use of the 6 x 6 control grid.
Also, Morpheus uses AHDSR for the Volume envelopes, and DAHDSR for the Mod (Aux) envelope - does anyone here have an insight into if/when these might be implemented as control archetypes within the Electra app?
BTW - my intention is to ‘go live’ with Morpheus and UltraProteus public presets, as I have both synths for testing and they are basically identical except for having different Instrument and Z-Plane list objects.
BTW - my intention is to ‘go live’ with Morpheus and UltraProteus public presets, as I have both synths for testing and they are basically identical except for having different Instrument and Z-Plane list objects.
I have also just acquired a Morpheus and would be happy to help test. Is this preset still be being developed?
I’ve made the Morpheus preset public - search under ‘E-mu’. Note it is still a work in progress, as I haven’t had time to develop it further or learn LUA scripting
