CAAD

Comunidad de Aventuras Conversacionales y Relatos Interactivos
Fecha actual 09 Ago 2020 23:59

Todos los horarios son UTC + 1 hora




Nuevo tema Responder al tema  [ 166 mensajes ]  Ir a página Anterior  1 ... 8, 9, 10, 11, 12  Siguiente
Autor Mensaje
NotaPublicado: 31 Jul 2015 19:04 
Desconectado
Dragón
Dragón

Registrado: 17 Sep 2014 12:58
Mensajes: 114
Bueno me he seguido peleando con tu script, veo que usas una función para windows:
tts.is_speaking()

He querido meter eso también en el caso de mac pero no encuentra esa función.... Tiene que haber alguna manera de saber si el mac en ese momento está reproduciendo texto o no...


Arriba
 Perfil  
 
NotaPublicado: 31 Jul 2015 19:25 
Desconectado
Dragón
Dragón

Registrado: 17 Sep 2014 12:58
Mensajes: 114
Ultima prueba... como ese proceso de python y el tema de applescript no se mucho como va, he intentado otra cosa...

Dado que al lanzar el script genera un proceso en el sistema de nombre "osascript" he pensado que, modificar mi script shell para que antes de enviar algo al script de python, mire si está ese proceso, cosa que indicaria que hay un texto de voiceover ejecutándose, y esperarse a que acabe...

Pero eso tampoco funciona, resulta que ese proceso solo aparece un momento, y desaparece de la lista de procesos aunque el texto que se le haya enviado aun no haya acabado.

En fin, Sukil, a no ser que encuentres alguna manera con tu script python usando, supongo applescript, para saber si realmente voiceover está hablando o no (cosa que en google no he encontrado), no se que más probar...

Saludos
César


Arriba
 Perfil  
 
NotaPublicado: 01 Ago 2015 21:33 
Desconectado
Yiepp
Yiepp

Registrado: 03 Nov 2013 22:56
Mensajes: 69
Hola:
Tengo una noticia buena y otra mala. La buena es que Sourceforge por fin, después de quince días, vuelve a estar en completo funcionamiento. La mala es que hoy he estado mirando con un amigo lo de ver si se podía hacer que VoiceOver esperase a que finalizase de hablar, y según veo no se puede (lo he mirado en el diccionario de VoiceOver, en el editor de scripts). Vamos, que lamentándolo mucho habrá que quitar la compatibilidad con Mac de mi script (porque Say ya se controla con un shell script).
Ahora me falta ver si puedo hacer algo con Speech Dispatcher en Linux, devorando antes la documentación de ssip y Speech Dispatcher. Una cosa bastante fea que le vi cuando empecé a hacer pruebas es que lo único que alcanzaba a leer era el primer mensaje, únicamente en inglés. Como siempre, ya os contaré si consigo solventarlo.
Saludos!


Arriba
 Perfil  
 
NotaPublicado: 02 Ago 2015 11:18 
Desconectado
Dragón
Dragón

Registrado: 17 Sep 2014 12:58
Mensajes: 114
Hola

Si, ya veo que sourceforge ha mejorado... Espero que del todo... Al menos ya deja subir archivos. He subido la versión snapshot (la misma que habia en google sites) ahí.
Bueno lo de voiceover yo creo que tiene que haber alguna manera... pero bueno, de momento la solución que tengo mediante say ya es válida.
A ver cuando tenga tiempo probaré tus scripts en Windows.

Saludos
César


Arriba
 Perfil  
 
NotaPublicado: 02 Ago 2015 22:39 
Desconectado
Implementador
Implementador

Registrado: 09 Jun 2010 14:50
Mensajes: 1677
Ubicación: Argentina
Primero que todo, me disculpo por no estar muy presente, consecuencia de estar recuperándome de un desastre informático y a la vez deber estudiar para la facultad que el martes tengo un parcial.

En cuanto a los agradecimientos, César, humildemente no creo haber hecho una gran contribución (a lo más tirar ideas y buscar alguna información sobre la consola), pero si estimas que mi ayuda ha servido para algo adelante, encantado de figurar en los agradecimientos así, con mi nombre real.

Respecto de VoiceOver (qué grande Louis con sus ingenios multiplataforma), César, lo cierto es que es un lector de pantalla completísimo, que ciertamente hace honor a la idea de las Mac (yo no tengo ninguna) de poder usarlas recién sacadas de la caja. La misma potencia tiene en iOS, de modo que hoy en día no hay compañía que ponga tanta accesibilidad de fábrica como Apple.

