Sending sysex on modulator change.

[puffer3]

Hi all,

I am working on a panel for a Jupiter 8 with Encore MIDI. It doesn't have sysex or CC parameter updates, but apparently the workaround it to send a full patch every time a parameter change is performed. I am trying to figure out how to do this even tho I am not really a programmer, by looking at other examples.

My goal first, is to make an string of all the modulators I am going to send (28 bytes according to the Jupiter 8 Encore manual). There is some odd formatting of the last 4 bytes that I dont understand yet, but I am starting out just grabbing all the modulators (39).

Then I have to convert it to Hex and send it with proper sysex formatting. Then tie the method to the panel to be run every time a modulator value is changed.

I have never scripted in LUA. So far I was able to send a static sysex string everytime a modulator is changed, but assembling and formatting the data for the full patch is a bit beyond me ATM.

This doesnt work yet. I was using this forum post for reference. Just trying to collect the data first. still have to add the F0, F7 headers and footers and ID and everything. Apologies if this is too noob. If there's somewhere more basic I should start with LUA, please let me know. I have been reading some, but also just mucking around trying to get things to work.

function set_SYS_Values()

 byte = {}
 byte[1] = panel:getModulatorByName("PROTECT"):getModulatorValue()
 byte[2] = panel:getModulatorByName("O2RANGE"):getModulatorValue()
 byte[3] = panel:getModulatorByName("VCOLFOMOD"):getModulatorValue()
 byte[4] = panel:getModulatorByName("VCOENVMOD"):getModulatorValue()
 byte[5] = panel:getModulatorByName("PWM"):getModulatorValue()
 byte[6] = panel:getModulatorByName("XMOD"):getModulatorValue()
 byte[7] = panel:getModulatorByName("O2FINE"):getModulatorValue()
 byte[8] = panel:getModulatorByName("SOURCE"):getModulatorValue()
 byte[9] = panel:getModulatorByName("CUTOFF"):getModulatorValue()
 byte[10] = panel:getModulatorByName("RESONANCE"):getModulatorValue()
 byte[11] = panel:getModulatorByName("VCFENVMOD"):getModulatorValue()
 byte[12] = panel:getModulatorByName("E1_SUS"):getModulatorValue()
 byte[13] = panel:getModulatorByName("E2_SUS"):getModulatorValue()
 byte[14] = panel:getModulatorByName("LFORATE"):getModulatorValue()
 byte[15] = panel:getModulatorByName("LFODLY"):getModulatorValue()
 byte[16] = panel:getModulatorByName("HPFCUTOFF"):getModulatorValue()
 byte[17] = panel:getModulatorByName("VCF_LFO_MOD"):getModulatorValue()
 byte[18] = panel:getModulatorByName("VCF_KEYTRK"):getModulatorValue()
 byte[19] = panel:getModulatorByName("VCA_LEVEL"):getModulatorValue()
 byte[20] = panel:getModulatorByName("E1_ATTACK"):getModulatorValue()
 byte[21] = panel:getModulatorByName("E1_DECAY"):getModulatorValue()
 byte[22] = panel:getModulatorByName("E1_RELEASE"):getModulatorValue()
 byte[23] = panel:getModulatorByName("E2_ATTACK"):getModulatorValue()
 byte[24] = panel:getModulatorByName("E2_DECAY"):getModulatorValue()
 byte[25] = panel:getModulatorByName("E2_RELEASE"):getModulatorValue()
 byte[26] = panel:getModulatorByName("LFO_WAVE"):getModulatorValue()
 byte[27] = panel:getModulatorByName("O1_MOD_SW"):getModulatorValue()
 byte[28] = panel:getModulatorByName("PWM_SWITCH"):getModulatorValue()
 byte[29] = panel:getModulatorByName("O1RANGE"):getModulatorValue()
 byte[30] = panel:getModulatorByName("O1_WAVEFORM"):getModulatorValue()
 byte[31] = panel:getModulatorByName("O2_WAVEFORM"):getModulatorValue()
 byte[32] = panel:getModulatorByName("VCA_LFO_SW"):getModulatorValue()
 byte[33] = panel:getModulatorByName("O2_SYNC"):getModulatorValue()
 byte[34] = panel:getModulatorByName("O2_RANGE_SW"):getModulatorValue()
 byte[35] = panel:getModulatorByName("VCF_SLOPE"):getModulatorValue()
 byte[36] = panel:getModulatorByName("VCF_ENV_SEL"):getModulatorValue()
 byte[37] = panel:getModulatorByName("E1_KEYTRACK"):getModulatorValue()
 byte[38] = panel:getModulatorByName("E1_POLARITY"):getModulatorValue()
 byte[39] = panel:getModulatorByName("E2_KEYTRACK"):getModulatorValue()
    


    syx = MemoryBlock (byte)

      fullmsg = MemoryBlock(string.format("%s %s", syx:toHexString(2)))


       m = CtrlrMidiMessage(fullmsg:toHexString(2))
           panel:sendMidiMessageNow(m)


end

still have to make the switches, but here is the interface portion so far.

[dnaldoog]

Hi @puffer3

Can you post the panel and resources as you have it so far? It’s probably easier for me to change the lua that way and then you can look at the source code. You can always delete the attachment later once I download it.

[dnaldoog]

Probably something like this for a start, but there is a more efficient way of doing this:

function set_SYS_Values()
    local mySet = {
        "PROTECT",
        "O2RANGE",
        "VCOLFOMOD",
        "VCOENVMOD",
        "PWM",
        "XMOD",
        "O2FINE",
        "SOURCE",
        "CUTOFF",
        "RESONANCE",
        "VCFENVMOD",
        "E1_SUS",
        "E2_SUS",
        "LFORATE",
        "LFODLY",
        "HPFCUTOFF",
        "VCF_LFO_MOD",
        "VCF_KEYTRK",
        "VCA_LEVEL",
        "E1_ATTACK",
        "E1_DECAY",
        "E1_RELEASE",
        "E2_ATTACK",
        "E2_DECAY",
        "E2_RELEASE",
        "LFO_WAVE",
        "O1_MOD_SW",
        "PWM_SWITCH",
        "O1RANGE",
        "O1_WAVEFORM",
        "O2_WAVEFORM",
        "VCA_LFO_SW",
        "O2_SYNC",
        "O2_RANGE_SW",
        "VCF_SLOPE",
        "VCF_ENV_SEL",
        "E1_KEYTRACK",
        "E1_POLARITY",
        "E2_KEYTRACK"
    }
    local byte = {}
    for i, v in ipairs(mySet) do
        table.insert(byte, panel:getModulatorByName(v):getModulatorValue())
    end

    local syx = MemoryBlock(byte)
    local fullmsg = MemoryBlock(string.format("F0 00 00 2F 03 00 %s F7", syx:toHexString(1)))
    console(string.format("f0 %s f7", syx:toHexString(1)))
    panel:sendMidiMessageNow(CtrlrMidiMessage(fullmsg))
end

[dnaldoog]

Looking at the manual it looks like many values on the JP8 go from 0-255. This means that the sysex value for these values needs to be split into two bytes MSB and LSB. ie 127 will be 00 7f but 128 will be 01 00 and 255 will be 01 7f.

function create14BitValue(value)
    local bv = BigInteger(value)
    return bv:getBitRangeAsInt(7, 14), bv:getBitRangeAsInt(0, 7)
end

local msb,lsb=create14BitValue(value)

this function returns two variables (lua can do that!) that can be added to the sysex message: See panel attached.

Normally with MIDI values go from 0-127 which fits into one 7bit byte 00 - f7

Each byte from byte 0x19 in the sysex mesage represents 8 bit bitfields that also need to be split into two sysex bytes once calculated. It's a bit of a challenge!

