[chuck-users] KBHit events
Moisés Gabriel Cachay Tello
xpktro at gmail.com
Thu Dec 5 13:24:49 EST 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20131205/9e0b82fe/attachment.html>
More information about the chuck-users
mailing list