Y bueno, por ahora no sé. En cuanto termine de recuperar la máquina de escritorio tendré a bien betatestear estos últimos avances.

¡Saludos y buen inicio de semana!


Arriba
 Perfil  
 
NotaPublicado: 02 Ago 2015 23:16 
Desconectado
Dragón
Dragón

Registrado: 17 Sep 2014 12:58
Mensajes: 114
Hola Fernando.

Si, debes estar en dicho archivo de agradecimientos, así como mucha otra gente a la que menciono en dicho archivo. Con mas o con menos contribuciones, ayudáis a que mi emulador sea mejor. Y que menos que os deje agradecimiento por escrito.
Además, todo el tema de Accesibilidad esta siendo muy especial para mi. En el emulador el soporte de texto nació como una curiosidad mas en mi emulador, algo que se me ocurrió hace mucho tiempo (años incluso antes de hacer el emulador)... Como siempre he sido fanático de Linux y de la consola, pensé... Porque no tener una salida de texto desde Spectrum? Esto que nació como digo, como curiosidad, o frikada, de mi emulador, llamó la atención de vosotros, usuarios del foro de caad, en otro post diferente al actual,
viewtopic.php?f=9&t=5677

En el que se nombraba dicha salida de texto y el posible uso de ello para sistemas de speech.
Eso me sirvió de motivación para poder implementar el speech, primero en Linux y solo con el driver de texto, y luego ya en Windows y con todos los drivers.
Sinceramente es una de las cosas de las que mas me siento orgulloso, porque el emulador ayuda a usuarios invidentes a que puedan disfrutar de juegos de Spectrum. Y haber podido ayudar a alguno de vosotros me satisface enormemente.

En cuanto al tema de VoiceOver... Si, lo poco que he podido probar, tanto en mac como en iPhone, me parece una maravilla. Aunque bueno, quizá vosotros tengáis mas practica en otros sistemas de accesibilidad y quizá superen al de Apple.

En fin, ya seguimos charlando.... Creo que ya comenté en post anteriores que mejoré un poco el tema del prompt en juegos creados con el paws... Ahora cuando se escribe la sentencia en el prompt, luego,se escucha todo seguido, y no separado por espacios, como antes. Ya lo probareis y me decís algo

Saludos
César


Arriba
 Perfil  
 
NotaPublicado: 02 Ago 2015 23:32 
Desconectado
Yiepp
Yiepp

Registrado: 03 Nov 2013 22:56
Mensajes: 69
Hola:
Contesto primero a Fernando. De ingenios nada. Soy bastante malo en Python, tiro de manual constantemente y la mayor parte del trabajo está hecha por terceros.
Lamentablemente sigo sin poder encontrar ninguna solución 100% fiable al problema de VoiceOver. Se me ocurre una.
Veamos: algunos programas, al no saber cuánto tiempo tienen que esperar entre mensajes, usan un parámetro de espera. Este parámetro, por ejemplo, se podría indicar por línea de órdenes, añadiendo al shell script el parámetro --wait y un número (generalmente no entero). Eso sí, calcularlo ya correría por cuenta del usuario.
Ejemplo sacado del manual de un juego real:
Citar:
Windows srapi_wait parameter
Since I couldn't find a way to know when a screen reader stops talking on Windows, I had to evaluate the duration of a message. An additional parameter called "srapi_wait" determines how long SoundRTS will wait before sending the next message. With "srapi_wait = .1" and a message of 10 characters, SoundRTS will wait for .1 * 10 = 1 second.
Increase the value of srapi_wait if some messages are interrupted by the next one. Decrease the value of srapi_wait if the silence between two messages is too long.

Vale. No sé cómo a mí en Windows esto no me falla. Será que como es un programa cíclico en Windows se espera a que el lector deje de hablar hasta que el script termine. En fin, quizá esto funcionaría en Mac. Es más, creo que la escala usada serviría perfectamente. A primera vista, puede parecer surrealista, pero os sorprendería la velocidad con la que leemos algunos ciegos. ¿Qué opina el resto?
Saludos!


Arriba
 Perfil  
 
NotaPublicado: 03 Ago 2015 00:46 
Desconectado
Yiepp
Yiepp

