"Veli-Pekka Tatila" <[EMAIL PROTECTED]> writes: > Mario Lang wrote: >> impossible to work with for me, since I am on some channels which do >> have quite some traffic going on. > I see. Umm howabout using Festival to read IRC messages on the fly, > would that be possible?
Yes, you can do this already. AFAIK, sirc once had a "speak" script which did use festival to send channel traffic to your soundcard. I definitely remember having had it working here, but I do not remember any details (such as links or if you needed to grab this script from the web at all or if it is already shipped with sirc, just ask google). > It could be quite nice if it when a new message arrived, stopped > reading the console, read the message, paused and backtracked a few > words before continuing with the text. I know that problem, and so I wrote erc-speak about two years ago. This is essentially the same as the "speak" script for sirc I described above, however, it is written for ERC, the Emacs IRC Client, and it utilizes Emacspeak for speech output. I use it daily, I couldn't imagine staying on IRC at all without having speech output. erc-speak can also do things like highlighting keywords with special voices and such, if your Emacspeak backend does support multiple voices (mine, DECtalk Software (R), does.) > This might make things impossible on a busy channel, true, but might > also work on slow 1 to 1 conversation in which both parties are > doing something else while chatting, too. erc-speak can queue traffic, so it even works for very crowded conversations, it catches up as soon as time permits. > about brltty and Gnopernicus co-op: >> Yes, it does. In fact, I wrote this feature in July 2003. > Wow, what else have you written apart from maintaining the > accessibility binaries, If you really care, check http://delysid.org/programming.html (the project list), although I haven't documented everything properly up there anyway. > which is a blessing to me personally, not having to compile from > sources at this point. I am happy to hear this, since it was one of my primary motivations for packaging this stuff in the first place. >> change and re-evaluate your code at run-time, > Umm maybe I could do the same by saving the file and running some > shell scripts that re-compiles and applies the changes. The point is, that SuperCollider has no edit, compile, run cycle as you know it from programming languages like C. It is a dynamic programming language in a sense. > Howabout self-modifying synth code, does that become possible? In a way, yes. > Just a crazy thought. Not crazy enough for the collision machine! :-) >> In SuperCollider, you can evaluate pieces of code >> without having to restart SC. > Wow this sounds very good. Can I play it from a MIDI device? Yes, you can write code which receives MIDI events, and does something with them (like controlling the parameters of a running synth, or initiating a new one.) > Howabout presets, do I have to specify them numerically as well and > can I say preview cutoff changes in real time or is it more like > change cutoff, recompile and listen, change again, more listening > etc... As I said, there is no recompile cycle as you know it. You can execute code while your SC server is already running, which allows you to tweak cutoffs and stuff at run-time, either by manually invoking some piece of code, or by interfacing with MIDI, or with whatever else you can think (and program) of/for. > I imagine that could be painful at worst. Emacs might be the best > tool for it after all, does it work nicely with EmacsSpeak? I haven't tried SuperCollider with Emacspeak yet. I am more of a primarily braille user. -- CYa, Mario
pgp33gYIzPxe5.pgp
Description: PGP signature