I wrote a small panel that should should you the way. I only did byte 0x19 and a couple of the inital 14bit values in the message.

For the bitfield sysex you would create and alter new functions for each byte (ie 0x20) would become function processBitField20 and you would add it to the set_SYS_Values() function sequentially:

ie

    local sumByte19 = processBitField19()
    local m19, l19 = create14BitValue(sumByte19)
    table.insert(byte, m19)
    table.insert(byte, l19)

    local sumByte20 = processBitField20()
    local m20, l20 = create14BitValue(sumByte20)
    table.insert(byte, m20)
    table.insert(byte, l20)

Also I would recommend naming all your controls to being as close to the names in the manual. It will save confusion as you go deeper and deeper into the abyss!

Jupiter 8_1.zip

[puffer3]

Thank you dnaldoog! Heres my panel so far. I will try to integrate some of your suggestions! also attached is a single and full patch sysex dump from the synth i nabbed last night

This community is very supportive and I do really appreciate it. I have felt a bit overwhelmed just trolling the old forum. Thanks again!

jupiterpanelAndSysex.zip
.

[dnaldoog]

Thanks @puffer3 for that.

I can't understand the manual. I don't see any reference for how to send individual values to the Jupiter 8. Most controls are indeed 0~255 so that would probably mean you have to use NRPN or sysex on each control, but I'm no sure how to do that from the manual.

The sysex for dumping data that I suggested is probably about right. I loaded a MIDI Quest Demo instrument for Jupiter-8 MIDI KIT but moving the sliders sends no MIDI??? If you could download MIDIQuest and connect to the machine maybe you could sniff out the MIDI messages? Here is a screenshot.

[Godlike-Productions]

You need to use 2 nibbles to send the 0-255 values. The Encore supports 255 value resolution for all continuous values. There are a few parameters that are bit maps (the switches). From what I know MIDI Quest doesn't work well on the Encore as the Z80 can't cope with dense stream of MIDI data. The Jupiter 8 was never designed to allow patches to be loaded many times a second. It was designed around the tape interface for loading patches, which is much, much slower. Even the Encore was not designed to do what we are asking of it and it doesn't have rate limiting in it. It just passes stuff to the Z80 which chokes. Realtime control of the Encore really is a hack on top of hacks.

I wrote my own MIDI scheduler to get it to work reliably.

[dnaldoog]

am working on a panel for a Jupiter 8 with Encore MIDI. It doesn't have sysex or CC parameter updates, but apparently the workaround it to send a full patch every time a parameter change is performed…

On re- reading this I can see why moving the controls doesn’t do anything in MIDIquest, but then again it too should be sending the full 28 byte message on any modulator change? Doesn’t seem to.

[Godlike-Productions]

Just to say - bijevel has done this but he probably won't be very helpful. He is selling it for 79$: https://godlike.e-junkie.com/product/GP-S-JP8M/Jupiter-8-Morph

Well, it is not forbidden to sell panels but afaik you would be forced to publish the source code. At least this is a GNU condition which does apply to many 3rd party libraries which Ctrlr is built of. I don't want to start a war here but I had to say that. This community with many people who are selling panels just does not feel right to me.

Just wanted to clarify that this is my panel, not bijevel. I have worked with him on the Kurzweil panel, and we are working on another project together, but I developed Jupiter 8 Morph.

Regarding selling the panel, I am far from the only person selling products based on ctrlr, even on these these forums here. VST, Juce and Ctrlr allow for sale of products built on the platform. There was a lot of work put into my panel, and I think it's priced similarly to editors with similar functionality such as those by sountower, though the market is very, very small, being that there aren't very many Jupiter 8's around.

Part of the reason I decided to charge for this panel, is because I implemented the librarian, which was functionality that was requested, but that I had little use for personally. The librarian took a long time to develop and get working. Also, I provide ongoing support for the products. I also provide patches for users of the panel.

