modalityteam / modality-toolkit Goto Github PK

Any of you would like to talk to the RME hardware?
here's the latest OSC table for controlling RME´s TotalMix FX.

http://www.rme-audio.de/forum/viewtopic.php?id=17232

@miguel-negrao, I assigned this to you since you know best about the methods... I offer my help, though.

make a controller paged via software

FRP version:
https://github.com/miguel-negrao/FPLib/blob/master/Examples/FRP/soft%20paging.scd

These helpfiles are out of date:

• FuncChain.schelp
• MDispatch.schelp
• MKtl.schelp
• MKtlElement.schelp
• PKtl.schelp
• String.ext.schelp

Some helpfiles are for classes that don't exist

• MBasicElement.schelp -> MAbstractElement.schelp

elementAt(\kn,0,1)

just make into a string

move an action from one control to another

If so, I'd vote for accounting for it, since it then forwards the same structure as in the lower level implementation

MIDIMKtl('sprc0', 8454149, 8454144); // SuperCollider
MIDIMKtl('cncn2000', 1310720, 1310720); // iCON iControls V2.00
MIDIMKtl('mdth0', 917504, 917504); // Midi Through
MIDIMKtl('cncn2001', 1310721, nil); // iCON iControls V2.00
MIDIMKtl('sprc1', 8454150, 8454145); // SuperCollider
MIDIMKtl('syst0', 0, nil); // System
MIDIMKtl('syst1', 1, nil); // System

icon iControls appears has two devices. Possibly midi out is on the second one... have to investigate

it seems there is still an issue setting output elements with odd bitsizes. This needs a reverse implementation of the input byte parsing.

This should be a folder in the user's home in which she can put custom desc.scd files.
Files in this folder possibly overwrite files in the generic folder.
If an overwrite happens, the system should warn about it.
Should be accessible by a method similar to Meta_MKtl:deviceDescriptionFolder

Could be either a graphical display or just a listing like

sl_[0-9]_[0-9]
bu_[0-9]_[0-9]
bd_[0-9]_[0-9]
kn_[0-9]_[0-9]

ask a HID device and get something where you have to fill in the names.

If flat, we need a way to go from JSON-flat back to sc-hierarchical;
If hierarchical - which seems better - we need a way to notate the hierarchy
with just arrays and dicts.

The MPD18 has 16 Buttons and a slider.

• [Sound Buttons] Buttons 1-3 are mapped to adsr enveloped sound sources.
  • By pushing them down sound turns on; releasing: sound off.
• the Slider sets amplitude (or pitch) for the (sound)source of the currently depressed button.
• [Memory Slots] Buttons 5-16 represent 'memory' positions (initially not mapped)
  • if sound is assigned (see below), sound is played when button depressed.
• [Shift Button] Button 4 is a 'shift key'. When depressed
  1. Sound Buttons don't trigger any sound but select the active slot. This can be followed by
  2. depressing a Memory Slot button, which assigns the selected sound to that pad.
  3. if you release the shift key before assignment, nothing happens.
  4. assigning a copy to an already assigned memory slot replaces existing
  5. mute copy
     +[Sound Button then Shift button]
  6. Sound Button triggers sound
  7. depress Memory Slot button, assigning the sound to the pad, with sound

Variant

• Several (up to three) sound buttons can be assigned to a memory slot
• slider informs all sounds assigned to a memory slot

Further Variation

• include velocity and aftertouch from pads
• press shift button then memory slot (w/o pressing sound button) clears memory
• play sound using 2 to 4 dim fan out w/ aftertouch and slider
  • slider no longer applies to amplitude
  • velocity to amplitude
• button then shift.
  • shift starts to record control data from aftertouch
  • release shift to stop recording.
  • aftertouch recording (looped) is applied to that source for some param
  • double click shift key then sound source to remove recorded source param

Where should it be documented?

Regardless of whether the Functional Programming Quark is installed or not, the Modality Toolkit invoke HideVar, a class provided by the FP quark, in the class MKtlElement

symbol lookups are as fast as lookups by combined numbers,
and faster than using lots of MIDIFuncs.
so we stay with a flat elementsDict for very fast lookups.

The MPD18 has 16 Buttons and a slider.

• [Sound Buttons] Buttons 1-3 are mapped to adsr enveloped sound sources.
  • By pushing them down sound turns on; releasing: sound off.
• the Slider sets amplitude (or pitch) for the (sound)source of the currently depressed button.
• [Memory Slots] Buttons 5-16 represent 'memory' positions (initially not mapped)
  • if sound is assigned (see below), sound is played when button depressed.
• [Shift Button] Button 4 is a 'shift key'. When depressed
  1. Sound Buttons don't trigger any sound but select the active slot. This can be followed by
  2. depressing a Memory Slot button, which assigns the selected sound to that pad.
  3. if you release the shift key before assignment, nothing happens.
  4. assigning a copy to an already assigned memory slot replaces existing

Variant

• Several (up to three) sound buttons can be assigned to a memory slot
• slider informs all sounds assigned to a memory slot

Further Variation

• include velocity and aftertouch from pads
• press shift button then memory slot (w/o pressing sound button) clears memory
• play sound using 2 to 4 dim fan out w/ aftertouch and slider
  • slider no longer applies to amplitude
  • velocity to amplitude
• button then shift.
  • shift starts to record control data from aftertouch
  • release shift to stop recording.
  • aftertouch recording (looped) is applied to that source for some param
  • double click shift key then sound source to remove recorded source param

We agreed that we want to wait a little until merging the Bergen branch into master.
E.g. to wait until the HID implementation is tested a bit and can be merged into the official SC repository.

One should be able to pair a midi box for physical midi connections with a specific spec manually

less urgent...

e.g. Logitech Extreme 3d (but works on osx) and Logitech G13

if the same fader has different cc-numbers for in and out but physically the same thing, we should deal with it in the spec.

Writing use cases in the issue tracker marked with the label "use case" (see on the right)

Use cases should include very simple as well as more complex real-world scenarios.

• discover a device and use it as a mixer
• soft paging of controllers
• remapping of functionality

As found in SketchesNotesEtc/specFileDefinition.md

Once hid gets merged in, can we already use MKtl everywhere ?

http://modality.bek.no/