Hi everyone,
I’m in the process of building a preset for a 03R/W synth. That is in my opinion a super synth to work with. Apart from the workstation features it goes beyond what the M1 was capable of (and that was a very succesful engine in the nineties), only missing one feature the 01R/W had. I actually forget its name, since I read all too often its effect wasn’t having a lot of sweets spots.
Anyways…where help could be needed: the O3R/W has time direction controls. These alllow the effects of keyboard tracking or velocity to be positive or negative impacting the time parameters of EG’s, but I haven’t figured out yet how to control them via SysEx.
An additonal problem is that I attempt to hide controls when they are not relevant , but I seem to be always too ‘late’. The hiding feature is not imposed on the patch on-hand but rather on the next patch to come, which is quite undesirable.
If any one recognizes these obstacles and found a solution ,do let it be known on the forum.
This being said, I found my way though the other Sysex quirks Korg has used on the 0xR/W range. For those interested, give me a sign, and I’ll explain how to deal with them.
Best of luck. Peace !
I don’t know exactly how you’re implementing the call to hide/show stuff, so this is a bit generic.
If you are parsing the patch sysex received from the 03R/W and can determine whether controls need to be hidden, you should be able to call a hideControls() function right when parsing the sysex.
The hideControls() would do the normal things –
(with the appropriate control ID, any hide/show checks, etc)
function hideControls(controlID)
local hiddenCtrl = controls.get(controlID)
absCtrl:setVisible(false)
end
This is exactly what fails. An example of my code in the Matrix 1000, doing similar things:
function sus1Hide(ValueObject,value) ---- hides the sustain control of env1
local bool = true
if value ==1 or value ==3 then bool = false end
local control = controls.get (52)
control:setVisible (bool)
end
What I found is that when I call these hiding functions (like sus1Hide in the example above) after the midi.sendSysex command that triggers the patch parsing, these hiding commands are actually executed before the patch parsing takes place. So I assume some parallel processing is happening, where the patch parsing is taking place in parallel with the execution of the lua code, and I do not know how to resolve this.
What I need is a call back function which I’d name parameterMap.pppp, where pppp stands for Patch Parsing Post Processing. If such a function would exist, I could execute the hiding and formatting functions exactly after the patch parsing has finished, instead of in parallel.
I experimented with the parameterMap.onChange function where at least I hoped to test the idea, but my preset runs out of memory during the tests, so I stopped these tests.
Since parsing the sysex is serial, can’t you just put a straight function call into the hide/show at the end of the parsing routine?
Is there a way to put anything at the end of the parsing routine? AFAIK that routine is hidden. All I have in the lua code is my midi.sendSysex that kicks off the parsing. The hide/show I put thereafter is triggered too early.
Darn - I was hoping you had the sysex as some LUA calls. I don’t know if there’s any guaranteed thing you can check to see if it completed. Monitoring the last few MIDI values in the parameter map might work sometimes if they changed, but that’s not guaranteed. Maybe be gross and after the sysex call, check to see if the patch name has been updated, and then set a timer for 10 or 15 ms then do the show/hide.
Not perfect, I know.
Can you show me how to set a timer ? It may be a dirty solution, but if it works, all the better
This is cut out from my tc 2290 attempts to create increment/decrement pads (holding the pad automatically increments, etc). In this chunk, I’m sending sysex messages, but when the timer is running, the onTick() is called every tick, so you could increment a global counter and then in your hide/show function set the counter to 0, call timer.enable(), while loop looking for counter value to be some number, then stop the timer and do your stuff…
I know it’s a rough sketch, but time is tight here. I’ll try to work an example up in the morning here.
timer.setPeriod(20)
timer.disable()
function timer.onTick()
midi.sendSysex(PORT_1, {0x33, 0x00, 0x05, keyVal[1], keyVal[2]})
midi.sendSysex(PORT_1, {0x33, 0x00, 0x05, 0x0F, 0x0F})
end
-- virtual momentary buttons for up/down
function arrowValue(ValueObject, Value)
local message = ValueObject:getMessage()
local keyNum = message:getParameterNumber () - 100
print(string.format("param number = %d", keyNum))
keyVal = splitByte(keyNum)
if (Value == 1) then
timer.enable()
else
timer.disable()
end
end
1 Like
I created a basic preset to show timer, hide/show stuff.
Timer example
Wow thanks. I’ll check it out later this week.
Glad to help. It’s just a fun little demo/utility - no MIDI messages generated or anything.
If you’re prone to epileptic fits, don’t set the refresh rate too low. 
Allthough I have no access to my E1 right now, I couldn’t resist reading your code. Actually quite understandably written 
. I now see what the onTick might bring to the table.
I will definitely try it out as waiting function for the patch parsing. Hopefully the parsing itself won’t be stopped by the timer running 
And then I’ll use the timer function to add an additional filter ADSR to the Korg NTS-1 and an additional LFO to the Korg DS-8 and the OB-6!
Let’s find out how fast the MIDI transmission rate must be for the EG to sound snappy. I expect timer.setPeriod(x) to be somewhere between 10 and 50. We’ll see.
I would think LFOs using the timer would be great. Envelopes are trickier. In the analog world, envelope attack/decay times are usually well under 10ms, which is the lower limit for the timer period, so for audio (VCA) it would probably sound mushy/slow. For the filter, depending on what you want to achieve, 10ms+ may be good enough, but you might feel/hear a lag.
GOOD NEWS ! Patch Parsing Post Processing is a fact 
I made the lua to wait 275 milliseconds after sending the midi SysEx that triggers the patch parsing.
After that time laps, the parsing was over, and then indeed the post processing takes place as intended. 250 milliseconds was too short for the current 03R/W parsing (and it’s not yet complete).
To be safe I 've set the wait time to the double value, 550 milliseconds. Not short, but sure.
excellent news. You can even flash a button saying “parsing” now. lol
It would be best if there was some callback hook that signaled when parsing was complete. Then we could wait until that returned.
But for now - it works and you can keep moving forward. great news indeed.
I’ve reached version V2.0 of the Korg 03R/W preset.
I was able to control and parse every single parameter, except for the “purple” effects parameters. These ones do control the synth but aren’t read from the buffer dump.
https://app.electra.one/preset/YEiyHkzSEw8d9duJWv2Y
Enjoy!