Need help with KeyKit widget UI programming
Jason Cunliffe
I want to model an instrument in Keykit. To serve later I hope as as
MIDI controller, display and programmable 'home' for a physical MIDI
device/insutrment I am designing. I need some help please getting
started in KeyKit UI widget programming.
My Instrument design calls for a regular array or clusters of circular
buttons [KEYS] populating a grid. Each KEY should be responsive to all
the usual mouse events, as well as MIDI and script-based events.
- How to do onMouseOver, onMouseDown, on MouseUp events for a circular
widget in KeyKIt ?
- How to make these buttons easy to "pull off" like KeyKit's lovely
menus ?
- How to color circlar widgets with OFF, OVER, DOWN, HIT states ?
- How to display text in labels when mouse moves over/out
- How to trigger MIDI events when user clicks down adn off?
etc
I'm used to Flash - Actionscript programming where all that is very
easy.
Just looking for some guidleines to get started on this - wher to look
in KeyKit code for basic creation of circular buttons to which I can
how to freely assign functions and event listeners to these objects or
groups of them.
From just the GUI point of view I could build mockup nice in Flash
[Actionscript]. But MIDI is extremely limited.
Else using MAX/MSP/Jitter [expensive] or PD [PureData], its free
opensource sibling.
But I love KeyKit, its design philospohy, scale, features and cross
platform minimalism [++the price is right].
Thanks for KeyKit and for any help
Jason
Tony
indeed Keykit's design philosophy in unbeatable, especially if you use touch
surfaces or tablets. Back to your problem, for such differentiation I would
recommend using AutoHotkey (in Windows XP) where you have much detailed
control about the interaction between a human's hand and pc keyboard or pc
mouse.
Then the only remaining problem to be solved would be how fast it can be
made to transmit command line commands from the external world of Keykit,
like from AutoHotkey, to Keykit which is run in GUI-mode ( starting key.exe
rather than lowkey.exe ).
If you would be satisfied with the possible transmit time optimizations for
your application area/field then you could build your control GUI even
directly in AutoHotkey, meaning externally to Keykit. Using python and QT
might be another option.
Have you any more information about your instruments functionality, will it
be a midi controller only or having also a sequencer with midi generation,
manipulation and recording and of course also control/triggering
capabilities? Circular buttons sounds a little like genoQs Octopus which are
a quite high price you have to pay for a set of LED's and buttons with some
kind of intelligent behaviour behind them.
Keykit is the best tool to add midi intelligence to any hardware midi system
I would say.
Kind regards,
Tony
> My Instrument design calls for a regular array or clusters
> of circular buttons [KEYS] populating a grid. Each KEY
> should be responsive to all the usual mouse events, as well
> as MIDI and script-based events.
> - How to do onMouseOver, onMouseDown, on MouseUp events for
> a circular widget in KeyKIt ?
> - How to make these buttons easy to "pull off" like KeyKit's
> lovely menus ?
> - How to color circlar widgets with OFF, OVER, DOWN, HIT states ?
> - How to display text in labels when mouse moves over/out
> - How to trigger MIDI events when user clicks down adn off?
> etc
>
>
Tim Thompson
I'm a big fan of Actionscript 3.
> Just looking for some guidleines to get started on this
My recommendation would be to create your interface in Flash, and use a socket (TCP) to connect to keykit to do any MIDI I/O and
realtime scheduling. This leverages your (and Flash's) strength, as well as keykit's, and is much more adaptable in the future. No
need to use HTTP, just keep a TCP socket open (or two sockets, if you want things going in both directions) and have a client always
waiting to receive things, to reduce latency. If you want really-low latency from human input, I recommend a hardware controller,
not a mouse.
If you still want to do keykit widget programming, I can only recommend that you start digging into the code of existing GUI tools,
starting with the simpler ones. There are no circular widgets.
...Tim...
Tony
communication between Keykit and its external world, in my case that
would be AutoHotkey. My goal is to handle all pc keyboard inputs with
AutoHotkey, rather than with Keykit as AutoHotkey has much more power
for various combinations, timewise, multiple presses, momentary
buttons behaviour and even complete keyboard mappings... unlimited
possibilities.
I would like to use following information structure:
pc keyboard input --> AutoHotkey --> generation of keykit
'phrases' as text strings --> sending those 'phrase strings' via TCP
socket to Keykit --> further midi processing in Keykit --> output
from Keykit as midi via one of the available midi ports
So all together we could convert in real-time pc keyboard input events
to midi events or midi event sets.
Any starting helper tips would be great! Thanks in advance.
> My recommendation would be to create your interface in Flash, and use a socket (TCP) to connect to keykit to do any MIDI I/O and
> realtime scheduling. This leverages your (and Flash's) strength, as well as keykit's, and is much more adaptable in the future. No
> need to use HTTP, just keep a TCP socket open (or two sockets, if you want things going in both directions) and have a client always
> waiting to receive things, to reduce latency. If you want really-low latency from human input, I recommend a hardware controller,
> not a mouse.
midi controller?
...Tony...
Tim Thompson
> communication between Keykit and its external world,
See lib/sock.k - there are several examples there. For listening for
TCP connections, try this - in keykit, execute "test_listen(8888)".
In another (shell or cmd) window, use telnet to connect to it with
"telnet 127.0.0.1 8888". Any lines you then type in the telnet
connection should be seen and printed by the keykit code in
test_listen().
...Tim...
Tony
I tried telnet and it seems to work. Later I can try to find out how I can
avoid a "visible telnet window" sending somehow the same information to
keykit without having to see any telnet window. But this is another problem
and story.
I am interested in the limitations to the 'phrases' we can send using this
method? How long or better how short should each chunk of 'phrase' be? Does
the function realtime(ph) have any limitations? I tried a longer 'phrase'
and it did not play correctly, it played it very fastly, bbrrrrrrrip. Could
the reason be in the telnet application or in the communication type, is
udp_listen better than tcpip_listen if I only want to send pc keyboard key
triggered 'phrases' to Keykit without needing any feedback back from Keykit.
At least for shorter phrases it seems to work properly, it would be only
nice to know the limitations, not to come too close to them, while
experimenting with the real-time side of Keykit. This method is btw. also
adding midi-output functionality to AutoHotkey indirectly, meaning with the
help of Keykit, the following clarifies why:
a) Pc keyboard --> AutoHotkey --> Midi-Out is NOT
possible in 2009
b) Pc keyboard --> AutoHotkey --> Telnet --> Keykit --> Midi-Out
IS possible, which is great! Now we can build the most complex pc keyboard
midi control devices for our sequencers or vst-hosts. For me a pc keyboard
is not a single unit when used in that way, I am differentiating it's
following components:
1. QWERTY 4 x 10 matrix, meaning 1..0 and three more rows below that
2. F1..F12 area
3. Escape key
4. Print/Roll/Pause keys
5. Insert/Delete/Home/End/PgUp/PgDown keys
6. Arrow keys
7. Rest of the QWERTY area keys, in my case, left control, left win, left
alt, space, right alt, right win, right control, left shift, right shift,
Caps Lock, Tab, °^, six more button on the right side, menue button, enter,
backspace.
8. Numpad area
Thanks to AutoHotkeys power we can give those regions specific "hierarchical
meanings" and use multiple keypresses with momentary behaviour mainly on the
4 x 10 QWERTY matrix area. Such a simple pc keyboard can get a real power
midi output machine when used in this way. We only need to forget for a
moment what a "normal pc keyboard" does or should do. Especially when
combined with a pc keyboard where each key can get ist own "freely
programmable" color, like here http://www.luxeed.com/shopping_01_e.php . I
just do not know yet how freely and dynamically we could program the colors
for the keys using this keyboard and AutoHotkey.
Kind regards,
Tony
> Subject: [keykit] Re: Need help with KeyKit widget UI programming
Tim Thompson
this
> method? How long or better how short should each chunk of 'phrase' be?
Does
> the function realtime(ph) have any limitations? I tried a longer 'phrase'
> and it did not play correctly, it played it very fastly, bbrrrrrrrip.
Could
> the reason be in the telnet application or in the communication type, is
> udp_listen better than tcpip_listen if I only want to send pc keyboard
key
> triggered 'phrases' to Keykit without needing any feedback back from
Keykit.
implementation.
I just successfully sent a 500-note phrase over TCP between two instances of
keykit,
as a single line of over 6000 characters. Your bbrrrrip (assuming it
contained all the
notes you wanted to be played) is probably related to the way the
phrase is written, not any length limitations. If you provide more specific
details
with a specific example, I can help further. You don't want to use UDP.
...Tim...
Tony
which seems not to work properly. In the Keykit Library Functions I could
find:
readkey(filename)
This function reads a phrase from the specified file, which is is expected
to contain a phrase in KeyKit format, i.e. the same as a phrase constant in
the KeyKit language.
readkey uses the internal built-in function readphr().
Do we have also the counterpart for that, like writekey(filename)? I found
writephr(ph,fname) which uses
put(f,sprintf("%p\n",ph))
but in the Keykit Language Reference we see another implementation
put(f,string(ph))
At least the writephr(ph,fname) implementation in util1.k does not create a
one line string, but adds many \n.
...Tony...
Tony
I communicated with an AutoHotkey forum "guru coder", majkinetor, and here
is what he wrote to me:
"
I think there are much easier solutions then using tcp for communications.
You could convince him to implement the same interface via interprocess
communication using WM_COPYDATA. TCP is usually used with music to allow
server and client to remain on separate machines. If you want to be able to
control the program on single machine, mentioned IPC would be much easier to
use.
Implementing such thing is trivial, especially as there is already TCP
interface in place.
"
What do you think Tim? Here I am writing majkinetor is a guru coder, and to
majkinetor I write, Tim Thompson is a guru coder, hehe :)
We can not thank you enough Tim for your bombastic Keykit. Who needs pd and
MaxMsp for midi stuff if there is Keykit?
...Tony...
Tim Thompson
> communication using WM_COPYDATA.
mdep("clipboard","get") and mdep("clipboard","set","valueyouwanttoset").
I don't know if there's length limitations in that interface.
...Tim...
Tony
how will Keykit know when the clipboard content has changed and react
accordingly? How would you do it? I am interested in mdep("clipboard","get")
whenever the clipboard content will change, as I would like to fill into the
Clipboard always via AutoHotkey, never via Keykit, thus I would not use the
set method for now.
A minimal example of how Keykit can observe/watch/listen permanently for any
clipboard content changes would be great. At least listening for any
clipboard changes which are 'keykit phrases'. Whenever it detects a change
it should play it using realtime, as in the case of test_listen(port):
p = phrase(d)
realtime(p)
...Tony...