Yamaha Reface DX

[m.tarenskeen]

Hi,

I am working on a Ctrlr panel for the Yamaha Reface DX – if anyone is interested.

A lot of it is already working 🙂
I am strugling a little bit with LUA code to read a SysEx dump with all parameters from MIDI at this moment. The MIDI monitor shows me my panel is sending a SysEx dumprequest, and my Reface DX is responding to that. But it is also continuously sending 0xF8 bytes (MIDI clock message) and 0xFE (active sensing). This makes it very difficult to see what is happening in the Midi Monitor window.

Unfortunately it’s not possible to switch the clock messaged Off on my RefaceDX.
1. Is there a way to filter 0xf8 and 0xfe bytes so that I don’t see them anymore in the Midi Monitor?
2. How can I filter/ignore these bytes in my LUA code for reading data from the MIDI buffer and put correct values in my Ctrlr panel modulators?

As a teaser preview I am attaching a picture from my Reface DX Panel.

[dasfaker]

1. Just use something like MIDIOX and its midi monitor instead of Ctrlr one, there you can filter those messages.

2. Where do you want to filter them? In “Called when the panel receives a MIDI message” method?

[m.tarenskeen]

dasfaker wrote:

1. Just use something like MIDIOX and its midi monitor instead of Ctrlr one, there you can filter those messages.

2. Where do you want to filter them? In “Called when the panel receives a MIDI message” method?

1. Yes, sure I know that. But still it would be nice if I could filter it in Ctrlr’s MIDI monitortool.

2. Yes that’s the idea. I have created a button that sends a SysEx dump request message. The RefaceDX will react by sending a SysEx dump. And in my Lua method I want to first check the size of the incoming SysEx, from the first 0xF0 to the last 0xF7, and if the size is the expected value, extract the correct values to set in my Panel’ s parameter values. For this to work all 0xf8 and 0xfe bytes should be ignored.

To make things more complicated (I hope it isn’t a problem for Ctrlr) the SysEx the Reface DX is sending consists of 7 SysEx blocks (seven times 0xf0…0xf7).

[dasfaker]

But the incoming dump should not be broken, it should get in “in one piece”. At least this is the normal behavior. I have synths here that also send 0xf8 and 0xfe messages, but the dump is always complete.

Are you on Linux? I know that at least on some Linux systems, the midi buffer is limited to 256 bytes so bigger dumps are split.

[m.tarenskeen]

Yes I am on Linux. In this case the the dump is 241 bytes in size, so that should not be a problem except if the 0xFE and 0xF8 bytes keep filling that buffer. You are right that from the moment the first 0xF0 arrives the dump continues uninterrupted until the last 0xf7 has passed.

I should do some testing on my Windows machine to be sure I am not doing something wrong that has nothing to do with this.
Maybe you can recommend one of the existing panels to study how handling MIDI SysEx in/out dumps can work in Ctrlr panels?

[dasfaker]

As you said, check each message size. From f0 to f7 is a single message. When the size match what you expect you got it, no worry about any other message. This method only process what you want, not every message received.

A simple example:

midiMessageReceived= function(--[[ CtrlrMidiMessage --]] midi)
size = midi:getSize()
if size == 241 then -- message size match patch dump
    assignDump(midi) 
end

function assignDump(midi) --  assign bytes from dump to modulators
panel:getModulatorByName("Filter"):setModulatorValue(midi:getByte(10), false,false,false)
.
.
.end

[m.tarenskeen]

OK, thanks. That helped me get going!

As you said, check each message size. From f0 to f7 is a single message. When the size match what you expect you got it, no worry about any other message. This method only process what you want, not every message received.

The problem is: I do worry about the other messages. If I send one dumprequest to my RefaceDX it responds by sending 7 sysex blocks. 5 of those blocks I actually need to read, 2 blocks I want to ignore, and 4 of those five have the same size. I need to check their content to know which is which.

It’s not quite clear to me how “Called when the panel receives a MIDI message” works internally. What happens with the data in the midibuffer after I have read them? How long will data stay there for reading?

What I want to do – but don’t know how:
1. Flush all the SysEx data in the buffer to get stable and reliable responses in step 2.
2. Send a dumprequest to my RefaceDX
3. Read all SysEx data, not only one SysEx block, that are received in the buffer. It looks like non-sysex bytes like 0xFE and 0xF8 are ignored automatically in Ctrlr. That’s good.
4. Check the received data for checksum errors or missing data
5. In case of errors start again from step 1, and keep trying maybe 3 or 4 times before showing an error or warning message.
6. Put all these data in one or more Memoryblocks so that I can do all kinds of things with them

Maybe these are partly things that Ctrlr already handles automatically. But I am getting unreliable dump results with my current experiments. Sometimes it works, most of the time I am getting only part of the data received correctly.

PS: Panel parameter changes, loading and saving of SysEx dump of complete patch, sending SysEx dump, including checksum calculations, are now all fully functional. Much of the Lua code I wrote for this I can re-use for processing the received MIDI data. But I first have to get the correct and reliable SysEx data from my synth into Ctrlr.

[dasfaker]

Each incoming message triggers the midiMessageReceived method, so the message’s data is there until another message is received. For each message received, you will need to:

·Identify the message received by size.
·If size match but it’s the same for different messages, check the bytes that differentiate them.
·If the message pass these two filters, use it to assign values to modulators (call a function to assign them). If you need it, store the message as a memoryBlock.

Now you are done with this message, the next message will trigger again the method and so on.

midiMessageReceived= function(--[[ CtrlrMidiMessage --]] midi)
size = midi:getSize()
if size == 241 then -- message size match patch dump, but there are 2 with the same size. Suppose byte 5 differentiate them 
    if midi:getByte(5) == 0 then -- type 1
       assignType1Dump(midi) 
    elseif midi:getByte(5) == 1 then -- type 2
       assignType2Dump(midi)
    end
end

function assignType1Dump(midi) --  assign bytes from dump type1 to modulators
panel:getModulatorByName("Filter"):setModulatorValue(midi:getByte(10), false,false,false)
.
.
.end

function assignType2Dump(midi) --  assign bytes from dump type2 to modulators
panel:getModulatorByName("Level"):setModulatorValue(midi:getByte(10), false,false,false)
.
.
.end

[iceleben]

Hi dasfaker,
could you please explain why you had to set the false,false,false argument in your function panel:getModulatorByName(“Filter”):setModulatorValue(midi:getByte(10), false,false,false)
Thx,
Markus

[dasfaker]

Because this way the modulator don’t send it’s value to the synth.

[Possemo]

Hi iceleben, false,false,false is part of the correct syntax of setModulatorValue. If you don’t set them it will throw an error. Two booleans (in this case false or true) are not used in any way, one selects if the values should be sent back to the MidiOut (which you normally don’t want to happen so you set it to “false”). I forgot which one is the “send to midi out” switch as I always set it to false.

Oops, dasfaker you were faster than me.

• This reply was modified 7 years, 11 months ago by Possemo.

[m.tarenskeen]

You can download and try my Reface DX panel now. Yesterday the site was down. Today the site was online again, but a bugfixed version was replaced with an older version. I have uploaded latest version with some minor bugfixes again. Sorry for the noise.

Download: Yamaha Reface DX panel

• This reply was modified 7 years, 11 months ago by m.tarenskeen.
• This reply was modified 7 years, 11 months ago by m.tarenskeen.

[Author]

Posts