I’ve got an Ensoniq SQ-80 and I’m attempting to make a preset for it. It responds to NRPN messages for the parameters, and while setting up faders or lists do work the synth steps through every single adjustment extremely slow. Often times the synth will freeze up and will reboot. Once a parameter is selected though sending CC#6 alone is fast and causes no problems.
Is there a workaround for this situation? A way to send the initial MSB and LSB once when selecting a control, and then send only the values while adjusting?
When monitoring IN (of both the SQ-80 and E1) does the order of CC’s match (CC 6 & CC38)? Maybe the SQ-80 has trouble with MSB first or LSB first? Have you tried switching it?
I have the control set for LSB first. There’s no response when sending MSB first.
Update: When monitoring the SQ-80 front panel controls and selecting a parameter to edit I receive a NRPN of 98 (LSB) and 99 (MSB) only. When adjusting the data slider a data entry of CC#6 is sent, and CC#38 is never used.
The 98 and 99 part are correct, but only 6 and no 38 is bit odd. The Electra One also sends 100 and 101 (if memory serves me right) are a bit superfluous, but should not hurt. @martin any ideas?
I think I have seen the pattern you describe before on the Behringer BCR2000.
The 100/101 are sent to reset the current active NRPN parameter. That way each NRPN “message” leaves the synth in a consitent state. It is quite a standard way of doing that. I can imagine it could make troubles on some older synths.
I am currently occupied with preparing stuff for the Superbooth but I will add this on my TODO list. I mean, make this reset optional.
@Feinsveur it would be great if you could try to send (say from some application) a NRPN message with and without the 100/101 to see, if it is the reason why SQ80 freezes.
I’ll look into an application that can send that NRPN and see what happens.
While doing some research on the web I found some threads that talk about this particular issue with the Ensoniq ESQ-1 and SQ-80. Apparently the Z80 processor in the synths can’t handle high traffic of NRPN messages. They only expect the single 98/99 message for parameter selection followed by a regular CC6 for the value, which is all that is sent while monitoring the synths’s value slider.
I stopped working on it due to how the SQ-80 was handling the parameter changes. Changing the parameter values worked, but unfortunately it seemed too much for the processor to handle live adjustments and would freeze the synth. At least that’s what I was finding.
If there’s a way to send the parameter’s NRPN message 1 time while first selecting it and then only CC#6 values after, it’d work fine. From what I was finding though is that since CC#6 is used exclusively for changing all of the parameters, you would never have an accurate representation of each of the parameter’s current values using a global CC#6 message, which really ruins the fun.
Hi @Feinsveur , let’s get you back to fun! The SQ80 is too much of a beauty to give up on it I know , causeI played it myself once back in time.
there may be two parts in the solution:
the short term trick: slow down the traffic to the SQ80 by adding a Rate to the Device settings. Start with 10 ms and see if that solves. If you had to set it on 100 ms without positive result, then it is surely not enough as a solution, but a value of 5, 10 or 20 ms is certainly recommended for older synths, as it avoids clogging them.
the ‘a bit more work’ trick but it should resolve the issue 100%: make your own simplified NRPN message via lua. For this to work you change the NRPN controls into virtual controls, and you assign a ‘simplifiedNRPN’ function to each of them. You ensure the function retrieves the controllernumber and the value to send. Also you need to foreseena global variable in which you store the previous controllernumber that sent NRPN messages. In hte function you can make your own NRPN sysex , reducing the amount of CC messages to the minimum required (only CC6 if the controller remains the same, and sending the initial MSB and LSB as well when it changes).
If you have no experience with lua, I’ll make to initial function for you, it would be good you give me access to a copy of your preset, then I’ll build it in right away so you can test it. Once succesful, we’ll document the code here for others to pick up, and you can alter the remaining NRPN controls in your preset.
@Feinsveur : Thank you so much for getting back to me about this! I hope that @NewIgnis 's reply will will help you to get back to things… I’m definitely way behind with my efforts… I was still trying to figure out why I couldn’t get the OSCs to react separately to my efforts to control them… But all in all it should be possible to create a preset for the ESQ-1/SQ-80 family as there are plenty of editors / controllers out there, no?
The simplified NRPN message would be the answer for sure. Unfortunately, I have zero know-how with lua, so any help on making a custom message would be appreciated.
The first trick probably still would’nt work, because even before crashing the SQ-80 will slowly step through each and every increment change (about 1/4 secs) you send to it using the full NRPN. It really only wants that CC#6 after the initial NRPN.
I’ll have to look over my setup to see if I even have the preset available. It wasn’t much at all, just like 2 controls to test the parameter c
hanges until I figured out a good solution.
I took a note but I do not want to promise I would work on that in coming weeks. From what was said here I assume that if there was an option to send the NRPN parameter change just once and then keep sending value changes it should be ok with the ESQ-1/SQ80. Right now, each NRPN includes the parameter identification and even the parameter reset messages.
It contains 3 generic NRPN’s on device 1: A fader, selection list and a button, all are to be set up as virtual controls not as NRPN.
Currently it assumes all NRPN numbers will be between 0 and 127.
So when a control is tweaked it’ll always send CC99 as 0.
It also assumes none of the values to transmit are higher than 127.
That can be changed naturally.
Each virtual control has been assigned a function I have called simpleNRN
And here’s the lua script
deviceId = 1
device= devices.get(deviceId)
devPort = device:getPort ()
channel = device:getChannel ()
previousNRPN = 0
function simpleNRPN(ValueObject, value)
local message = ValueObject:getMessage ()
local parameterNumber = message:getParameterNumber ()
if parameterNumber ==previousNRPN then
midi.sendControlChange (devPort , channel, 6, value)
else
previousNRPN =parameterNumber
midi.sendControlChange (devPort , channel, 99, 0)
midi.sendControlChange (devPort , channel, 98, parameterNumber )
midi.sendControlChange (devPort , channel, 6, value)
end
end
What is does: when the control selected is the same as the previous (via previousNRPN), it will only send CC6 values, otherwise it’ll send CC99 with a 0 value, then the control number as CC98 and then CC6.
In the meantime I discovered a second synth that doesn’t respond well on the 2 subsequent RPN messages the E1 transmits after each sequence of 4 NRPN messages, i.e. the preenFM2. I already built my own simplified NRPN function to deal with that. Simple enough but the downside is that any control that should have been a NRPN now has to be set as a Virtual controller. The issue is that the preenFM2 doesn’t use SysEx parsing but relies entirely on a one time transmission of all NRPN’s into the E1 for setting the parameters right. And there is going to be more work involved to reconvert all those received NRPN into virtuals. A setting in the E1 for simplifying NRPN use (without the RPN ) would be welcome.
I know , causeI played it myself once back in time.