Patch Dump vbscript by Fozzie : questions

[Filch]

I’m going to use this post to ask specific questions about the vbscript cooked up by Fozzie for updating the ctrlr panel from a hardware patch dump. I figured a new post would be easier to find and read than posting questions on established threads created for panels.

I’m referencing information from the original post about this vbscript that can be found on msepsis’s panel post for the Waldorf Microwave XT.
[url:25khh4k7]http://ctrlr.org/viewtopic.php?f=61&t=533#p2976[/url:25khh4k7]

My questions will be for specifically tailoring this to the Waldorf Blofeld, but anyone could use this information to assist them in using it for their hardware.

Fozzie, msepsis, or anyone who can help me decipher some of this, please chime in. ” title=”Smile” />

My first question is in regards to the first part of the conversion process in the script. I’m assuming that the values in the [i:25khh4k7]strsysexIndexCC[/i:25khh4k7] string are the parameter sysex Index numbers that do have a corresponding CC assigned to them. And that the values listed in the string [i:25khh4k7]strccIndex[/i:25khh4k7] are what the CC values are for the corresponding sysex Index values in order.

Example from the script :
strsysexIndexCC = "8 9 10
strccIndex = "33 34 35

In this case, parameter sysex Index 8 is CC 33 , and sysex Index 9 is CC 34. Is this much correct? (I hope so, b/c this is the easy part :-p )

I’ve attached the sysex implementation of the Blofeld in case there were questions or references to that from someone else.

[msepsis]

hi Filch,
I’m pinging fozzie about this. Honestly from the XT manual CC 33 (Osc 1 Octave) is sysex parameter change index 1, cc34 is index 2… I think you’re on the right track but the wrong footing, still maybe this will help. You can find a pdf of the microwave XT manual out there, but hopefully fozzie will be back to you with a more solid explanation.

-Rob

Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

[msepsis]

Oh. more precisely… sysexIndex 8-11 are reserved… let me dig into this, I might be able to answer this for you.

Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

[fozzie]

Fozzie is back ” title=”Smile” />

You are right on the idea of how I convert the patch dump sysex string into CC messages (as the first part in the script). This is indeed the easy part, but obviously only works for parameters that have an assigned CC number. Luckily, the CC and sysex implementation of the MWXT is quite consistent, therefore it is possible to make these conversions. SInce the first 7 bytes in the sysex patch dump are not related to parameter values (but to manufacturer ID, model number, etc), the index begins at the 8th byte in the patch dump, takes its value and puts it in the corresponding CC message as the value byte. The real work is in getting the order of the bytes in the patch dump sysex message translated correctly into the correct CC message. I’ll have a look at the midi implementation of the blofeld later, I don’t know at this moment whether it is set up in a similar way.

