since I couldn’t find any option to deal with SySex data on the Morph as of now I would like to call for a feature request for this functionality in the (near) future.
Some more advanced setups in live situations rely heavily on the great possibility to send SySex back and forth.
Same goes for OSC protocoll. Any plans for including them in future updates?
Thank you for the feedback! We are working on Sysex messages and they will be included in a future update. We are looking into the OSC.
You might find this useful for sending OSC with the Morph: https://github.com/nosuchtim/MorphOsc
Thank You Alex, Thank You Tim!
I will certainly look into your git repository Tim.
Have a great day guys!
I’m getting an error trying to execute the morphosc.exe.
“The code execution cannot proceed because LibSensel.dll was not found”
Hmm, do I need special Sensel library installed prior?
Yes, you need LibSensel.dll. If you execute the installer that you find here:
it will create a c:\Program Files\Sensel\SenselLib directory with the things you need to develop and execute custom programs in C. The appropriate LibSensel.dll file (32-bit or 64-bit) needs to either be copied from there into the same directory as morphosc.exe, or (I think, I haven’t tested this) the directory containing it can be added to the PATH value.
Due to the Morph’s high resolution, etc., I am surprised that the Morph doesn’t currently support OSC. I am very glad to see that Tim Thompson has provided an OSC library for the Morph. I’ll take a look at it, but I have no experience with coding. I’ve done a fair amount of synth & app programming and was hoping that it would be a straight forward process to create a custom layout with an innovator’s overlay to send OSC messages.
To clarify your need: if you had the feature you wanted, to what device or application would you be sending the OSC messages?
Hi Tim. Reaktor6, Parat+, Aalto, and basically any sound design/synthesis software that supports OSC. If I can afford it, later this summer I’m hoping to purchase the Instruo Aither eurorack module to send OSC from Parat+ to eurorack CV.
To add to this request, my OSC needs revolve around sound, video, and also lighting control – the higher-end lighting consoles and software speak OSC and benefit from higher-than-MIDI resolutions as well as not needing many go-between applications. MaxMSP/MaxForLive (the ‘official’ max object’s refresh rate and accuracy doesn’t cut it), Reaktor6, VDMX/Resolume, QLab, etc… Having OSC would finally take advantage of the Sensel’s resolution & sensitivity in ways that I’m struggling with now.
To guide the development of an OSC feature, it would help to identify the specific product you would most want to control, or, lacking that, specific examples of the kind of OSC messages you want to send, and how a particular slider/button/area would produce those messages. The current MorphOsc utility I’ve put on github doesn’t require any programming, but it does require some editing of a JSON file that specifies the OSC message format. If you look at that, it would be useful for you to identify particular OSC messages that can’t be specified with that mechanism.
When looking at the MorphOsc utility, don’t worry about the (in)flexibility of it’s ability to handle different areas of the pad - just look at the mechanism for specifying OSC messages, and let me know if that mechanism is sufficient for your needs.
Thank you so much, Tim – the JSON format for specifying the OSC commands is quite good for my uses. What I’m looking for is the ability to set a specific path with a scaling range (not always 0. to 1.); sometimes it’s a fader, dial or pressure pad, sometimes it’s a one-shot keystroke or encoder inc/dec, etc.
Since I’m sometimes building custom ‘keypad’ interfaces for some lighting consoles, here’s what the ETC Eos lighting consoles are looking for when communicating over OSC, by way of example: https://github.com/ETCLabs/EosSyncLib/blob/master/Supported%20OSC%20Commands.pdf
I’ve attached two overlay designer pics for the M-Series (programmer keypad) and ETC Eos (parameter wheels), hope you can see them. I’m having issues getting all the commands to work over MIDI or keystrokes how I’d like them to, and being able to specify the exact OSC strings would be a great help.
Ideally this would all be part of the overlay designer someday. Of lesser importance (for me) might be OSC text strings, LED feedback (if ever possible) and multiple destinations/ports.
Cool, so it sounds like a OSC string along with min and max values of the transmitted values will be mostly sufficient for you, then. This assumes that all of the receiving applications are driven by single-argument OSC messages, at least for the primary value of a slider or button, as well as (perhaps) the pressure. Sending x and y for areas would be a 2-argument OSC message. It would be easy to modify my MorphOsc utility to specify the min/max values, but MorphOsc assumes the entire pad is a single area, while most uses (i.e. your uses) need the ability to specify sub-regions of the pad (i.e. what the overlay designer does). If the overlay designer exported a documented/extensible format (it currently doesn’t), it would be possible for me to enhance the MorphOsc utility to read a *.senselmap file and do what you want. I think I’ve suggested this elsewhere, but this is a perfect example of the value of documenting and choosing an extensible format for files like *.senselmap
Thanks for the feedback! From the Sensel side, the following might answer a few questions:
- If you need higher resolution, you may want to consider 14 bit CC MIDI, which is an option on MPE and XYZ MIDI Pad. This should give you access to 14 bit CC values for X, Y, and Pressure.
- We agree that the .senselmap should be documented and open format. We will make sure to keep everyone updated as we solidify the format.
- As for OSC on the Morph, we don’t have any further updates at this time but we understand that it is a priority for some customers. We appreciate the feedback to help make it a higher priority.