New Device Request: Waldorf M

[RadekPilich]

I will look into this later.

[christofmuc]

Let me know if you can find anything. Last time I asked Waldorf (I think it was about the Kyra) they just said "no". I said "well then I don't buy one...".

[RadekPilich]

The manual states: "Compatible with classic Waldorf Microwave I sysex messages (sound bank transfer/sound transfer)"

But those will only work with the classic MW mode and not with the extensions.

Sound Quest has an editor and EdiSyn as well, there was some sysex documentation available, but probably not publicly and only to the above mentioned parties.

https://github.com/eclab/edisyn/tree/master/edisyn/synth/waldorfm

[christofmuc]

Oh indeed, it seems to be right there: https://github.com/eclab/edisyn/blob/master/edisyn/synth/waldorfm/WaldorfM.java#L1952

[christofmuc]

There you go, no idea if that will do anything, I just used the values from the file above:

[christofmuc]

Waldorf_M.zip

[RadekPilich]

@christofmuc it's not being detected.

I can play it from Masterkeyboard though. However KK doesn't seem to get any MIDI from it, although computer sees it.

There is Device_Id setting on the synth.... I have tried 0,1,48, made no difference.

[christofmuc]

Hm, maybe wrong model number somewhere. It does not give any MIDI back? Can you record a sysex dump initiated from the device, we might figure out the model number from the dump.

[RadekPilich]

Is this format ok?

It's from
https://github.com/gbevin/ShowMIDI

Here is Blofeld to compare

Full MIDI OX here:

TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT
0000491A 10 -- F0 Buffer: 64 Bytes System Exclusive
SYSX: F0 3E 30 00 72 01 20 59 6F 75 27 76 65 20 67 6F 74 20
SYSX: 69 74 21 20 20 20 20 20 20 20 20 20 20 00 00 00 00 00
SYSX: 00 40 00 40 7F 3F 02 40 00 40 0A 40 03 40 01 40 14 40
SYSX: 03 40 0A 40 00 40 00 40 00 40
00004925 10 -- -- Buffer: 64 Bytes SysEx Continue
SYSX: 00 40 00 40 01 40 02 40 00 40 0A 40 03 40 01 40 14 40
SYSX: 04 40 0A 40 00 40 00 40 00 40 00 40 00 40 09 40 32 40
SYSX: 01 40 5D 3F 00 40 00 40 03 40 01 40 00 40 03 40 00 40
SYSX: 01 40 00 40 09 40 32 40 01 40
00004926 10 -- -- Buffer: 64 Bytes SysEx Continue
SYSX: 5D 3F 00 40 00 40 03 40 01 40 00 40 03 40 00 40 01 40
SYSX: 00 40 00 40 40 40 40 40 00 40 00 40 00 40 00 40 00 40
SYSX: 00 40 00 40 00 40 00 40 00 40 22 40 00 40 39 40 14 40
SYSX: 00 40 3F 40 03 40 01 40 00 40
00004926 10 -- -- Buffer: 64 Bytes SysEx Continue
SYSX: 04 40 05 40 03 40 00 40 5A 40 3F 40 00 40 00 40 03 40
SYSX: 01 40 00 40 03 40 00 40 00 40 03 40 00 40 36 40 5A 40
SYSX: 00 40 3C 40 19 40 00 40 18 40 00 40 1B 40 00 40 1A 40
SYSX: 00 40 01 40 02 40 06 40 41 40
00004926 10 -- -- Buffer: 64 Bytes SysEx Continue
SYSX: 58 40 00 40 41 40 03 40 00 40 19 40 00 40 18 40 00 40
SYSX: 1B 40 00 40 1A 40 00 40 01 40 01 40 5F 40 7F 40 50 40
SYSX: 7F 40 7F 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40
SYSX: 00 40 00 40 00 40 00 40 00 40
00004926 10 -- -- Buffer: 64 Bytes SysEx Continue
SYSX: 00 40 00 40 00 40 00 40 00 40 00 40 06 40 00 40 00 40
SYSX: 00 40 00 40 00 40 7F 40 00 40 00 40 00 40 00 40 00 40
SYSX: 00 40 1E 40 00 40 00 40 00 40 19 40 00 40 1E 40 00 40
SYSX: 00 40 00 40 7F 40 00 40 0A 40
00004926 10 -- -- Buffer: 64 Bytes SysEx Continue
SYSX: 00 40 00 40 00 40 00 40 00 40 00 40 20 40 01 40 00 40
SYSX: 01 40 00 40 00 40 28 40 00 40 00 40 00 40 00 40 00 40
SYSX: 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40
SYSX: 00 40 00 40 00 40 00 40 00 40
00004926 10 -- F7 Buffer: 64 Bytes SysEx End
SYSX: 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40
SYSX: 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40
SYSX: 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40
SYSX: 00 00 00 00 00 40 00 40 7F F7

