[fozzie]

Maybe I can join in the confusion ” title=”Wink” />

Msepsis, I think what atom means by the indexing of the modulators to get proper values assigned to them is in essence the same activity I have done with my Midiox script, you use the position / index of a value in the long sysex message to link that to the proper controller. I’m guessing you can set that up in combination with assigning short cc or sysex messages to the knobs (as is the case in the MWXT panel). Whether you then parse the long sysex into the short messages or make some array to redirect/parse the long sysex-derived values to the correct knobs using an array or table is about the same amount of work. If this whole scripting is independent from the short sysex / cc message functionality that is already present, you can still turn a knob on your synth and also have your panel update directly.

What is not clear to me yet is how you can take/parse values out of a midi message and assign that to one of the modulators to update its value, but I guess that is what we should use the getModulatorByName() and getModulatorByIndex() methods for? Is that right atom?

[fozzie]

Nice, thank you once again for all the coolness ” title=”Smile” />

I have taken a look at the LUA midi-receive panel example and kind of get the idea, but I’m not really familiar with the object oriented side of programming and corresponding syntax. Would anyone be willing to write an example on how (a) received value(s) could be assigned to one specific modulator that is present in the panel? That would help me in understanding LUA syntaxis. I would like to work on parsing a complex incoming sysex to update the MWXT panel without needing a midiox-script, but am not sure where/how to begin… I don’t mean to be demanding anything here, it would just be cool if someone could help, otherwise it will probably just take me a little longer to figure things out, which is no problem either.