Registrado: 03 Nov 2013 22:56
Mensajes: 69
Hola:
Acabo de encontrar un bug extrañísimo en la versión Windows de ZEsarUX. Resulta que al intentar jugar una aventura inglesa, y escuchar todos los soniditos de carga, he pulsado varias veces el comando ctrl+insert numérico (el 0 con bloq num desactivado) + flecha abajo. Este comando se utiliza para cambiar el idioma del lector de pantalla entre otras cosas (lo tenía en castellano). Bueno, pues al hacer eso se han vuelto a oír los pitidos de carga. Y además el speech se comportaba de forma bastante peculiar en el menú de cambio de volumen y en el menú de salir. Quizá es que se han abierto otras instancias de ZEsarUX al pulsar dicha combinación varias veces. Supongo esto porque he tenido que salir varias veces del emulador, y los mensajes del speech eran bastante curiosos al respecto.
A, y por cierto. Puede que esto sea rizar el rizo pero me ha pasado: por línea de órdenes he especificado la opción --textspeechmenu como la primera, después las de trap print y las del ancho de línea, y por último el programa de texto a voz. El menú no se enviaba al programa. Como digo, casos raros y fácilmente solventables por el usuario, pero por reportar que no quede :) .
Saludos de un jugador nocturno.


Arriba
 Perfil  
 
NotaPublicado: 03 Ago 2015 05:56 
Desconectado
Dragón
Dragón

Registrado: 17 Sep 2014 12:58
Mensajes: 114
Hola

Respondo a los dos post de Sukil.
Primero, lo de la pausa al enviar mensajes con VoiceOver... Entiendo que sugieres que el emulador espere un número de segundos proporcional a la longitud del mensaje... Supongo que funcionaria, pero de todas maneras, si al final el script que tiene el emulador, que usa el comando say del mac, es capaz de esperar por si solo... para ir queremos ese otro parámetro? Si, seria otro parámetro mas con el que jugar, pero creo que esto añadiría complicación al sistema. Porque insisto, lo de que espere antes de enviar el siguiente mensaje, ya lo hace con el script que hice para Mac.
En cuanto a las dos cosas con ese juego... Esa ccombinacion de teclas en el emulador no significa mucho, aparte de activar teclas y botones del joystick kempston y poco más... Pero bueno lo probare en Windows a ver que sucede.
En cuanto a los parámetros por línea de comandos, dime exactamente lo que le has enviado. Pero en principio el orden no influye para nada y debería funcionar

Saludos
César


Arriba
 Perfil  
 
NotaPublicado: 03 Ago 2015 09:25 
Desconectado
Yiepp
Yiepp

Registrado: 03 Nov 2013 22:56
Mensajes: 69
Hola:
En cuanto a lo de VoiceOver, me refería a que mi script esperase un número proporcional de segundos antes de acabar, no el emulador. Cierto es que say esto lo hace correctamente, pero quizá resulte más cómodo utilizar VoiceOver mismo para la salida de texto a voz.
Y lo del menú que no se verbaliza... ahora no consigo reproducirlo. Bueno, es un fallo menor, así que no creo que tenga importancia.
Lo de probar mi script en Windows: muy bien, nunca viene mal algún testeo más. Te dejo algunos puntos a tener en cuenta:
Creo recordar que en su versión actualmente liberada hay que especificarle --sapi y una voz a utilizar para usar dicho motor. Si no, no funciona a menos que haya un lector de pantalla en funcionamiento. En el código lo he solucionado, y lo liberaré en breve, en cuanto confirme o descarte la utilización del script en Linux.
Los lectores de pantalla se interrumpen cuando se pulsa una tecla. No así SAPI, que es únicamente un sintetizador de voz. Así que para interrumpirlo hay que especificarle un script de parada.
En Windows inferiores a Windows 8, a mi entender las únicas voces que vienen con el sistema son voces inglesas de Microsoft, bastante malas, por cierto.
Y creo que eso es todo.
Saludos!


Arriba
 Perfil  
 
NotaPublicado: 03 Ago 2015 10:02 
Desconectado
Implementador
Implementador

Registrado: 09 Jun 2010 14:50
Mensajes: 1677
Ubicación: Argentina
Hago un intento de dar algo de luz verde sobre la espera de que un lector de pantalla deje de hablar, al menos en Windows que es lo que domino:

La librería de código abierto Accessible Output se comunica con los lectores de pantalla no a través de sus lenguajes de scripts sino directamente mediante llamadas a sus librerías que, por el hecho de buscarse que se recurra a los scripts, los fabricantes dejan bastante de lado. El caso es que al menos ni JAWS ni NVDA permiten por llamadas a sus librerías poner en cola mensajes hasta que se terminen de verbalizar los anteriores.
Al emplear SAPI 5 la cosa está algo mejor, porque aparte de poder un programa detener lo que se está verbalizando, en el repertorio de etiquetas XML tanto de SAPI 5 como de Microsoft Speech Platform hay una para insertar marcadores de eventos que una vez alcanzados envían una señal a la aplicación para que ésta haga algo, lo cual en el emulador podría servir para que una vez enviada la señal éste mande la línea siguiente. ¿Tienen los sistemas de voz en Mac y Linux alguna etiqueta semejante? Ahora tengo que bajarme la versión normal de Balabolka cuya ayuda traduje en su momento, de modo que en un ratito vuelvo con la información específica de esa etiqueta.

Aunque ya no sería cuestión de lidiar tanto con el emulador sino más bien con el lenguaje de scripts de JAWS, el hecho de estar traduciendo el archivo de documentación de las funciones internas de JAWS que nunca se tradujo (uno de esos proyectos personales de demente del lenguaje y la informática) me hace pensar que JAWS tiene una función que satisfaría esta necesidad de que no se verbalice todo de una vez pero que tampoco se salte nada, concretamente QueueFunction, cuya descripción cito:

Citar:
La función dada se ejecutará la próxima vez que jaws deje de hablar. Se pueden poner en cola varias funciones. Las funciones se ejecutan en el orden en el que se agregan a la cola. Detener la voz pulsando control o realizar otra acción por el estilo borrará la cola.

¿Haría falta que las llamadas a librerías pudieran hacer justamente esto?

La función dada en teoría puede ser cualquiera (de ahí el tono genérico), pero en la vida real suele ser alguna que verbalice otra información, ya sea especificada entre comillas o de conformidad con lo que haya en alguna variable/devuelva otra función. Que la cola se borre al presionar CTRL o hacer otra cosa es lógico, porque cuando un usuario de cualquier lector de pantalla (no es propio de JAWS ni se circunscribe a Windows) pulsa CTRL es para que la máquina se calle, no para pasar al anuncio siguiente... Y aunque en la documentación de la función de JAWS no está, presumo que debe ser excepción a la regla que el usuario desactive la casilla Interrumpir voz mientras se escribe, al menos respecto a lo que la información se refiere como otra acción por el estilo.
Para el caso la función Pause (otra en que también pensé) sería impertinente, porque lo que hace es detener la ejecución de un script para que una aplicación tenga tiempo de procesamiento a fin de completar tareas, pero con un script de JAWS no habría necesidad de que los tiempos de espera los maneje el emulador.

En un ratito, como dije, vuelvo con la información de las marcas en SAPI, a ver qué equivalencia existe para otros sistemas.


Arriba
 Perfil  
 
NotaPublicado: 03 Ago 2015 10:27 
Desconectado
Yiepp
Yiepp

Registrado: 03 Nov 2013 22:56
Mensajes: 69
Hola Fernando:
Muy interesante la información, pero he de decir que lo que comentas ya se consiguió. Te explico rápidamente el procedimiento de mi script, o programa, como quieras, con lo que creo que es el procedimiento de la libreía:

Con JAWS y NVDA, se envía el texto a reproducir sin más. El texto lo reproduce entero, porque al ser únicamente un alínea la que se envía por cada ejecución del script, no hay posibilidad de interrupción. Es decir: la ejecución del script se genera limpiamente, sin saltos ni contratiempos, a menos que uno se mueva de forma impaciente en el menú, cosa que no es solucionable. Como tanto JAWS como NVDA tienen la ventaja de silenciarse cuando se pulse una tecla, no hay ningún problema de lentitud en el menú (salvo algo así como medio segundo hasta que la opción se verbalice). Aclaro que mi programa funciona con más lectores, pero esos dos son los únicos que conozco y que uso o he usado.

Con SAPI 5, sin embargo, el script no espera a que SAPI deje de hablar. Al contrario: enbía el texto y el script se cierra. Por suerte, con SAPI se puede evaluar si este sigue hablando, por lo cual es fácil mantener el script abierto hasta que termine de hablar. Sin embargo, como sabes SAPI no reacciona a teclas así que hay que crear un script de parada para el emulador que "mate" el proceso cuando se pulsen flechas en el menú, o escape en la ventana de juego. Este script es un bat con la orden taskkill apuntando al programa a parar, que el emulador ejecuta en los casos anteriormente citados.

Saludos!


Última edición por Louis Creed el 03 Ago 2015 10:31, editado 1 vez en total