After dealing with all parameters that have a CC assigned, the only way to get the other parameters to update correctly on the MWXT is to make short sysex parameter change messages. In my script, I use the same system as for the CC messages, only now it is a bit more complex since the sysex string is a 10 byte message. Since there are more than 127 parameters assigned in the MWXT sysex implementation, there is a byte in the sysex string that is 0 for parameters 0-127 and 1 for parameters 128-255. To accomodate for this, I split the sysex script part into two parts. To make the complete sysex strings, the trick was to get the index bytes sorted that ‘select’ the parameter and to couple it to the correct value byte from the patch dump (similar to the CC part to combine the right value to the right CC#).

That is all the script does, it takes all the parameter value bytes that are in the patch dump and puts them into the correct CC messages and sysex parameter changes messages. There is a 10 millisecond delay between each message to prevent a midi overflow (mox.sleep (10)), it cycles through all cc’s and sysex parameter changes in 3 for-to loops.
Hope this helps, let me know if you have more questions. I’ll have a look at the blofeld midi implementation to see if a similar setup is possible.

[fozzie]

After just a very brief glance at the blofeld sysex implementation, it looks very similar to the MWXT setup (no coincidence, I guess). There are more parameters, so more work to do, but I guess doable.

Additionally, with regard to sysex index and correct sorting of the value bytes in the patch dump sysex string, it is important to notice that the sysex index mentioned in the implementation is needed to compose the correct 10-byte sysex string (parameter change message), however, it does not translate directly into the position index# in the patch dump message, since it is offset in the patch dump message by the first 7 or 8 sysex bytes that are general ‘start of sysex’ bytes. Hope this is clear enough for Filch and msepsis to understand what the …. I’m doing in the messy script ” title=”Wink” />

[Filch]

I understand that the format for these parameters are 10 byte messages as specified by Waldorf for both the Blofeld and Microwave XT (probably most of their synths).

Is the reason you’re parsing the sysex strings into 10 byte message chunks is because CTRLR chokes on anything bigger, or because the microwaveXT hardware chokes if it gets bigger chunks too fast?

I’ve updated most of the script for Blofeld including adding a fourth part for converting parameters 256 – 383. I’ll attach it here shortly once I go over it all again to make sure my numbers are right.

–edit–
VBScript is not postable here, so I’ve attached as a notepad file

[fozzie]

"Filch":2q6cjebu wrote:

Is the reason you’re parsing the sysex strings into 10 byte message chunks is because CTRLR chokes on anything bigger, or because the microwaveXT hardware chokes if it gets bigger chunks too fast?
[/quote:2q6cjebu]

The reason is that these 10 byte sysex messages can be assigned to CTRLR knobs, which are then able to receive input from a patchdump via the parsed messages and able to send the same 10 byte messages once you start tweaking the patch via CTRLR. This is the only way (with my still limited CTRLR knowledge) that I know how to be able to update a CTRLR panel with settings from a patch on the synth AND after that being able to tweak the patch from the CTRLR panel.
I understood from atom that in the not-so-far-away future CTRLR will get the functionality to do this within CTRLR (parsing a patchdump and updating controls with the info), but afaik CTRLR now only handles short sysex strings.

[Filch]

Okay, that makes sense to me. I’m going to have to give this script a run through when I get back home and have some time.

Question about one of the lines of code in the part that converts sysex parameters coupled to CC’s:
[i:im0vq7ck]mox.OutputMidiMsg port, 176, ccIndex(i), cint("&H" & sysex(sysexIndexCC(i)))[/i:im0vq7ck]

What is [i:im0vq7ck]176[/i:im0vq7ck] referring to here?

[fozzie]

From the midiox help function:
[quote:2d3rois2]OutputMidiMsg(nPort, nStatus, nData1, nData2)

This method sends a MIDI message out all MIDI ports that are mapping the channel. The nStatus parameter is a combination of the MIDI status and channel. Data1 and Data2 values depend on the MIDI message.
[/quote:2d3rois2]

I have searched for a clear description of this ‘combination of midi status and channel’, but never found it. I remember to have found some examples that use a format of "175+midichannel#" that work. In this specific case, the 176 value specifies CC messages sent on channel 1 of the specified port (which I have made a variable that is specified separately).

[atom]

theese are 3 bytes midi messages, a CC is a:
0xbX where is X is the midi channel byte
0xb0 CC on channel 1 0xbf CC on channel 16

[fozzie]

Thanks, I’m no good with the binary / hex / decimal thing :blush:

I was always confused with the 0x.. notation, but now found out that the ‘0x’ part is just the C hex prefix :blushing_even_harder:
But anyway, functionally, as midiox wants decimal input on for the three CC bytes, the format ‘175 + value of midi channel’ is indeed the same as 0xb0-0xbf for channels 1-16.

No programming experience, I guess it shows….

[atom]

yeah you have to get used to it. i’d stick to hex where it’s possible it just get’s easier later on, most of device manuals use HEX and Decimal input is rare since it does not include bit wise splitting (or is not that obvious).

[fozzie]

Filch, I just thought of one issue with MidiOx that might be a problem in your Blofeld script. A MWXT patch dump sysex string is a little over 256 bytes long (265 or something like that), however, Midiox seems to capture only the first 256 bytes of the dump while the rest vanishes into the digital abyss. For the MWXT it is not a problem, since the last bytes in the dump are patch name information bytes that are just not captured. No functional problem.

For the Blofeld, since it has many more parameters, this could be a problem. You can check whether the problem occurs by deleting the apostrophe in line 21 before "MsgBox strSysEx". What now happens is that after each dump, a screen messagebox is shown by Midiox with the captured sysex string. You can check this output with regard to length of message, whether it ends with F7, etc.

I suspect this will be an issue for you. In the midiox help file, two approaches are described to capture long sysex strings and it is also mentioned that you could capture the rest of the string in a second variable or call of the routine, but I could not figure out how to yet (and it wasn’t a real issue for me so I didn’t try that hard). You probably should look into this… let me know if I can help.

[atom]

two things

1) you can set the MIDI OX buffers to anything larger then 256 it might help with bigger dumps.
2) LUA is already working and even at this point you can do a program request, fetch, translate and set modulator values according to values in the dump, internaly in Ctrlr for each panel, i’m just doing the first API documentation and an example panel as we speak (i think i might have something ready later today).

[fozzie]

How cool! Can’t wait!!! CTRLR just gets better and better ” title=”Smile” />
It is kind of messy to have this whole midiox thing running in the background, so if we can get rid of it….

[Filch]

Big YAY for the LUA implementation. I spent a long time converting Sysex to CC to Hex’s the last couple nights for this script. I utilized some spreadsheets, word, etc to do calculations for me. OH well!! lol

I have some nice organized spreadsheets now that will probably be useful for the LUA programming. Guess I should spend the evening studying up some LUA. ” title=”Smile” />

[Author]

Posts