I feel as though I have contributed to the community with code examples from this product and other panels that I've developed, and when I stop supporting Jupiter 8 Morph, I will release the source code publicly.

The fact is, developing software, especially to cater for requests from others, takes time that I could have spent writing music, or doing paid work in my studio, or on one of a range of other projects that were put on hold. The sales of the software even at the price point I have chosen and even if I sell a copy to every Jupiter 8 user is not going to make me rich, and realistically very unlikely even to pay for the hours I put into the software. All of the revenue I've collected from the sale of Jupiter 8 Morph is being set aside for an apple computer at some stage, so that I can at least be self sufficient in building editors for OSX.

I know not everyone will agree with me, but those are my reasons for making this a paid product, and will shape decisions for other software I develop in the future. If there is a significant investment of my time in something, especially if it is to fulfil requests of others, then I'd like to be at least somewhat compensated for that time. My other option is to not do the thing, and direct my time to things for me. Software that is less demanding on my time, or things that I build for my own needs that I would have done otherwise, tend to be released for free, and I have released a lot of stuff over the years for free, and will continue to do so.

[puffer3]

I think its totally fine for you to sell your panel. Its within the license and was obviously a ton of work!

[damiensellier]

The licensing is pretty clear for Ctrlr.
Ctrlr is released under a dual license type. Roman Kubiak already talked about that on the old forum, you pick up the one you prefer and fits better to your projects, either the GNU which is more for sharing the open source files with mods, OR under the Ctrlr Copyright (License BSD) that just requires mentionning that your binaries have been made with Ctrlr and with its copyright notice it deserves (in the documentation and/or in the credits window for the panel).

Ctrlr uses Juce framework which requires to comply to JUCE license as well which is fair to me. It's free under 50K$/year if you leave the JUCE logo. If you make more money or want to remove the JUCE logo, you have to pay a one-time fee of about 700USD.

Ctrlr also uses the Boost lib which is under the MIT license as well as the luabind. LUA is under MIT as well, so you do whatever you want with it.
And if you release some panels as VST3 you need to sign the agreement with steinberg, it's easy and free. VST2 is closed from now on and no one shoud distribute VST2 without the prior agreement from Steinberg. If you respect all that you are good to go.
The only copyright issue with panels is if someone use Copyrighted materials such as trademarks (yamaha, roland...) and/or their logo without consent. Same applies to extra Fonts/typeface imported for the Panel GUI, the stock ones are open source.

Hope it helps with the licensing side of Ctrlr. Good luck with your projects.

[Godlike-Productions]

Just on Logo's, I have been in touch with Roland, and they have a blanket policy that nothing should be released with their logo unless they have made it (ie it's an official Roland Product), which is why I ended up sticking my logo on my panel where the Roland Logo is on the Jupiter 8. They are otherwise supportive apart from this one proviso. Might be useful for others making stuff supporting Roland synths in the future. I have my Juce and VST stuff all set up. Wasn't aware of the stop on VST2's though, thanks for the update there.

[damiensellier]

@Godlike-Productions don't worry about all. Steinberg just removed the VST2 support from Cubase 11 to push developers to focus on VST3. To be honest VST2 is quite dated anyway and will fade away slowly.

[dnaldoog]

HI there @puffer3 and @damiensellier,

This panel handles incoming MIDI and assigns to the panel.

I am not sure if it 100% because to be sure of that I would need to be working with the unit directly, but I thought I would also do this incorporating the current structure without your needing to do too much of a rewrite, because the design for MIDI IN/OUT all centres around that table.

--re-assemble nibblelised data 
--m2=midi -- received from machine
local t, total, offset = {}, 0, 7
    for i = offset, m2:getSize() - 2, 2 do
        -- don't include trailing F7
        -- offset from beginning of string DATA access only
        assert(i < m2:getSize())
        local msb = bit.lshift(m2:getData():getByte(i), 4)
        local lsb = m2:getData():getByte(i + 1)
        total = msb + lsb
        table.insert(t, total)
    end
    local reassembledData= MemoryBlock(t)

