[chuck] Audicle presentation award / video

[Ge Wang]

Dear All,

As Phil mentioned, we haven't really addressed accessibility for
the Audicle, and are open to suggestions.

Here is one potentially bad idea:

     instead of / in addition to accessibility to screen reading of the 
Audicle,
     we sonify the various features of the Audicle, since the idea is to 
gain
     insight into the programs that we write.  There would be some switch
     that toggles/mixes audio synthesis with Audicle sonification, or 
maybe
     the sonification goes on a different channel (which can go to 
another
     host or separate headphones).  The sonification could even be coded
     in ChucK.  This is an entire project in itself, but could
     be very interesting.

I have just returned from a trip to Berlin (for transmediale 2005), and 
we
are continuing to plow/stumble forth on 1.2.  Meanwhile, we have
tweaked performance for OS X and XP, which we are putting out
in 1.1.5.5.

Best,
Ge!

On Feb 7, 2005, at 3:21 PM, Philip Davidson wrote:

>
> Audicle doesn't in itself increase the capabilities of the ChucK 
> language -
> it's analogous to xCode or Visual Studio, with some customization 
> towards
> coding for audio, and tools for  quick feedback on the state of the VM.
> However, the command line interface is fully functional, provides
> much of the same feedback as Audicle, and can be used with any text 
> editor
> Some videos of early chuck show off some serious command-line / pico / 
> emacs / vi madness.
>
> We welcome any suggestions to make chuck's command-line output more
> accessible for screen-reading
>
> but back to Audicle -
>
> Audicle's interface ( including text editor, etc ) is built entirely 
> in C++ using OpenGL for
> cross-platform compatability.  As yet there would be no default 
> screen-reading support,
> nor does it use standardized GUI elements ( at least, we haven't 
> written them ).  If there
> is a standard API that we can work with, that might be an option.  
> With respect to
> magnification of the interface - the windowing system is flexible 
> enough to allow for
> variation and customization ( enlarged fonts, widgets, etc ) in its 
> current incarnation,
> although it isn't properly exposed yet.
>
> The conversation here has given me more thought toward design concerns 
> in this type of system,
> since the Audicle attempts to combine single-user ( generally hi-res ) 
> interaction and a multi-user ( lo-res )
> presentation to an audience.  If it's not apparent that an on-the-fly 
> coding environment running
> off your laptop isn't an e-mail program, you aren't connecting with 
> the audience any more than
> you were before ( probably less so )
>
>
> we'll hopefully have more to work with once Chuck emerges from its 
> current re-write cocoon, and
> the Audicle is released into the wild
>
>
> Phil
>
>
> On Feb 7, 2005, at 1:21 PM, oliver oli wrote:
>
>> the question remains: if you're blind and using a screen reader, is 
>> there anything in audicle which should be made more screen reader 
>> aware or should you just use the command line interface?
>>
>> could the command line chuck be improved for screen readers?
>>
>> what would be a good interface for blind people?
>>
>> how usable is audicle for visually impaired people?
>>
>> Jeffrey Treviño wrote:
>>>     From: *oliver oli <smoerk at gmail.com>
>>>     I don't know much about Audicle, I only watched the video. It's
>>>     mainly a visualization of what is going on inside of ChucK. How 
>>> many
>>>     shreds are running and when they get activated, etc... There is 
>>> also
>>>     an editor which some nifty user interface, which I guess is 
>>> based on
>>>     OpenGL, too.
>>>  From the performance standpoint, I can say that the Audicle is much 
>>> more than a fancy editor / visualization. We have to keep in mind 
>>> that this language aims to facilitate on-the-fly programming. The 
>>> Audicle interface substantially changes how a performer might 
>>> interact with Chuck in realtime, because it fundamentally changes 
>>> the characteristics of the performance interface.
>>>     But this stuff is completely optional, you can also do everything
>>>     with plain chuck and an editor of your choice.
>>> Except that you can do it more quickly and in different ways using 
>>> Audicle. Plus our plain editors are way less interesting to audience 
>>> members than are fancy visualizations.
>>>     I don't think it makes any sense to try to make Audicle more 
>>> screen
>>>     reader friendly, because it's mainly 2D and 3D visualization. I
>>>     guess it's possible to magnify everything in Audicle as it's 
>>> based
>>>     on OpenGL.
>>>     But maybe it's possible to make the command line interface of 
>>> chuck
>>>     more accessible? Have you tried to run chuck? Is there anything
>>>     which could be improved for a screen reader...?
>>> As a composer/performer, I personally prefer virtual instrument GUIs 
>>> of some kind (even if they're dynamically defined) over command line 
>>> interfaces for performance. We need to get away from the suspicion 
>>> that your new music laptop performer is in fact checking his 
>>> e-mailing during the performance you're watching, and projecting 
>>> visualizations--especially visualizations like this that are 
>>> integrated with the code editor and are apparently effecting the way 
>>> in which the performer makes musical decisions--has a lot of 
>>> potential as a cure.
>>> --Jeff Treviño, Stanford University Computer Center for Research in 
>>> Music and Acoustics (CCRMA)
>> _______________________________________________
>> chuck mailing list
>> chuck at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck
>
> _______________________________________________
> chuck mailing list
> chuck at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck