{"id":156,"date":"2012-04-17T14:32:00","date_gmt":"2012-04-17T13:32:00","guid":{"rendered":"http:\/\/www.celesteh.com\/blog\/2012\/04\/17\/liveblogging-modality-modal-control-in\/"},"modified":"2015-06-19T00:23:18","modified_gmt":"2015-06-18T23:23:18","slug":"liveblogging-modality-modal-control-in","status":"publish","type":"post","link":"https:\/\/www.celesteh.com\/blog\/2012\/04\/17\/liveblogging-modality-modal-control-in\/","title":{"rendered":"LiveBlogging: Modality – modal control in SuperCollider"},"content":{"rendered":"

by many people<\/p>\n

Modality is a loose collaboration to make a toolkit to hook up controllers to SC.  Does mapping, including some complex stuff and some on-the-fly stuff.<\/p>\n

Marije spoke a bit of how they began collaborating<\/p>\n

Concept – support many devices over many protocols. Make a common interface. Easily remap.<\/p>\n

\nDevices <\/h3>\n

\nThey currently support MIDI and HID. the common interface is MKtl. Provides a system to process the data. They have templates. Templates for common ways of processing. Same interface for MKtl and MDispatch. (they may move to FRP (I don’t know what that is))<\/p>\n

Ktl quark is out of date.<\/p>\n

(I think I might be interested in contributing to this project – or at least provide templates for stuff)<\/p>\n

Different protocol have different transport mechanisms. Things very by OS. Different controllers have different semantics.<\/p>\n

A general solution is not trivial.<\/p>\n

Scaling is different on different OSes. Names of devices may have variations. MIDI has some device name issues.  real MIDI (non-usb) will not report their names, but use MIDI ports.  Similar issues will arise with OSC or SerialPort. <\/p>\n

The device description index is an identity dictionary. It’s got some NanoKontrol stuff in it. I am definitely interested in this…<\/p>\n

They’ve got some templates, but it’s still a bit vapourware.<\/p>\n

For every button or input on your device, they define what it is, where it is, etc.  This is good stuff.  You can also set the I\/O type.<\/p>\n

Device descriptions have names, specifications, platform differences, hierarchical naming (for use in pattern-matching). You can programmatically fill in the description<\/p>\n

nanoKontrol, Gamepad, DanceMat, a bunch of things.<\/p>\n

\nEvents and signals<\/h3>\n

Functional reactive processing. Events, data flow, change propogation. FRP – functional reactive programming<\/p>\n

These are functions without sideFX until you get to the output phase.<\/p>\n

In the FP Quark – functional programming Quark.<\/p>\n

Events are encoded in an event stream.  Event Source with a do method adds a side effect.  When somethng happens (is “fired”), do the do.  Only event sources can be fired.<\/p>\n

the network starts with an event source. <\/p>\n

Signals are similar but have state? You can ask for the value and change it.<\/p>\n

To create the network use combinators.<\/p>\n

inject has state internally.<\/p>\n

Dynamic Event Switching limits and event depending on a selector.  this is kind of like the gate thing in max.<\/p>\n

With Modality, every control has an elements, every element has a singal and a source. Controls have keys.<\/p>\n

You can combine values, attach stuff to knob changes. Easy to attach event streams to functions.<\/p>\n

this is complex to describe, but works intuitively in practice.  You can do deltas, accumulators, etc.<\/p>\n

\nClosing remarks<\/h3>\n

this is on github, but it not yet released.  depends on the FP quark.<\/p>\n

Needs gui replacements.  Needs a backend for OSC devices.<\/p>\n

Needs some hackin in the SC source.<\/p>\n

\nQuestions<\/h3>\n