Add a device for keyboard input

[jcelerier]

Let's devise the API here. I'd propose something like

# message sent when a key is pressed
/press 'A'
# message sent when a key is released
/release 'A'
# an array of everything currently pressed, in the order in which they were pressed
/keys ['ctrl', 'A', 'shift']
# maybe useful ones for the modifiers ? 
/ctrl
/alt
/shift
...

[bltzr]

How would the modifiers messages work, then? Wouldn't we need press and release?

[jcelerier]

you'd get a press & release when they are pressed, but you could also go check their state with /ctrl directly

e.g. if you press ctrl, shift, A in order you get:

/press 'CTRL'
/ctrl true
/keys ['CTRL']

/press 'SHIFT'
/shift true
/keys ['CTRL', 'SHIFT']

/press 'A'
/A true
/keys ['CTRL', 'SHIFT', 'A']

this is mainly to allow both the case where one wants to react to a key being pressed to trigger something (e.g. a trigger with a /press == 'A' condition), and the case where you want to check whether something is pressed when you reach a point in the timeline (e.g. for a condition, you'd check /a == true)

[thibaudk]

Thinking of it from the point of view of score I was wondering how this would interfere with keyboard shortcuts ?

I was wondering if access to keys (and mouth) could be, rather than a full "Device", a subset of the mapper device, in the same way "Timer" would be ?

Maybe "Timer" is a complete device now, but in any case, if all keyboard shortcuts where defined in a mapper device, it would also allow to completely edit, customize and overite them.

This mapper device would be hidden by default, but adding it in the Device explorer would show it.

Accessible as objects in the mapper, the actual parameter tree would be completely customizable, and there would be less of a need to draw up and implement it's API (other than in QML).

Just some thoughts.

[jcelerier]

Thinking of it from the point of view of score I was wondering how this would interfere with keyboard shortcuts ?

So, what would be the simplest would be to leverage the "Window" device for that - we could say that this device also exposes mouse / keyboard inputs when the user focuses that window. What do you think ?

On Wed, Nov 18, 2020 at 4:10 PM Thibaud Keller [email protected] wrote:

Thinking of it from the point of view of score I was wondering how this would interfere with keyboard shortcuts ?

I was wondering if access to keys (and mouth) could be, rather than a full "Device", a subset of the mapper device, in the same way "Timer" https://github.com/ossia/score-user-library/commit/084c7df3ac1fd4bc854fcecdc6f91f0106a5fb39 would be ?

Maybe "Timer" is a complete device now, but in any case, if all keyboard shortcuts where defined in a mapper device, it would also allow to completely edit, customize and overite them.

This mapper device would be hidden by default, but adding it in the Device explorer would show it.

Accessible as objects in the mapper, the actual parameter tree would be completely customizable, and there would be less of a need to draw up and implement it's API (other than in QML).

Just some thoughts.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ossia/libossia/issues/587#issuecomment-729742636, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVE56WEXG337244HJTB2YLSQPPWPANCNFSM4R54WKSA .

[thibaudk]

Well actually, the demands I had personally for the use of the keys where coming from composers mainly used to tapping away on the space bar in max to go to the next preset.

They wouldn't have any use for the window. I see your point tho about focusing on another interface than score as to disable the shortcuts.

here is an example of what I would imagine the end result be :

Ossia.Mapper
{    
    function onKeyDown(keys) {

        if (keys.space)
        {
            return [ { address: "/Keyboard/space" } ];  
        }
        
        if (keys.enter)
        {   
            return [ { address: "/Keyboard/enter" } ];  
        }   
    }

    function createTree() {
        return [
        {
            name: "Keyboard",
            children: [
                {
                    name: "space",
                    type: Ossia.Type.Pulse,
                    write: function() { score.play(!score.running); }
                },
                {
                    name: "enter",
                    type: Ossia.Type.Pulse,
                    write: function() { if (score.running) { score.stop; }; }
                }
            ]
        }
        ];
    }
}

This would make it very easy to free the default behavior of the space bar and apply it to anything. It would also make it very direct to bind it to another event, like a MIDI message, to start the scenario on pressing the play button of a controller.

Score skins are already available in the user library. Moving keyboard shortcuts to the mapper, and this mapper to the user library would enable in the same way it's customization and "free exchange".