[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….

[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.

[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….

[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).

[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.

[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” />

[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]

"lilakmonoke":10q3qr7v wrote:

if that works i would love to do one for the microwave v2.0 the king of wavetables. thats a different beast all together.[/quote:10q3qr7v]
If you mean a microwave II, that should be identical on the midi level to the microwave XT, for which msepsis has made an excellent panel already….

[fozzie]

Making such a script is not really hard, figuring out the CC and sysex details of ~240 parameters is larger part of the work. I have no real coding experience, but was able to hack it together with some trial and error.
Still, if you’re not in a hurry, it is probably easier to wait for the LUA implementation…

[fozzie]

very cool

Thanks for making CTRLR and all this cool stuff happening!!

[fozzie]

The vbscript receives a large sysex patchdump, takes out the separate parameter values (props for waldorf for their thorough sysex format & description) and transplants the value bytes into corresponding CC messages or (for parameters that have not been assigned to CC by Waldorf) into short 10 byte sysex parameter change messages. Since the CC and short sysex messages are handled by CTRLR, the script enables updating all controls in a panel from sending a single patch dump sysex message.

If CTRLR will be able to receive long sysex message and use the separate bytes in there to ‘feed’ CC or short sysex messages, the script will not be necessary any more.

[fozzie]

"msepsis":2o87t78n wrote:

but yeah i hope you don’t mind if i take what you posted there and work from there? I think this is awesome collaborative work that’s pretty damn fun to no end.
[/quote:2o87t78n]

Please do so. I like this kind of DIY collaborations and am happy to contribute. I take the liberty to modify things to my own liking so please do the same! We can discuss and enhance each other’s ideas, but I also don’t mind to do some tweaking to make ik to my own liking if we have different preferences.

I am excited that the script works on your XP setup! Cool, isn’t it, watching all the parameters update

[fozzie]

With regard to the layout, I started with the mod matrix on the right side, but thought it was a bit unbalanced in connection to your current layout. Also, I thought this gave a better overview of the parameters.

The screen I work on with my DAW is a large one, so I don’t need to scroll at all, can even zoom in and still see everything. Personally, I don’t need much screen real estate for a virtual keyboard, or modwheel/breatch/foot controllers. Still, if I need to scroll, I personally prefer to go up/down.

It’s really unfortunate that the script doesn’t work. On my setup, it updates all parameters in the patch sequentially (I inserted 10millisec delays between separate cc and sysex messages to avoid a midi overload) and works really nice. I have started synthesis with a Nord modular, and ever since I have a need to have a graphical overview of how a patch is set up. This panel works very well in that respect, so thanks again for your work. If I can be of help in the midiox problem, let me know. I think the messagebox thing could help to see where the problem in midiox lies.

[fozzie]

Not sure if it is useful to anyone but me, but here is a version of the panel of msepsis with the addition of the modmatrix and a few extra parameters. I have made the layout worse, so apologies for that. I want to have the complete patch overview for myself, that’s why I added the stuff, layout is less important to me right now.

[fozzie]

"msepsis":2ur310zm wrote:

+1 for this idea,
I put in a feature request this weekend that was very similar, double click to turn visibility of the value box on if you have it hidden ..we know some of these panels could have 200+ sliders/knobs, kinda cluttered with all values displayed all of the time.
[/quote:2ur310zm]
I really like this one, too. I am starting the same struggle you have been through for some time probably, to fit all controls in a small screen with optimal control. Double clicking to enter a precise value / showing the value would be a very nice functionality!

[fozzie]

I think I read somewhere around here that you use Win7 64 bit, msepsis. If that is the case, you should try out whether loopbe1 or loopbe30 virtual midi cables work, there seem to be issues with the old familiar ones (midi yoke, etc) and 64 bit OS’s.

[fozzie]

Argh, just typed in a lenghty reply and then it got lost on submitting the message

Anyhow, I have attached / linked to a zip file containing a screenshot of my setup. It shows the midi setting of my MWPC software editor (which does not work well, hence the CTRLR activity), the midiox setup plus input/output after running a sysex patch dump into the script, and my CTRLR setup.
My scheme with midi yoke channels is a bit complex since my MWPC output has to go into a virtual midi cable, and I mix in a usb keyboard controller as well just before going to the MWPC Midi1 output, which leads back into the hardware PC module. One important thing is to have the Midiox event port connected to the virtual midi cable that is coupled to the CTRLR input (out to midi yoke 1 in my case). This event port is the source of the processed cc and short sysex messages, so that needs to be in place.

My setup is on 32 bit xp, midiox 7.0.0.365 and CTRLR build 504.

If it still doesn’t work, change line 21 of the script by deleting the apostrophe (‘) before MsgBox strSysEx. If you delete it, midiox will show the captured sysex patch dump in a screen message (click ‘ok’ to get rid of the message and continue the script). It should show a 256 byte message (the end of the message is not captured due to a limitation in sysex capture size, but this gives no problem since the last bytes only deal with patch name). On an older system I had problems years back that Midiox would only capture the last part of a message that is larger than 256 bytes. If this is the case, the problem is clear but I don’t know if it can be solved ” title=”Confused” />

Still, I hope it works for you with this info. Let me know.

[url:34kgcsoy]http://www.mediafire.com/?1utzb8w4ssodwjp[/url:34kgcsoy]
This URL links to a mediafire hosted zip file containing a png screen shot of the setup, the vbscript file that works for me and a horribly edited version of your 1.98 panel that contains the entire mod matrix but not at all matched to your layout, so just for reference / information.

[fozzie]

Hmm, I don’t know what is going wrong in your setup. In my case, the panel updates correctly now, even the sysex knobs.

In the midiox output monitor, do you see a long list of cc messages followed by a very long list of 10-byte sysex messages? If not, there is something going wrong in the midiox part before getting into CTRLR.

The ‘press OK to end midi loop’ should not be pressed, it is the way to end the script when all conversions are done. I guess that’s not really clear but a legacy from the midiox script example that I based the script on.

I’ll try to make some snapshots of my setup in Midiox and CTRLR, to clarify. One thing could be important as well: my setup is on an XP 32 bit computer. I have read that 64 bit OS have issues with midiox and virtual midi channels.

[Author]

Posts