----- Original Message ----- 
From: "Art Hunkins" 
To: "Andres Cabrera" 
Sent: Wednesday, May 06, 2009 10:48 PM
Subject: Re: [Cs-dev] [Csnd] sensekey and Sugar (OLPC)


> Thanks for this perspective and direction, Andres. I'll dig into TamTam 
> tomorrow to see how keyboard strokes get communicated.
>
> I had thought that perhaps my system software needed updating, but, no, I 
> had the most recent version (build 767).
>
> Incidentally, the sensekey test materials, in failing, presented the new 
> failure message below (the line beginning "python:" seems the important 
> one here). Has anyone an idea of what this could be referring to?
>
> Csound version 5.08.91 beta (float samples) Aug 22 2008
>
> libsndfile-1.0.17
>
> UnifiedCSD: /home/olpc/Activities/Waves.activity/sensekey.csd
>
> STARTING FILE
>
> Creating options
>
> Creating orchestra
>
> Creating score
>
> orchname: /tmp/filexKtoYc.orc
>
> scorename: /tmp/filezbGM8M.sco
>
> rtaudio: ALSA module enabled
>
> rtmidi: ALSA module enabled
>
> orch compiler:
>
> 20 lines read
>
> instr 1
>
> sorting score ...
>
> ... done
>
> Csound version 5.08.91 beta (float samples) Aug 22 2008
>
> displays suppressed
>
> 0dBFS level = 32768.0
>
> orch now loaded
>
> audio buffered in 128 sample-frame blocks
>
> writing 512-byte blks of shorts to dac
>
> SECTION 1:
>
> python: xcb_io.c:182: process_responses: Assertion `((int) 
> (((dpy->last_request_read)) - ((dpy->request))) <= 0)' failed.
>
> Csound tidy up: Segmentation fault
>
> inactive allocs returned to freespace
>
> end of score. overall amps: 5000.0 5000.0
>
> overall samples out of range: 0 0
>
> 0 errors in performance
>
> 144 512-byte soundblks of shorts written to dac
>
> Removing temporary file /tmp/fileQgEakn.srt ...
>
> Removing temporary file /tmp/filezbGM8M.sco ...
>
> Removing temporary file /tmp/filexKtoYc.orc ...
>
> Csound tidy up: Segmentation fault
>
> Art Hunkins
>
> ----- Original Message ----- 
> From: "Andres Cabrera" 
> To: "Art Hunkins" ; "Developer discussions" 
> 
> Sent: Wednesday, May 06, 2009 11:30 AM
> Subject: Re: [Cs-dev] [Csnd] sensekey and Sugar (OLPC)
>
>
> Hi Art,
>
> The rainbow-daemon is the security system for Sugar/OLPC. It is very
> restrictive, so things that usually work on other systems require
> certain changes to work on Sugar. Since you are already using python,
> I would recommend taking a look at how things are done in TamTam,
> which also receives keyboard events and passes them to csound. They
> grab the keyboard events in python (from the main Activity subclass):
>
> http://git.sugarlabs.org/projects/tamtam-branch/repos/mainline/blobs/master/TamTamMini.activity/TamTamMini.py#line53
>
> and then pass the to csound via the software bus:
> http://git.sugarlabs.org/projects/tamtam-branch/repos/mainline/blobs/master/TamTamMini.activity/Mini/miniTamTamMain.py#line552
>
> Cheers,
> Andrés
>
> On Tue, May 5, 2009 at 1:02 PM, Art Hunkins  wrote:
>> There is definately a problem with sensekey being run in Sugar. 
>> Apparently
>> it has to do with X windows, as this is what the log file indicates.
>>
>> The attached test csd runs fine from the console on the OLPC, including
>> printing out the ASCII characters as struck on the keyboard (which is the
>> expected behavior).
>>
>> In Sugar, however, the run aborts immediately; the log file carries on 
>> about
>> an X window system error. (The other attached file is the simplest 
>> possible
>> Python GUI.)
>>
>> When kasc is initialized to 0, and this line substituted for sensekey 
>> (only
>> the single line is changed, as indicated in the csd), the 10-second file
>> runs fine - except, of course, there is no alternation of pitches when
>> pressing ASCII keys. Obviously the problem involves sensekey and X 
>> windows.
>>
>> Can one of the developers investigate (Victor, Brian, Andres, or anyone 
>> else
>> involved with OLPCsound), or indicate where I should turn?
>>
>> I've 4 csd's in my current OLPC Activity project; the two using MIDI
>> controllers are working fine in Sugar, the two using ASCII keystrokes as 
>> a
>> control mechanism (through sensekey) are hanging me up completely.
>>
>> The two attached files are intended to be inserted into Victor's Wave
>> activity - in the Waves.activity directory. The attached waves.py 
>> replaces
>> Victor's of the same name. As mentioned above, the sensekey.csd runs fine
>> from the console and command line: csound sensekey.csd (from wherever
>> sensekey.csd is located).
>>
>> I really hope this sensekey issue can be sorted, and made to work in 
>> Sugar.
>> 50% of my project depends on it.
>>
>> As always, I much appreciate the help.
>>
>> Art Hunkins
>>
>> ----- Original Message ----- From: "Art Hunkins" 
>> To: 
>> Sent: Friday, May 01, 2009 9:57 PM
>> Subject: Re: [Csnd] sensekey and Sugar (OLPC)
>>
>>
>>> A followup:
>>>
>>> A similar sensekey/ASCII-based csd issues two slightly different error
>>> messages (with the same run abort):
>>>
>>> rainbow-daemon: Fatal IO error 0 (Success) on X server :0.0
>>> or
>>> rainbow-daemon: Fatal IO error 11 (Resource temporarily unavailable) on 
>>> X
>>> server :0.0
>>>
>>> Sometimes the run returns to Sugar, sometimes not.
>>>
>>> The scripting seems to be right, and nearly identical for the two csd's.
>>>
>>> Art Hunkins
>>>
>>> ----- Original Message ----- From: "Art Hunkins" 
>>> To: 
>>> Sent: Friday, May 01, 2009 9:28 PM
>>> Subject: [Csnd] sensekey and Sugar (OLPC)
>>>
>>>
>>>> I have a csd that runs impeccably from the XO console, but fails in 
>>>> Sugar
>>>> (a Python script is running as an XO project; I've been making 
>>>> progress).
>>>> I'm fairly certain the problem is sensekey, or the way in which Sugar 
>>>> is (or
>>>> isn't) dealing with ASCII keystrokes.
>>>>
>>>> The Sugar error occurs precisely at the first ASCII keystroke (prior to
>>>> that, the run is fine). With the keystroke, the run aborts and exits to
>>>> Sugar.
>>>>
>>>> The log shows the error message to be:
>>>> rainbow-daemon: Fatal IO error 12 (Cannot allocate memory) on X server
>>>> :0.0
>>>> then a bit later:
>>>> Csound tidy up: Segmentation fault
>>>>
>>>> What do I need to change?
>>>>
>>>> Art Hunkins
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>>>> "unsubscribe
>>>> csound"
>>>
>>
>> ------------------------------------------------------------------------------
>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>> production scanning environment may not be a perfect world - but thanks 
>> to
>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
>> i700
>> Series Scanner you'll get full speed at 300 dpi even with all image
>> processing features enabled. http://p.sf.net/sfu/kodak-com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>
>
>
> -- 
>
>
> Andrés 

Brian Redfern wrote on 5/7/09 3:39 AM:

> Actually its not pygtk, just taking keyboard input is basic python, but I
> would imagine you can do more taking the input via the python script and
> then seeing if you can pass it into the csd as a channel.

Can the sensekey callback be set from Python?

Actually, I guess there are two ways to do this in C.  The first does not
set a callback and I guess would be usable from Python.  The second sets a
callback and because of the void* types, I am guessing will not be usable
from Python?

  /**
   * Set the ASCII code of the most recent key pressed.
   * This value is used by the 'sensekey' opcode if a callback
   * for returning keyboard events is not set (see csoundSetCallback()).
   */
  PUBLIC void csoundKeyPress(CSOUND *, char c);

  /**
   * Sets general purpose callback function that will be called on various
   * events. The callback is preserved on csoundReset(), and multiple
   * callbacks may be set and will be called in reverse order of
   * registration. If the same function is set again, it is only moved
   * in the list of callbacks so that it will be called first, and the
   * user data and type mask parameters are updated. 'typeMask' can be the
   * bitwise OR of callback types for which the function should be called,
   * or zero for all types.
   * Returns zero on success, CSOUND_ERROR if the specified function
   * pointer or type mask is invalid, and CSOUND_MEMORY if there is not
   * enough memory.
   *
   * The callback function takes the following arguments:
   *   void *userData
   *     the "user data" pointer, as specified when setting the callback
   *   void *p
   *     data pointer, depending on the callback type
   *   unsigned int type
   *     callback type, can be one of the following (more may be added in
   *     future versions of Csound):
   *       CSOUND_CALLBACK_KBD_EVENT
   *       CSOUND_CALLBACK_KBD_TEXT
   *         called by the sensekey opcode to fetch key codes. The data
   *         pointer is a pointer to a single value of type 'int', for
   *         returning the key code, which can be in the range 1 to 65535,
   *         or 0 if there is no keyboard event.
   *         For CSOUND_CALLBACK_KBD_EVENT, both key press and release
   *         events should be returned (with 65536 (0x10000) added to the
   *         key code in the latter case) as unshifted ASCII codes.
   *         CSOUND_CALLBACK_KBD_TEXT expects key press events only as the
   *         actual text that is typed.
   * The return value should be zero on success, negative on error, and
   * positive if the callback was ignored (for example because the type is
   * not known).
   */
  PUBLIC int csoundSetCallback(CSOUND *, int (*func)(void *userData,
    void *p, unsigned int type), void *userData, unsigned int typeMask);

It would be usable from Python using ctypes. See the ctypes
documentation in the Python manual.

Hope this helps,
Mike

On 5/7/09, Anthony Kozar  wrote:
> Brian Redfern wrote on 5/7/09 3:39 AM:
>
>> Actually its not pygtk, just taking keyboard input is basic python, but I
>> would imagine you can do more taking the input via the python script and
>> then seeing if you can pass it into the csd as a channel.
>
> Can the sensekey callback be set from Python?
>
> Actually, I guess there are two ways to do this in C.  The first does not
> set a callback and I guess would be usable from Python.  The second sets a
> callback and because of the void* types, I am guessing will not be usable
> from Python?
>
>   /**
>    * Set the ASCII code of the most recent key pressed.
>    * This value is used by the 'sensekey' opcode if a callback
>    * for returning keyboard events is not set (see csoundSetCallback()).
>    */
>   PUBLIC void csoundKeyPress(CSOUND *, char c);
>
>   /**
>    * Sets general purpose callback function that will be called on various
>    * events. The callback is preserved on csoundReset(), and multiple
>    * callbacks may be set and will be called in reverse order of
>    * registration. If the same function is set again, it is only moved
>    * in the list of callbacks so that it will be called first, and the
>    * user data and type mask parameters are updated. 'typeMask' can be the
>    * bitwise OR of callback types for which the function should be called,
>    * or zero for all types.
>    * Returns zero on success, CSOUND_ERROR if the specified function
>    * pointer or type mask is invalid, and CSOUND_MEMORY if there is not
>    * enough memory.
>    *
>    * The callback function takes the following arguments:
>    *   void *userData
>    *     the "user data" pointer, as specified when setting the callback
>    *   void *p
>    *     data pointer, depending on the callback type
>    *   unsigned int type
>    *     callback type, can be one of the following (more may be added in
>    *     future versions of Csound):
>    *       CSOUND_CALLBACK_KBD_EVENT
>    *       CSOUND_CALLBACK_KBD_TEXT
>    *         called by the sensekey opcode to fetch key codes. The data
>    *         pointer is a pointer to a single value of type 'int', for
>    *         returning the key code, which can be in the range 1 to 65535,
>    *         or 0 if there is no keyboard event.
>    *         For CSOUND_CALLBACK_KBD_EVENT, both key press and release
>    *         events should be returned (with 65536 (0x10000) added to the
>    *         key code in the latter case) as unshifted ASCII codes.
>    *         CSOUND_CALLBACK_KBD_TEXT expects key press events only as the
>    *         actual text that is typed.
>    * The return value should be zero on success, negative on error, and
>    * positive if the callback was ignored (for example because the type is
>    * not known).
>    */
>   PUBLIC int csoundSetCallback(CSOUND *, int (*func)(void *userData,
>     void *p, unsigned int type), void *userData, unsigned int typeMask);
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com