This is work in progress of an editor for my ESQm/80. Its an ESQm with the SQ80 ROMs hacked in. It also is my 1st attempt at integrating LUA extensions into my editor. Most of the controls are there and functioning. I used Gemini AI to help a lot. I have to take another break and ask for some help. I am having trouble getting the SYSEX dumps working so requesting a patch does not work at this time. I have most of the controls going thru a routine called simpleNRPN that was on a forum post, I expanded it and asked Gemini for help after I broke it! Please look it over and suggest anything! I will get back on it in a week or so after I sit with it a while. Its a little messy because I am not a professional coder.
I have shared it for all to see.
Questions I have.
Not sure why I cannot get the sysex request working.
When I manually receive a dump into the web editor, I am unsure about how to handle the nibblezed data and point it to a control.
When I send a patch from the web editor I crash the ESQm80. I restart and the mini edits work just fine. The solution has been to turn off the ESQm when updating the preset on the mini. I need to figure out a way to prevent the dump from looping thru the mini and sending data to fast to the ESQm.
These are the biggest issues I have. I have other issues but those seem to involve waiting for an update!
Hi, can you share the MIDi implementation guide/manual for your synth? Can you also tell what specific MIDI settings you have set on the synth (MIDI channels, Device ID’s, etc)
Hey Dave… I’ve been getting Claude AI working and managed to get preset set up for the Kawai XD-5. I’ve got an ESQm as well and will work on a preset as well. Currently have the Yamaha TG-77 on the desk and trying to work out the kinks in that. I’ll take a crack at the Ensoniq once I’ve cleaned up this one unless you all get it done before I get a moment. Best of luck
Better share the whole preset, Dave. Else it’s rather difficult to comprehend the interactions (or their lack of it). Do you have any manuals on how the ESQm is to behave ? Especially any differences between all models ? You mention ESQ1, ESQm, ESQm80, SQ80… Usually manufacturers refer to the model in the sysEx headers, so one set made for the SQ80 doesn’t necessarily work for the ESQ1. I’ve found one on the internet http://www.buchty.net/ensoniq/files/manuals/ESQm.pdf , hopefully that was a correct one to check on?
It states :
The receiving ESQ-M will only recognize system exclusive messages if the MIDI channel number in the message is the same as the MIDI base channel selected on its MIDI page and its MIDI enable parameter is set to recognize system exclusive messages (i.e the display should show ENABL=KCPSYS).
To be able to receive sysExdata, the ESQ-M must be in program select mode (i.e. the program page must be displayed) and the MIDI enable parameter on the MIDI page must be set to receive system exclusive messages.
May I make some suggestions:
do not hardcode the MIDI channel (0A). You might regret this later on, when for some reason you need to change the channel. But as long as you are performing basic tests, you might stick to a hardcoded “0A”.
in the dump, remove the “00”. According to page 109, that is not part of a single program dump
my biggest concern: I don’t find anything about a program request in the manual. For sure the sequence show in the “Default Request” above is incorrect, as it is the one for a dump. You can try swapping the command byte “01” for another to see if the Request is present. I’d try “00”, “71” and “03” but that is entirely on your own risk (be sure you have backupped your programs). But nothign is mentioned about a request command in the manual. Perhaps in a later firmware?
check to enforce a dump: it seems on page 87 / 88 to explain how to send a single program out via midi. Try it out with:
This is the link to the current version I am working on.
I will clean up the hard coded MIDI channel info etc.
I have looked over all the manuals at the butchy.net site. There is a section on that web site that describes the upgrade/mod to the ESQm to add the SQ80 ROM’s. I do have an ESQ1 I could be doing my testing with but I would have to pull it out of the closet!
It is super hot here in Portland today so I will stay inside and work on this and do some practicing until it cools off, I will let you know what I come up with.
I do, I also use a MIDIHUB to route and monitor traffic. I worked with everything yesterday and got nowhere. I am able to initiate a dump from the front panel to the web ap. I just cannot seem to request one. A request is made but the ESQm does not respond. I wonder if it is because of the channel I chose (11)? But I am using it in POLY mode so that should not be an issue. And yes, it is in “program” mode when I send a request. I have also tried various types of request, different channels etc.. Will attempt to spend some time on it this afternoon.
That was it. Both the docs I was looking at for this information was for V1 of the OS.
"ESQ-M – Musician’s Manual
ESQ-M MIDI Implementation Specifications (Software ver.1.0) 1.0 ESQ-M System Exclusive Format
1.1 ESQ-M System Exclusive Header
All ESQ-M System Exclusive messages start with the following header. The receiving ESQ-M will only recognize system exclusive messages if the MIDI channel number in the message is the same as the MIDI base channel selected on its MIDI page and its MIDI enable parameter is set to recognize system exclusive messages (i.e the display should show ENABL=KCPSYS).
System Exclusive status byte ENSONIQ I.D. code
ESQ Product I.D. code MIDI channel number
To be able to receive this data, the ESQ-M must be in program select mode (i.e. the program page must be displayed) and the MIDI enable parameter on the MIDI page must be set to receive system exclusive messages.
1.2.1 Single Program Dump
This transmits the program currently selected on the current Track. Refer to Table 1 for details on the structure of the program.
xxxxxxxx F0h, 0Fh, 02h,
00000001 THIS WAS WHAT I WAS SENDING. Single Program Dump code
00001111
0000nnnn
2 nybbles per byte of program data102 data bytes (204 nybble-ized MIDI bytes) 1= low nybble, h = high nybble
Hi, I have patch request functioning. But, as I was finishing Rule linking ENV4’s controls to the sysex dump (about 40 controls). The ESQm started crashing again when a patch was requested from the mini.
Like before sending a preset “to” the mini from the web editor, the ESQm crashed after about 40 controls were added. Now it was doing it after the mini started requesting a patch after about 40 controls were linked to the sysex dump.
What I noticed:
The mini sends a patch dump request to the ESQm. Out Port 1 (TRS MIDI out)
The ESQm responds with the correct sysex dump. Received on Port 1 (TRS IN)
Just after the MINI receives the dump, the mini then sends ALL of the Controls mapped to NRPN’s out Port 1 (TRS) (The same port that sent the initial dump request). Then the ESQm crashes because there is an overflow of data.
Can I stop this “Echo” ? (It’s not really an echo).
Can I slow it down as I do all of the controls individually on the preset?
For sure you should not echo received patch parameters. That is indeed not the intention, so something in lua is triggering that. I have no access to my pc, so you have to check yourself. The first place to look for is an onChange callback function in your lua that reacts to parameter changes by sending out the sysex commands. Check it only sends out when the origin of the change is internal to the E1 (changing a knob) and not when set via lua or received via midi.
Also there is a throttle function for each device in a preset. You should try setting it at 10ms or a bit more. It creates additional delays between 2 message transmissions. That will not stop the echoing, but it should prevent clogging of messages followed by the synth freezing .
A small update, I have the sysex dump working and have a bandaid applied to prevent the ESQm from crashing as I map parameters to the sysex dump. I am looking for an accurate layout of the dumps. Everything was fine until I got to the LFO’s. Running into time constraints again.