[chuck-users] KBHit events

Julien Saint-Martin julien.saintmartin at googlemail.com
Sun Dec 22 07:38:00 EST 2013


Hi Manuel,

You're welcome and I think you are close to success :-) "Sleep Button
ready" means ChucK succeeds to open a device. But it don't looks like to be
the right one.

On my side I tested your code replacing 5 by 0 in the line:
if(!hid.openKeyboard(0)) me.exit();

It works for me. Can you try the same thing? Maybe argument of openKeyboard
is not related to the event number in your system.

Cheers,
Julien




2013/12/22 Manuel Bärenz <manuel at enigmage.de>

>  Thanks a lot Julien,
>
> I'm still trying to set up the keyboard events. I found
> /dev/input/by-path/, which contains symlinks to /dev/input with sensible
> names. I guess this is what you meant. One of them is called
> "platform-i8042-serio-0-event-kbd", I assume that is the keyboard. It links
> to /dev/input/event5, so I granted access rights to the device to everyone
> and wrote the following little script:
>
> Hid hid;
> HidMsg msg;
> if(!hid.openKeyboard(5)) me.exit();
> <<< hid.name(), "ready">>>;
> while(true)
> {
>   hid => now;
>   <<< "received event" >>>;
>   while(hid.recv(msg))
>   {
>     <<< msg.ascii, " was used" >>>;
>   }
> }
>
> The output of it is, surprisingly, "Sleep Button ready", and it never
> comes to the point of "received event". Any ideas?
>
> Best, Manuel
> Am 06/12/13 09:57, schrieb Julien Saint-Martin:
>
>      Hi Manuel and Moisés,
>
>  Sorry for confusion I checked my code and I use Hid event not KBHit.
>
>  I work on linux too (Debian). And I have to modify a little my linux
> config to use KeyBoard in Chuck.
>  On linux distrubutions I tried, Chuck didn't receives Kb event by
> default. But fortunately there is a work around.
>  I am not on my linux PC now  so maybe the following is not exactly right:
>  Go to directory /dev/input and find which event corresponds to your
> keyboard (there is a directory with links name of hid but I didn't remember
> the name) . For me it is usually event0.
>  Then modify access rights to this event to give read access to everyone.
>  After that your chuck may catch keyboard events.
>
>  Once ok, Chuck works great on linux and you can use fantastic Jack server
> to connect it directly to other sound tools. So I encourage you to don't
> give up with linux :-)
>
>  have fun,
>  Julien
>
>
>
>
>
>
> 2013/12/5 Moisés Gabriel Cachay Tello <xpktro at gmail.com>
>
>> I got some problems with the linux builds also, and my final solution was
>> using wine and the windows version of miniAudicle (the windows ChucK
>> standalone also would work) and everythings just goes fine, In fact I wrote
>> and tested the above code with it :)
>>
>>
>> 2013/12/5 Manuel Bärenz <manuel at enigmage.de>
>>
>>>  Hey Moisés,
>>>
>>> Thanks again for this more sophisticated example. I'm having problems
>>> with HIDs, I constantly get this error:
>>>
>>> HidIn: couldn't open keyboard 0...
>>> I get the error for all values from 0 to 5. I'm using Gentoo Linux. For
>>> tonight's presentation, I'm going to stick with KBHit probably.
>>>
>>>
>>> Best, Manuel
>>>
>>>
>>> Am 05/12/13 17:43, schrieb Moisés Gabriel Cachay Tello:
>>>
>>> Hi, I'm a coursera's ChucK course student, in the lectures, Ge used HIDs
>>> to handle keyboard input, so this snippet should help (I'm commenting the
>>> code for clarity).
>>>
>>> // HID stands for human-interface-device, also this is an event,
>>> // see below for more info
>>> Hid hid;
>>>
>>> // This is a message, this will hold the event's (keypress) information.
>>> HidMsg msg;
>>>
>>> // We should define a device number since we would have multiple
>>> keyboards
>>> // attached to our computer, 0 would do on most cases but you can try 1,
>>> or 2
>>> // if that doesn't work.
>>> 0 => int device_number;
>>>
>>> // We check if the device attach with ChucK was successful, otherwise
>>> the program
>>> // would end inmediately
>>> if(!hid.openKeyboard(device_number)) me.exit();
>>>
>>> <<<"Keyboard:", hid.name(), " ready!">>>;
>>>
>>> // We setup a simple sound chain for demonstration pruposes only
>>> BeeThree organ => JCRev rev => dac;
>>> .05 => rev.mix;
>>>
>>> // And repeat forever, see how the keyboard input is something that
>>> would happen
>>> // *forever*, a keypress can occur anytime so we need to stay alert
>>> until a new
>>> // event comes in
>>> while(true) {
>>>     // Events are things that happens sometime, in ChucK this mains
>>> basically
>>>     // hold ourselves until the event appears (thats why we wain for the
>>> event
>>>     // ChucKing it to now)
>>>     hid => now;
>>>
>>>     // When our wait finishes: check all the messages that came from the
>>> keyboard
>>>     // using the recv function, and passing msg as the holder of the
>>> information
>>>     while(hid.recv(msg)) {
>>>
>>>         // we check if the message is a buttondown message, in that case:
>>>         if(msg.isButtonDown()) {
>>>             // We show the ascii value of the key pressed
>>>             <<< "Button down:", msg.ascii >>>;
>>>
>>>             // and make our generator sound, see how we check if the
>>>             // frequency too much high we simply discard this message
>>>             msg.ascii => Std.mtof => float freq;
>>>             if(freq > 20000) continue;
>>>
>>>             freq => organ.freq;
>>>             1 => organ.noteOn;
>>>
>>>             // this will make sure the sound will keep for a minimum
>>> amount of
>>>             // time, otherwise, concurrent events may stop before even
>>> commencing
>>>             80::ms => now;
>>>         } else {
>>>             // If we're not in a buttondown event, just assume it's a
>>> key has been
>>>             // left out and shut down the sound.
>>>             <<< "Button up:", msg.ascii >>>;
>>>             1 => organ.noteOff;
>>>         }
>>>     }
>>>
>>> }
>>>
>>>
>>>
>>> 2013/12/5 Manuel Bärenz <manuel at enigmage.de>
>>>
>>>>  Hi Julien,
>>>>
>>>> No, this is not the case. KBHits are only key down events. I tried to
>>>> include several kb => now, but it didn't help.
>>>> See also this example here:
>>>> http://chuck.cs.princeton.edu/doc/examples/event/kb2.ck
>>>> Apparently, the solution is emptying the event queue by calling
>>>> kb.getchar() until kb.more() returns false:
>>>>
>>>>
>>>> KBHit kb;
>>>>
>>>> me.sourceDir() + "/bum.wav" => string filename;
>>>>
>>>> adc => WvOut b => blackhole;
>>>> filename => b.wavFilename;
>>>> kb => now;
>>>>  while(kb.more()) kb.getchar();
>>>>
>>>> b.closeFile();
>>>>
>>>> SndBuf buf => dac;
>>>> filename => buf.read;
>>>> kb => now;
>>>>
>>>>  The important line is "while(kb.more()) kb.getchar();", apparently. So
>>>> I guess kb => now; doesn't wait at all if there are still unprocessed keys
>>>> in the queue.
>>>>
>>>> Best, Manuel
>>>>
>>>> Am 05/12/13 12:18, schrieb Julien Saint-Martin:
>>>>
>>>>   Hi Manuel,
>>>>
>>>>  Maybe your problem is as follow:
>>>> For each key press there is two kb events: key down and key up.
>>>>
>>>>  A simple solution maybe to write "kb => now;" twice.
>>>>
>>>>  Cheers,
>>>>  Julien
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2013/12/5 Manuel Bärenz <manuel at enigmage.de>
>>>>
>>>>> Hello again,
>>>>>
>>>>> I also wanted to demonstrate a simple sequencer prototype that lets me
>>>>> record a file and then plays it back to me. I've come this far:
>>>>>
>>>>> KBHit kb;
>>>>>
>>>>> me.sourceDir() + "/bum.wav" => string filename;
>>>>>
>>>>> adc => WvOut b => blackhole;
>>>>> filename => b.wavFilename;
>>>>> kb => now;
>>>>> b.closeFile();
>>>>>
>>>>> SndBuf buf => dac;
>>>>> filename => buf.read;
>>>>> kb => now;
>>>>>
>>>>> But strangely, the program doesn't wait for the second kb event, but
>>>>> exits directly after the first key that I hit. Any ideas what I'm doing
>>>>> wrong?
>>>>>
>>>>> Best, Manuel
>>>>> _______________________________________________
>>>>> chuck-users mailing list
>>>>> chuck-users at lists.cs.princeton.edu
>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> chuck-users mailing listchuck-users at lists.cs.princeton.eduhttps://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>
>>>>
>>>> _______________________________________________
>>>> chuck-users mailing list
>>>> chuck-users at lists.cs.princeton.edu
>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>
>>>>
>>>
>>>
>>> --
>>> -Moisés
>>>
>>>
>>> _______________________________________________
>>> chuck-users mailing listchuck-users at lists.cs.princeton.eduhttps://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>>
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>>
>>
>>
>> --
>> -Moisés
>>
>> _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>>
>
>
> _______________________________________________
> chuck-users mailing listchuck-users at lists.cs.princeton.eduhttps://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20131222/d5c08173/attachment-0001.html>


More information about the chuck-users mailing list