I have added some fields to the main lookup table which are the BIT.AND and BIT.RSHIFT numbers needed when re-reading in the bitfields;

...
    {"ENV_2_DECAY", map = false},
    {"ENV_2_RELEASE", map = false},
    {
        "LFO_WAVEFORM",
        "VCO_MODULATOR_FREQ_MOD_SWITCH",
        "PULSE_WIDTH_MODULATION_SWITCH",
        "VCO1_RANGE",
        map = true,
        a = {3, 12, 48, 192}, -- AND Mask
        r = {0, 2, 4, 6} -- Right Shift this much
    },
...

Again as I said I am not sure if these are right, but you will soon know!

---

JUPITER 8_1_2_beta Jupiter 8 JG Edit_2022-03-12_19-21.zip

[dnaldoog]

The Juno Alpha 1 is a nice synth especially if you have the controls over the parameters with a panel or the programmer.

I actually have written a panel for it. You might find the drag and drop librarian interesting. :)

[damiensellier]

I actually have written a panel for it. You might find the drag and drop librarian interesting. :)

Hi John, I wanted to take a look at your panel but the file downloaded from souceforge with the main green button is the ctrlr 5.3.198 dmg. You should chech it out. Have a nice week.

Edit: I downloaded the panel from the updated tree

[dnaldoog]

I actually have written a panel for it. You might find the drag and drop librarian interesting. :)

Hi John, I wanted to take a look at your panel but the file downloaded from souceforge with the main green button is the ctrlr 5.3.198 dmg. You should chech it out. Have a nice week.

Edit: I downloaded the panel from the updated tree

This should be the link for MacOS https://sourceforge.net/projects/juno-alpha/files/MacOS/

[puffer3]

Yes The jupitders are quite rare. The one we are building this panel for is in pretty good shape and sounds amazing.

I love an alpha juno! I don't have one but I do use the "Redominator" plug in sometimes to get the hoover sound.

[damiensellier]

@dnaldoog I just watched Espen Kraft videos about the Roland MKS-50 vs Alpha Juno. I want one, the pads sounds so good!
The rackmount form factor of the MKS50 is really nice since the controllers are missing on the keyboard anyway. I'll check ebay if I could get one for a good price.

[puffer3]

Which panels do people suggest for saving panel presets on the computer with a simple browser (name only, not a file browser)? I want to add computer based patch storage to this panel and have been looking at the DX-11 panel. Is there one that is closer to what I am after?

I see there has been some patch load and save functions added to this panel. I will try to work out a clean way of implementing them. Thanks!

Thanks for all the help everyone!

[dnaldoog]

Hi @puffer3,

I think the best way to do this is with json, but it might be a steep learning curve. I have almost finished an implementation for your panel. It's interesting for me to review and brush up on such stuff before it all dissolves into the fog.

By saving patches as json you will be able to assign a name and optionally other parameters linked to any one of the 128 x 64 byte sysex messages.

I have written a few utilities here and one of them concerns json, but as I said I have almost finished a suggested implementation for your panel.

So please stand by!

[puffer3]

Thanks for the tip. it would be easier to use json instead of just writing the table of modulators to a data file (like in the file example panel) with a unique name and then setting up a file browser and reloading with the assign sysex function? That was what I was working towards yesterday with limited success. Alas I am not really a programmer, tho these projects have made me want to get better at it.

[puffer3]

I know I havent been able to contribute much besides visual assets and layouts, but I did make some switches to use in place of the pushbuttons (which I was also proud of, but still need to be modified to remove the large black border)

Jupiter8SwitchLayout.bpanelz.zip

[Godlike-Productions]

I second the use of .json It's human readable and is a bit of an upgrade on xml, though that also will work.

There are .json methods build into ctrlr. A few things to bear in mind.

