I want to be able to send a sysex dump to my Strymon BigSky from my own program or request it from Electra. But from what I have seen, parameters are located in different places depending on which type is selected. For example, the Boost parameter can be located at offset 28, 29, 30, 31 and 32 in the sysex dump depending on which type (offset 9) is selected. That makes it difficult to receive a sysex dump and set all controls to the right values. My question is, do I have to solve it with LUA code or are there other ways? Can someone please give me some guidelines on how to solve it in the best way?
This is also the case with the Ensoniq DP/4 and I am handling it all with Lua code. I have found the easiest and (probably) most efficient way is to use tables to store the offsets and refer to them when necessary.
For example:
-- store the dump in a table
dumpVals = { 0x07, 0x00, 0x01, 0x10... }
-- create a table of offsets based on type
offsets = {
typeA = { 1, 2, 3 },
typeB = { 4, 5, 6 },
typeC = { 7, 8, 9 }
{
-- get table of offsets for type A
local a = offsets.typeA
-- set desired offset's position within the table
local b = 1
-- get desired offset from table
local c = a[b]
-- get value at desired offset in dump
local value = dumpVals[c]
-- a more concise version:
local value = dumpVals[offsets.typeA[1]]
With some good pre-planning of your tables you can use one function for all types rather than needing one for each type.
1 Like
I made a small variation of what you suggested and it works perfectly. Now I just need offsets in the sysex dump to all parameters for BigSky. I have asked Strymon but haven’t received an answer yet. If I don’t get that information, it will be reverse engineering. This is my question to Strymon.
““I am integrating my Electra One MIDI controller with the BigSky pedal and am seeking guidance on the SysEx parameter offsets to enable accurate mapping. Through my reverse engineering, I have observed that certain parameters (e.g., Boost) appear at different offsets depending on the selected type, though I have confirmed the type parameter is at offset 9. While it is technically possible to determine all offsets manually, this process is extremely time-consuming.
Any official or reference mapping of parameter offsets for each type would be immensely valuable and allow me to implement a fully accurate integration quickly and reliably. Given my experience with both hardware and SysEx, I can work directly with the information you provide without further effort on your part. Your assistance would not only save significant time but also ensure the integration works flawlessly, benefiting both users and the broader community.
Thank you very much for your time and support, and I greatly appreciate any guidance you can provide.””
For those who have a BigSky or TimeLine, here are the sysex requests I know of.
"Note that these examples assume presets are numbers starting from 0.
This will get the preset at location XX YY. Where XX is the upper 7 bits
of preset number and YY is the lower 7 bits. Where Z is the Product ID
(Note PID TIMELINE 01, MOBIUS=02, BIGSKY=03) “F0 00 01 55 12 ZZ 63 XX YY F7”
Preset is 14 bit number but is valid 0-199(for TimeLine) or 0-299(for BigSky).
TimeLine har 200 presets
BigSky har 300 presets
Timeline examples:
Ex. “F0 00 01 55 12 01 63 01 00 F7”
Requests location 128
Ex. “F0 00 01 55 12 01 63 01 47 F7”
Requests location 199
Ex. “F0 00 01 55 12 01 63 01 48 F7”
Requests edit buffer (last preset + 1)
BigSky examples:
Ex. “F0 00 01 55 12 03 63 01 00 F7”
Requests location 128
Ex. “F0 00 01 55 12 03 63 01 47 F7”
Requests location 199
BigSky examples
Ex. “F0 00 01 55 12 03 63 02 2C F7”
Requests edit buffer (last preset + 1)
1 Like
Glad it helped! I am curious what variation you made. 
With DP/4, there are 40 or 50 algorithms with up to 34 parameters each. 11 of the parameters are common to all algorithms yet they are at different offsets, to top it off! Then each parameter takes a value in one of 8 data types, some of which are two byte words, some are signed, some two’s complement and all have differing midi ranges, as well as differing display ranges! Needless to say, I have developed a set of tables (of matching complexity!) with all of the parameters and their “attributes” that enable me to address any and all algorithms using a single concise function. There are 4 separate fx units in the DP/4 so I have dedicated an E1 page to each unit. On each page there is a list control for selecting the unit’s algorithm. The attributes of each parameter’s associated controls, as well as various flags needed for tying everything together are also stored in my tables, which makes it so the four pages are automatically reconfigured and arranged appropriately when a new preset is loaded (or single page when a new algorithm is selected). Through this endeavor, I have really developed a much more intimate understanding of this notoriously arcane and confusing device!
Suffice it to say, Electra One is an incredibly awesome device, one for which I have waited a long time. 
I am still working on polishing my DP/4 preset and will make it public soon.
3 Likes
FWIW, I did something similar to handle the 40+ different algorithms in the PCM 80/81. Some parameters appear in most, some in only a few, and often all are at different offsets in each algorithm.
The E1 will not support creating separate unique pages for each algorithm, so a more efficient way needed to be done.
The main trick is trying to be efficient and get as much info out of the table lookup as you can
2 Likes
This is my solution, it might not be that much different from your idea when I think about it. The byteMap table is not ready yet.
Is there any way I can help testing?
I have a DP/4.
Made some presets before for the Ensoniq Mirage Masos and Soundprocess OS.
Anyhow really great to see you are working on the DP/4
Cheers
Tim