Arriba
 Perfil  
 
NotaPublicado: 03 Ago 2015 10:29 
Desconectado
Implementador
Implementador

Registrado: 09 Jun 2010 14:50
Mensajes: 1677
Ubicación: Argentina
Bueno, me hice de Balabolka y veo en el tema de ayuda sobre etiquetas XML para SAPI 5 que de la que hablaba era bookmark.

Creo, Louis, que si Accessible Output permite aprovechar esta etiqueta cuando se emplea SAPI 5 solucionarías, al menos en Windows, lo de la comprobación del tiempo de espera para enviar la línea siguiente, pues con una de estas marcas podrías indicar a SAPI que envíe una señal a Accessible Output, a su vez enganchado al emulador, para que recién cuando se recibe esta señal el emulador siga mandando texto que leer. Paso a citar lo que dice al respecto la ayuda de Balabolka, a ver qué se puede aprovechar:
Citar:
La etiqueta Bookmark inserta un evento de marca en el flujo de salida de audio. Utilice este evento para enviar una señal a la aplicación cuando se haya llegado al texto correspondiente a la etiqueta Bookmark. La etiqueta Bookmark debe estar vacía.

La etiqueta Bookmark tiene un atributo, Mark, cuyo valor es una cadena. Este valor puede usarse para diferenciar los eventos de marcas (cada uno de los que contiene el valor de la cadena en su etiqueta correspondiente).
La aplicación recibirá un evento aquí,
Código:
<bookmark mark="marca_1"/>

y otro aquí
Código:
<bookmark mark="marca_dos"/>


Arriba
 Perfil  
 
NotaPublicado: 03 Ago 2015 10:38 
Desconectado
Implementador
Implementador

Registrado: 09 Jun 2010 14:50
Mensajes: 1677
Ubicación: Argentina
¡Qué bueno Louis que lo hayas conseguido!
Y sí, desde luego que SAPI por sí sólo no proporciona combinaciones de teclas, pues justamente se ocupa del texto a voz y el reconocimiento de voz, que cada aplicación (lectores de pantalla, sistemas telefónicos, conversores de texto a archivos de audio etc.) se ocupará de administrar específicamente.

Lo de Taskkill lo había pensado yo hace un tiempo y de hecho en este hilo está, aunque no sé por qué César había dicho que no era una buena idea. Ya esperaremos a que nos ilumine al respecto, pero creo recordar que lo sugerí cuando planteó la necesidad de un script auxiliar que interrumpiera al script de voz responsable de la verbalización. La pregunta que ahora me ronda es, en todo caso, ¿qué hace técnicamente el script auxiliar si no es un Taskkill al que se le pase en una variable sustituida en tiempo de ejecución el "nombre de imagen" del proceso de voz con el parámetro /f para soslayar cualquier potencial confirmación?


Arriba
 Perfil  
 
NotaPublicado: 03 Ago 2015 11:16 
Desconectado
Yiepp
Yiepp

Registrado: 03 Nov 2013 22:56
Mensajes: 69
Hola:

Lo de los eventos en xml... he de reconocer que no soy muy ducho en eso, y que a mi parecer en el estado actual SAPI funciona como debería. Y no, Fernando, yo no conseguí mucho en verdad: la única complicación fue averiguar la forma de saver cuándo SAPI dejaba de hablar. Tuve suerte con JAWS y NVDA, gracias también a la forma de interactuar con los programas de texto a voz que tiene el emulador. Si no hubiese sido tal como es ahora, es decir, una ejecución por cada línea, seguramente sufriría del problema de que los mensajes se pisaran unos a otros tanto en Windows como en Mac.

Respecto al taskkill... buena pregunta, aunque me consta que no es necesario utilizar -f (me cargué NVDA para hacer la prueba y funciona). En fin, cosas de Windows, supongo :) .

Saludos!
P. D.: No se me puede más que escapar una carcajada al ver que Fernando utiliza mi nick y César mi nombre...


Arriba
 Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 166 mensajes ]  Ir a página Anterior  1 ... 8, 9, 10, 11, 12  Siguiente

Todos los horarios son UTC + 1 hora


¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 7 invitados


No puede abrir nuevos temas en este Foro
No puede responder a temas en este Foro
No puede editar sus mensajes en este Foro
No puede borrar sus mensajes en este Foro

Buscar:
Saltar a:  
Desarrollado por phpBB® Forum Software © phpBB Group
Traducción al español por Huan Manwë para phpBB-Es.COM