add descs for leap motion & sensel morph

[adcxyz]

obviously, both leap motion & sensel morph have interesting new features and flexible options, so it would be great to have basic modality descs for them that are good starting points, i.e. easy to modify for custom, highly personalised uses.

[LFSaw]

this would be awesome!

(I heard @bgola might be interested in this as well...)

Assuming we're talking MIDI for sensel morph, these are the challenges:

different overlays possible

I'd simply do multiple descs, or create a combined one in case I want to switch between them

custom overlay allows for a customised layout

see above

MPE-capable

I am quite new to this so I don't know really how to handle this...

14bit cc messages

to my knowledge there is currently no device description that has an example for a 14bit cc MKtlElement. However, there's an example implementation for a 14bit cc handler here:

https://gist.github.com/carltesta/bb5065a7b92bab7673237e9cc1c9a612

sensel morph — OSC

an entirely different way of approaching the sensel morph would be to implement an osc bridge to its API, which would break out all additional elements it provides such as ellipsis size and orientation per pressure area. One could implement this following the OSC implementation in libManta combined/adapted from MorphOSC (windows only).

[adcxyz]

different overlays possible

I'd simply do multiple descs, or create a combined one in case I want to switch between them

custom overlay allows for a customised layout

better separate descs and separate MKtls that you can turn on/off as needed, simpler to maintain and understand.

see above

MPE-capable

https://github.com/ModalityTeam/Modality-toolkit/blob/master/Modality/DeviceExamples/roli.scd is a toy example of MPE by hand; MPE is quite orthogonal to Modality concepts, so ATM writing little things like roli.scd is easier. Maybe we would need special MPE classes that are easy to combine with modality - I did not have a clear idea how to do that then.

I am quite new to this so I don't know really how to handle this...

14bit cc messages

to my knowledge there is currently no device description that has an example for a 14bit cc MKtlElement. However, there's an example implementation for a 14bit cc handler here: https://gist.github.com/carltesta/bb5065a7b92bab7673237e9cc1c9a612

Modality has MIDIControl14BitHelper, but no usage example in a desc yet AFAIK

sensel morph — OSC

an entirely different way of approaching the sensel morph would be to implement an osc bridge to its API, which would break out all additional elements it provides such as ellipsis size and orientation per pressure area. One could implement this following the OSC implementation in libManta combined/adapted from MorphOSC (windows only).

yes, all for it!

[LFSaw]

started sketching an OSC interface for a morph here (well, OSC still lacking) but it is quite promising what features you get that are not available in the MIDI world, so I am currently in favour for of dropping my ambition to add a MIDI-based desc for a morph in favour to an OSC-based one. of course, a native interface in SuperCollider would be best... well... still dreaming...

[LFSaw]

A first working prototype of senselosc is ready for testing.

[bgola]

Hi!

Super nice @LFSaw ! I used another this osc interface (written in python) to send stuff from morph to SC: https://github.com/batchku/sensel-osc

It is nice but I'm not sure if it covers all what senselosc does, from the docs yours seems more complete.

But probably would still be good to have the MIDI-based desc for some of the overlays.. I used another Roli example written using OSCFunc as well with the thunder overlay, was pretty straightforward and playful.

I don't have ideas on how to integrate Modality and MPE, I'm quite new to both :) But I'm happy to study it, try things and make suggestions..

[madskjeldgaard]

Hi guys. See this PR for a bit more info on 14 bit midi cc https://github.com/ModalityTeam/Modality-toolkit/pull/381

[LFSaw]

hello again,

after writing senselosc (see above) I realised that IMHO the MKtl interface is more than cumbersome in order to navigate around an inherently multidimensional device such as the morph... I therefore implementeda dedicated Morph-class, see its Quark.

I'd be more than happy about comments and further improvements... it is a little hacky, still but certainly serves the purpose...