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
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
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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
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
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
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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing listchuck-users@lists.cs.princeton.eduhttps://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- -Moisés
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
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
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
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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing listchuck-users@lists.cs.princeton.eduhttps://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- -Moisés
_______________________________________________ chuck-users mailing listchuck-users@lists.cs.princeton.eduhttps://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- -Moisés
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
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
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
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
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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing listchuck-users@lists.cs.princeton.eduhttps://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- -Moisés
_______________________________________________ chuck-users mailing listchuck-users@lists.cs.princeton.eduhttps://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- -Moisés
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
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
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
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
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
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
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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing listchuck-users@lists.cs.princeton.eduhttps://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- -Moisés
_______________________________________________ chuck-users mailing listchuck-users@lists.cs.princeton.eduhttps://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- -Moisés
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing listchuck-users@lists.cs.princeton.eduhttps://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
HI Manuel, I have no more idea unfortunately. Maybe you can try with Hid events http://chuck.cs.princeton.edu/doc/examples/hid/kb.ck Br, Julien Le dimanche 22 décembre 2013, Manuel Bärenz a écrit :
I tried all numbers from 0 to 7, all the other numbers give, surprisingly, "Power Button ready" and otherwise the same results.
Am 22/12/13 13:38, schrieb Julien Saint-Martin:
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
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
participants (3)
-
Julien Saint-Martin -
Manuel Bärenz -
Moisés Gabriel Cachay Tello