[christofmuc]

Ok, I can confirm that the sysex dump you sent is a valid edit buffer, and the code accepts it. So it must be the device ID problem.

I made a new version that always sends its messages on device ID 127, which should be the broadcast ID:

Waldorf_M_V2.zip

[christofmuc]

You could also try to load a Waldorf M patch from disk into the database, and test sending it to the synth. Sometimes that works easier than requesting the data.

[christofmuc]

Released the beta version with 2.5.1, feel free to reopen if it doesn't work!

[RadekPilich]

Well, I can send a patch from disk via KK, but the bulk import from synth does nothing. The auto-detection works, although it produces mis-match that has to me corrected manually (the assigned MRCC is one item below the M in the list of MIDI devices]

I don't have rights to reopen the issue.

Additionally, the patch send from computer is not only loaded into the edit buffer, it is also immediately stored to the memory, where it overwrites the previously active patch. Don't know yet if this is a property of M or if we are sending it incorrectly.

[christofmuc]

Use this version. It stores the device ID from detection and reuses that.

But really the device detected is implemented with a get edit buffer command, and that works. It is weird get program dump doesn't work.

Can you attach a MIDI log from the conversation? KnobKraft stores it in the MIDI log tab, and you can save it from there.

Waldorf_M_V3.zip

The wrong MIDI channel is expected for now.

[RadekPilich]

Nothing is happening. It stays at 0%

00:40:15.933: In M Wavetable Synthesizer Sysex [f0 3e 30 00 72 01 4a 6f 75 72 6e 65 79 20 74 6f 20 4d 20 56 53 20 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00 40 00 40 00 40 04 40 00 40 0a 40 03 40 03 40 00 40 03 40 0b 40 00 40 00 40 00 40 01 40 00 40 04 40 04 40 00 40 0a 40 03 40 03 40 00 40 03 40 09 40 00 40 00 40 00 40 00 40 00 40 0c 40 00 40 01 40 2d 40 00 40 00 40 03 40 03 40 00 40 03 40 00 40 01 40 00 40 19 40 3a 40 01 40 6f 3f 00 40 00 40 03 40 03 40 00 40 03 40 00 40 00 40 00 40 00 40 40 40 40 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 48 40 00 40 03 40 02 40 2e 40 00 40 03 40 03 40 00 40 03 40 00 40 1a 40 7c 3f 38 40 12 40 3e 40 00 40 03 40 03 40 00 40 03 40 00 40 00 40 03 40 0b 40 1d 40 5d 40 68 40 46 40 03 40 00 40 00 40 00 40 03 40 00 40 03 40 00 40 01 40 10 40 00 40 1d 40 3d 40 0f 40 7f 40 03 40 00 40 03 40 00 40 03 40 00 40 03 40 00 40 03 40 00 40 01 40 01 40 1d 40 7f 40 45 40 00 40 46 40 7f 40 00 40 00 40 01 40 00 40 45 40 7f 40 45 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 02 40 01 40 00 40 06 40 00 40 00 40 00 40 00 40 00 40 7f 40 00 40 00 40 00 40 00 40 00 40 00 40 15 40 00 40 00 40 00 40 19 40 1e 40 06 40 00 40 01 40 00 40 7f 40 00 40 5f 40 00 40 3f 40 07 40 00 40 00 40 00 40 00 40 01 40 00 40 00 40 00 40 00 40 28 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 00 00 00 00 40 00 40 7f f7]
00:40:41.457: Out M Wavetable Synthesizer Sysex [f0 3e 30 7f 74 00 04 00 f7]

[christofmuc]

The upper message I guess is the result of the auto detection? This is an edi buffer dump.

Are you sure you ran the new version? It still used the 0x7f as device ID, while the device ID (the fourth byte) is 0, as seen from the edit buffer response.

[christofmuc]

Oh, I just found this comment in Edisyn:

// The M's patch dumps have slots to indicate the patch and number but unfortunately they
// do not populate these slots. Maybe we can get that to change. In the meantime, we
// set the bank and number here.

That explains it, KnobKraft is waiting for a message that returns a non-zero bank.

Here is a new version, simplified, that only uses edit buffers. We need to figure out bank switches, but for the first bank this should produce something:

Waldorf_M_V4.zip

[christofmuc]

Oh, and when the MRCC is wrongly detected, that means the Waldorf M is too slow. We can increase the wait time for the auto detection to work.

[RadekPilich]

STATUS:
Well done, now it pulls the active bank to whatever bank in KK I try to download.
I forgot to mention, that auto-detection works only when forced from setup, never on start-up.

