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 <[email protected]> > 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 <[email protected]> > >> 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 <[email protected]> >> >>> 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 <[email protected]> >>> >>>> 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 <[email protected]> >>>> >>>>> 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 >>>>> [email protected] >>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> chuck-users mailing >>>> [email protected]https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>>> >>>> >>>> _______________________________________________ >>>> chuck-users mailing list >>>> [email protected] >>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>>> >>>> >>> >>> >>> -- >>> -Moisés >>> >>> >>> _______________________________________________ >>> chuck-users mailing >>> [email protected]https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>> >>> >>> _______________________________________________ >>> chuck-users mailing list >>> [email protected] >>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>> >>> >> >> >> -- >> -Moisés >> >> _______________________________________________ >> chuck-users mailing list >> [email protected] >> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >> >> > > > _______________________________________________ > chuck-users mailing > [email protected]https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > > > _______________________________________________ > chuck-users mailing list > [email protected] > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > >
_______________________________________________ chuck-users mailing list [email protected] https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