5.6.23 has a few bugs in error handling. You must ensure that you are never trying to save nil to any modulator or file. Ctrlr will crash badly. There's some discussion in the these forums at github about some protected space methods that I recommend.

Secondly, you cannot write binary data to .json. You must convert to a string.

On the upside, the .json methods automagically render table structures so you don't need to decode and encode them yourself (apart from any conversion to and from binary data.

Final recommendation is to use memoryblocks to hold your runtime data (ie read and write from the file into memoryblocks). If you want to make your panel's patch data compatible with mine, I can help with the methods around data structure formatting, though much of it is already in these forums. Have a look at the posts on class structures that I've provided. Those are all based around my Jupiter 8 Panel.

[dnaldoog]

Hi @puffer3,

I think the best way to do this is with json, but it might be a steep learning curve. I have almost finished an implementation for your panel. It's interesting for me to review and brush up on such stuff before it all dissolves into the fog.

By saving patches as json you will be able to assign a name and optionally other parameters linked to any one of the 128 x 64 byte sysex messages.

I have written a few utilities here and one of them concerns json, but as I said I have almost finished a suggested implementation for your panel.

So please stand by!

Hi there @puffer3

Here is a very rough example of using json. This panel is not complete of course, but let me know what you think!

---

UPDATED 3/17/2022!
jupiter8dnaldoog_v4.zip

[Godlike-Productions]

I've already built one for the Jupiter 8 with Encore - available here - https://godlike.com.au/index.php?id=150

If you want to build your own, you'll need to keep in mind that the Z80 is really, really easy to overwhelm with MIDI data, which was one of the problems that some of the other editors suffer from. Ctrlr will send a huge amount of MIDI data out, really quickly, when you move a modulator sending Sysex strings. This will crash the Jupiter and freeze it.

[puffer3]

I had emailed you asking for a demo before I started this project but received no reply. The Morph function is really interesting and smart. Thanks for contributing! Are you willing to share how you slowed down the transfer rate to help with the data transmission?

[Godlike-Productions]

If that was a few weeks back, and you are Henry, I did send an email back with a link to the demo to the gmail address. Apologies. I was going to follow up to see how you got on.

I'll post the reply here instead or rewriting it. Let me know when you've managed to download it.

Hi Henry,

Thanks for getting in touch.

You can download the software here - https://godlike.com.au/index.php?id=356

It will launch into the 30 day demo the first time you run it (you will need a free ilok account). Just download and place the plugin into your plugin directory. The demo license allows you to use all of the different versions (standalone, AU, VST, Mac, Windows). I recommend you do a backup of your Jupiter’s memory first using a sysex dump utility.

I control the encore in a similar way as MIDIQuest , except that for editing I keep the edit buffer updated using sysex. Nearly all of the controls on my panel can be automated via your DAW software. Just map the control as you normally would, and make sure that control mode is set to on. Turn control mode off, if you want to import or export patches to the Jupiter 8. Turning control mode on turns off the MIDI thru of the Encore and stops patch dumps. This is to reduce the risk of corrupting the dumps. If you are just modulating the low pass filter, you can use the assignable MIDI CC’s such as expression, but if you want to automate more than 1 parameter, I’d recommend using SYSEX as that will reduce the overall MIDI bandwidth.

I wrote my own MIDI scheduler that essentially samples every parameter from the software and updates the Jupiter’s patch edit buffer. The sampling period is determined by the MIDI Delay parameter in the bottom right. I found that below 200ms my Jupiter 8 would glitch and could freeze up as the Z80 gets overwhelmed with data, though feel free to experiment. Increasing this value to 250ms to 300ms seems to be a good balance between keeping the Jupiter running smoothly and allowing expressive control.

I wrote the MIDI scheduler to be as efficient as possible. For example, it doesn’t send MIDI data if there are no changes in values.

I wrote this primarily to allow real time automation of the Jupiter, so it very much is designed to work within your DAW. The librarian was added later (and ended up requiring about 90% of the coding) and it works as an effective patch editor.

