Re: [chuck-users] keyboard fail
Spencer and Bob,
The problem is not exclusively an El Capitan issue. It was already happening in Yosemite before she upgraded.
We have tried other device numbers. If it is a correct device number, it will open the keyboard but not receive data. If it is an incorrect device number, it gives the 'couldn’t open' response. (As I indicated, we also tried connecting an external USB keyboard.)
davd
Fra: Bob Bob
Tried keyboard input on Yosemite, same model only difference is that my laptop has 15" and it worked just fine. Enviado desde mi iPad
El 31/10/2015, a las 10:22 a.m., David Loberg Code
escribió: Spencer and Bob, The problem is not exclusively an El Capitan issue. It was already happening in Yosemite before she upgraded. We have tried other device numbers. If it is a correct device number, it will open the keyboard but not receive data. If it is an incorrect device number, it gives the 'couldn’t open' response. (As I indicated, we also tried connecting an external USB keyboard.)
davd
Fra: Bob Bob
Emne: Re: [chuck-users] keyboard fail Dato: 31. oktober 2015 01:10:39 GMT-4 Til: ChucK Users Mailing List Svar til: ChucK Users Mailing List I've hesitated to update to el capitan because a lot of people have been having issues. I also have the latest MacBook pro but 15" and everything works so far.
2015-10-28 19:06 GMT-06:00 Spencer Salazar
: Hi David,
I will test this on my end also but some times an OS version update will introduce "ghost" HID's, especially keyboards or trackpads, that can be opened but do not generate data. This has happened a few times before. The way to check is to change the kbNum and see if using a different number (1, 2, 3, etc.) produce data. You only need to try this until you see "couldn't open keyboard #" for whichever number after 0, which means you've exhausted the list of things ChucK thinks is a keyboard.
Otherwise this could be a new issue specific to El Capitan :(
spencer
On Wed, Oct 28, 2015 at 11:16 AM, David Loberg Code
wrote: I have a student with a MacBook Pro (Retina, 13", early-2015). She was on Yosemite with latest ChucK build; now on El Capitan with the ChucK beta build (1.3.5.2 beta). The same problem happened in both builds. She can open the keyboard with Hid. It will successfully pull the kb.name and print it. However, it won’t detect any other activity from the keyboard. It gets stopped at kb=>now; and won’t go any further. We have tried an external USB keyboard too, and it produces the same problem.
Anyone else have this happen OR have a cure?
thanks,
davd
David Loberg Code Western Michigan University code@wmich.edu
Hid kb; HidMsg kbMsg; 0 => int kbNum; kb.openKeyboard( kbNum ) => int kbAvailable; if ( kbAvailable == 0 ) me.exit(); <<< "keyboard '", kb.name(), "' ready" >>>;
while (true) { // hangs up waiting for kb=>now event kb => now; while(kb.recv(kbMsg)) { if (kbMsg.isButtonDown()) { kbMsg.key => int keyNum; <<< "#", keyNum >>>; } //end button down } // end while hid.recv } // end while(true)
davd
David Loberg Code School of Music Western Michigan University 1903 W Michigan Ave Kalamazoo, MI 49008-5434 code@wmich.edu
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On an MacBook Pro (Retina, 13-inch, Early 2015) with El Capitan version
10.11.1 the internal keyboard works ok for me with chuck built from git head
$ chuck --version
chuck version: 1.3.5.2-beta-1 (chimera)
mac os x : intel : 64-bit
http://chuck.cs.princeton.edu/
http://chuck.stanford.edu/
$ chuck --loop
[chuck](VM): sporking incoming shred: 1 (kb.ck)...
keyboard ' Apple Internal Keyboard / Trackpad ' ready
1# 30
2# 31
3# 32
4# 33
5# 34
q# 20
w# 26
e# 8
r# 21
t# 23
y# 28
# 224
# 6
^C[chuck]: cleaning up...
On Sun, Nov 1, 2015 at 6:50 PM, Bob Bob
Tried keyboard input on Yosemite, same model only difference is that my laptop has 15" and it worked just fine.
Enviado desde mi iPad
El 31/10/2015, a las 10:22 a.m., David Loberg Code < d.loberg.code@wmich.edu> escribió:
Spencer and Bob, The problem is not exclusively an El Capitan issue. It was already happening in Yosemite before she upgraded. We have tried other device numbers. If it is a correct device number, it will open the keyboard but not receive data. If it is an incorrect device number, it gives the 'couldn’t open' response. (As I indicated, we also tried connecting an external USB keyboard.)
davd
*Fra: *Bob Bob
*Emne: **Re: [chuck-users] keyboard fail* *Dato: *31. oktober 2015 01:10:39 GMT-4 *Til: *ChucK Users Mailing List *Svar til: *ChucK Users Mailing List I've hesitated to update to el capitan because a lot of people have been having issues. I also have the latest MacBook pro but 15" and everything works so far.
2015-10-28 19:06 GMT-06:00 Spencer Salazar
: Hi David,
I will test this on my end also but some times an OS version update will introduce "ghost" HID's, especially keyboards or trackpads, that can be opened but do not generate data. This has happened a few times before. The way to check is to change the kbNum and see if using a different number (1, 2, 3, etc.) produce data. You only need to try this until you see "couldn't open keyboard #" for whichever number after 0, which means you've exhausted the list of things ChucK thinks is a keyboard.
Otherwise this could be a new issue specific to El Capitan :(
spencer
On Wed, Oct 28, 2015 at 11:16 AM, David Loberg Code < d.loberg.code@wmich.edu> wrote:
I have a student with a MacBook Pro (Retina, 13", early-2015). She was on Yosemite with latest ChucK build; now on El Capitan with the ChucK beta build (1.3.5.2 beta). The same problem happened in both builds.
She can open the keyboard with Hid. It will successfully pull the kb.name and print it. However, it won’t detect any other activity from the keyboard. It gets stopped at kb=>now; and won’t go any further. We have tried an external USB keyboard too, and it produces the same problem.
Anyone else have this happen OR have a cure?
thanks,
davd
David Loberg Code Western Michigan University code@wmich.edu
Hid kb; HidMsg kbMsg; 0 => int kbNum; kb.openKeyboard( kbNum ) => int kbAvailable; if ( kbAvailable == 0 ) me.exit(); <<< "keyboard '", kb.name(), "' ready" >>>;
while (true) { // hangs up waiting for kb=>now event kb => now; while(kb.recv(kbMsg)) { if (kbMsg.isButtonDown()) { kbMsg.key => int keyNum; <<< "#", keyNum >>>; } //end button down } // end while hid.recv } // end while(true)
davd
David Loberg Code School of Music Western Michigan University 1903 W Michigan Ave Kalamazoo, MI 49008-5434 code@wmich.edu
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://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 Chuckers, I just tried the PowerADSR chugins. When used like a classical ADSR with function set() it works fine. But when I add the setCurves() function after the sustain part of my sound disapear. I checked the PowerADSR.cpp file and found something suspect line 235: float setDecayCurve( t_CKFLOAT dc) { m_decayCurve = dc; * m_sustainLevel = m_currentLevel;* m_decayCount = 0; return dc; } When setting the Decay curve, the function set sustain to current level. When the ADSR is off it reset it to zero. When I comment this line 235 PowerADSR works like I expect. I don't know what is the goal of this line so maybe it is not a propper fix. Note there is the same kind of action line 192 in the setDecay function. Some can also experiments problem with that, I think. Cheers, Julien
participants (4)
-
Bob Bob
-
David Loberg Code
-
Julien Saint-Martin
-
Michael Heuer