Modality-toolkit icon indicating copy to clipboard operation
Modality-toolkit copied to clipboard

how best to handle keyboard views - octave transposition?

Open adcxyz opened this issue 7 years ago • 3 comments

Currently, most desc files of MIDI keyboard device create guis where all reachable keys are shown, e.g. for a nanokey, keys 0-120. this is useful to get to all keys, but eats lots of gui space.

One option would be creating a KeysView class that knows to display say 25 keys, plus a gui element for octave transposition - then one can reach all keys if needed, and by default, the guis shows only the physical keys and their default note values.

// Notation in desc file could be: 
(
// ...
elements: [
	(
		key: \pkey, 
		style: (guiGroup: \keysView, numKeys: 25, defaultLowest: 48, octaves: (-3..3)),
		shared: (groupType: \noteOnOff),
		elements: (0..120).collect { |num|
			(midiNum: num)
		}
	)
]
)

adcxyz avatar Nov 13 '16 13:11 adcxyz

Sounds good to me. I was wondering how much we need to follow the geometry of the H/W devices... maybe it is just enough to give hints on available real-estate (row/column/width/height) and let the gui figure out by itself, how much it should show?

LFSaw avatar Apr 23 '17 10:04 LFSaw

We could simply go by how many physical keys the device really has, and do octave transposition based on that, like paging. Actually, if one can define an element to be in any subset of all pages, that could be done rather easily: Keys 24-49 could be in page0, 36-61 in page1, 48-73 in page2 etc.

adcxyz avatar Jul 08 '17 09:07 adcxyz

An alternative would be to show only mas 2 ocatves (more are really difficult to handle screen-real-estate-wise). IMHO, there's no point of showing 80 keys, even if that master keyboard of yours has them.

LFSaw avatar Jul 12 '17 06:07 LFSaw