The software is still being actively developed, so if you come across glitches, let me know and I’ll get onto them. As always, if you have questions, I’ll do my best to help out.

Again apologies that my email didn't get through

Regarding the transfer rate, I've outlined it above, but I think I dropped some code examples in these forums as well somewhere, for helping out others.

[puffer3]

gosh you know my name? blush I must have entered my email address incorrectly to the contact box (plz dont post it here haha) but I am glad to finally get to look at your panel.

Also, thanks for sharing your knowledge so freely!

[Godlike-Productions]

No worries,

As I mentioned, if you find anything that doesn't work or have any questions, get in touch. There's a lot to the plugin. I worked on it for about 3 years from when I first got ctrlr talking with the Jupiter 8 (though not full time). I have a couple of other projects to get stuck into soon before heading back for Version 2. If you have requests for features or changes, let me know and I'll add them to the development schedule.

[dnaldoog]

This is a new version with mock jupiter8 midi receive panel included for testing of receiving dumps as well as json file load/save functionality. Includes json dump file.

jupiter8dnaldoog_v4.zip

[puffer3]

thanks I am going to test it tomorrow! Excited!

[damiensellier]

@dnaldoog Thanks for the panel! I'll study it this weekend for the json capabilities, I really need to learn more about it for future preset librarians.

[puffer3]

I did test the panel yesterday and it seems that the sysex messages are not controlling the parameters yet. CC for volume works and the bank request works, but even the switch parameters (which shouldnt need a timer to slow them down I would think) were not sending messages the synth would respond to.

I am going to compare some sysex patch messages and make sure they are formatted in a way the synth can understand.

Also it seems that only some versions of ctrlr want to send sysex with the panel in its current state. I am using a mac and versions: 5.6.23
5.3.198
5.3.163

I also tested it on the newest Windows build with no sysex whatever coming out.

because each one seems to have bugs the others do not.

Any help would be appreciated although I have already received a lot from here!

[dnaldoog]

Hi @puffer3 -

Maybe the sysex header message is wrong? I just put that in as an example. I had trouble understanding the manual.

Often one loads a patch from a memory location on a Synth and that gets loaded to a temporary buffer on the synth. It is that edit buffer or whatever it is called that is changed, not the patch residing in the 0-127 (or whatever memory location) you loaded from. When you make some changes you like - the sysex is then saved to a memory location on the synth (maybe back to the original writable memory location). You probably know this but that could be the issue. That sysex is maybe not correct? You maybe need to send the 64 byte string to the edit buffer?

Then there could be an issue with the actual data itself. It was all a guess on my part.

The other problem could be that the message is arriving too fast. With Ctrlr, you can delay sending a whole message but I'm not sure you can control the speed of the actual message being sent like you can in BomeSX or MidiOX on Windows. Is it Snoize on MacOS?

I wonder if you can route the panel's MIDI to thru on a program like MidiOx which will then slow down the actual byte by byte rate it passes on to the synth?

REF:

1. https://ctrlr.org/forums/topic/splitting-sysex-for-older-synths/
2. Slowing down sysex for older midi gear. #460

Also I would only use version 5.3.201 on windows and 5.3.198 on MacOS. 😊

[puffer3]

After working on the prophet and OB8 panels (which are a bit easier) I feel a little better about Ctrlr. Now I am back on trying to get this one to work. I am taking my panels to the studio today to test and see. I will also try @Godlike-Productions jupiter 8 morph panel and see how that goes.

I will doubtless be back here asking for more help. I think the sysex formatting is beyond my skillset

[Godlike-Productions]

I'm here if you need a hand, or have any issues. Hit me up by email, or here.

[Godlike-Productions]

On the Jupiter 8, the edit buffer is seperate to the patch locations. When you select a patch, it loads into the edit buffer. The sysex for addressing the edit buffer is slightly different to accessing the patch locations, and the sysex string lengths are also different.