ISSUE:
It does some hiccup though - it pulls currently active patch and stores it as first patch in KK (because 0 always means current patch for M).
Therefore all the other patches are shifted by 1 and consequently eight patch in KK is seventh patch on synth and it's program change changes to patch 9 on M.
Patch numbering on GUI is 1-128.

CHANGE:
Please remove the +1 from bank name, so it starts from Bank 0, which is how it is on the GUI on M.
To load into edit buffer only without saving, new_message[34] = 0x01 needs to be added to convertToEditBuffer.

[RadekPilich]

Regarding bank switches, edisyn states, that bank numbering starts from 1 (again, 0 is current bank).

[christofmuc]

STATUS: Well done, now it pulls the active bank to whatever bank in KK I try to download. I forgot to mention, that auto-detection works only when forced from setup, never on start-up.

Startup is the "quick detect" which only checks the stored channel. It probably doesn't work because of the timing thing, let's try with a larger timeout. In the new version attached I set the timeout to 1 second, it was 200 ms before.

ISSUE: It does some hiccup though - it pulls currently active patch and stores it as first patch in KK (because 0 always means current patch for M). Therefore all the other patches are shifted by 1 and consequently eight patch in KK is seventh patch on synth and it's
program change changes to patch 9 on M. Patch numbering on GUI is 1-128.

Uuh. They are weird. So basically program 0 is the edit buffer, and the first patch position is called #1? The edit buffer logic assumes there is a program #0, I have to think on how to trick that.

CHANGE: Please remove the +1 from bank name, so it starts from Bank 0, which is how it is on the GUI on M. To load into edit buffer only without saving, new_message[34] = 0x01 needs to be added to convertToEditBuffer.

The bank+1 from Edisyn we also have, this is to address the bank in the synth. Display can be an arbitrary string calculated from the bank number. KnobKraft internally starts always with patch #0 and upwards, and banks are just intervals on all patches, so bank 0 is 0-127, bank 1 is 128-255. and so forth.

new_message[34] = 0x01 well spotted, that's a particular thing.

Waldorf_M_V5.zip

[RadekPilich]

Wow, you did it @christofmuc !

Quick-detect works.

Bank dump now also works correctly, including populating correct slots and program change working fine. It even pulls out the select inactive bank!

I knew it should have to do something with the patchNo, but I didn't figure out I have to add the createProgramDumpRequest rather then somehow edit the convertToProgramDump. What's the difference between patchNo and program_number anyways?

This is good for release in my opinion at least in the beta status.

Thanks a lot!

So the only thing not working is bank changes, only program changes work at the moment.

Btw. Bank changes sent from MasterKeyboard work. Only those from librarian don't.

EDIT: I've tried importing multiple banks in one go for the first time ever. It created a bulk import with all the patches, but didn't populate the IN SYNTH banks, so that I have to reload them. Is that correct behavior?

[christofmuc]

Awesome, work paying off is always satisfying!

The difference is only that when only edit buffer requests are defined, the Orm sends on its own program changes and then tries to retrieve the current patch. When program request is defined, you have the chance to modify request.

The internal program numbers always start at 0 and just increment upwards beyond the banks, you have to calculate the synths interpretation of that number in create program dump request.

The main error we made in the first version was to expect the program dumps to identify themselves in byte 32 and 33 - they don't, so effectively we always get edit buffers back, even when we create program dump requests. A bit weird, but happy it works.

Bank changes can be implemented by an explicit function when the synth does not follow the standard MIDI bank change message. Do we know how to change bank on the M?

The issue with "get bank" and "sync bank" is historical, and there might be a quick fix I can make. I have to test it again why it doesn't populate the "In synth" bank, that might be an easy fix. I'll open a new issue to track that!

Thanks for your patience!

[RadekPilich]

Bank changes can be implemented by an explicit function when the synth does not follow the standard MIDI bank change message. Do we know how to change bank on the M?

The same way as for Summit I believe. When using Summit as master then bank changes on Summit were changing M as well. Ofcourse we need the -1 offset, Bank A on Summit was the second bank on M.

[christofmuc]

The Summit adaptation contains no special code for bank changes, so the M should use standard MIDI?

The default implementation would be

    def bankSelect(channel, bank):
        return [0xb0 | (channel & 0x0f), 32, bank]

You could try to send b0 20 01 and b0 20 02 via the MIDI log window and see if the bank changes on the synth.

[RadekPilich]

@christofmuc Yep, that default bankSelect is good enough. Works status accomplished , thanks for the collab :-)

[christofmuc]

Party on! If I wouldn't have a 3rd Wave already, I'd now be running off and get me an M! I had always lusted after one!