No me estoy acordando mal, solo soy de la vieja escuela ![]()
Esto se añadió hace apenas 10 años en Mumble 1.3, cuando Mumble ya tenía más de 10 años.
Fue la principal queja sobre Mumble durante mucho tiempo.
No me estoy acordando mal, solo soy de la vieja escuela ![]()
Esto se añadió hace apenas 10 años en Mumble 1.3, cuando Mumble ya tenía más de 10 años.
Fue la principal queja sobre Mumble durante mucho tiempo.
Acabo de estar probando con esto y ¡es genial! Quería darles algunos comentarios iniciales.
Lo probé, pero no muestra el volumen del compartir pantalla de los otros participantes por separado de su volumen de voz. Solo muestra un deslizador combinado para su voz y el audio del compartir pantalla. ¿Se me escapó algún deslizador o lo entendí mal? (Mi caso de uso es poder silenciar o bajar el volumen de la transmisión de juego de alguien, pero seguir escuchando cómo habla.)
En cualquier caso, gran trabajo con esto: es un gran paso adelante para Discourse y ¡estoy muy emocionado por ello! ![]()
Hemos recibido mucho gran feedback, solo quiero resaltar algo
Este ha sido mi principal reto hasta ahora, y afecta a todas las plataformas, ya que es imposible transmitir mis sesiones de juego a 7680x2160@240Hz a través del navegador, que carece de codificación por hardware.
Por lo tanto, estoy explorando la gestión de esto, así como funciones como PTT global, mediante una aplicación de escritorio nativa, que nos permita gestionar mejor estas integraciones.
Gracias; la aplicación de escritorio nativa suena intrigante, pero por favor también soporten los estándares de streaming abiertos existentes, ya que al menos en mi grupo de amigos, todos ya tienen OBS instalado, confían en él y saben cómo configurarlo para transmitir. (Admito que esto es más común entre los jugadores que entre otros usuarios menos técnicos)
(Edición - solo para aclarar, la aplicación nativa también suena genial. Tener todos mis foros en una sola interfaz sería muy útil)
En cierto modo, estoy de acuerdo contigo, en el sentido de que no es Zoom. Pero también me permito discrepar un poco, porque por suerte OBS es un estándar utilizado en muchos campos.
Tuve un pequeño problema en la reconstrucción de hoy porque antes había probado el plugin con el nombre ‘Resenha’, que por cierto me entristeció bastante cuando lo cambiaron a ‘Voice’.
Esto resolvió mi problema:
Ahora, sobre el propio plugin, me di cuenta (y quizás sea solo una impresión mía debido a la recompilación tras casi dos semanas con más de 300 commits) de que algo me hizo aparecer en #quién-está-en-línea cuando probé el audio en mi instancia, incluso aunque el conmutador estuviera definido en ‘Desconectado’. ¿Es el comportamiento esperado?
Esto debería corregirse pronto: FIX: Do not overwrite permissions after editing - Pull Request #43496 - discourse/discourse - GitHub
¿Es posible mostrar en nuestra página alojada > acerca de > actividad del sitio (por ejemplo) 5 chats de voz de los últimos 7 días? O cualquier otra redacción que sea apropiada.
Nuestro caso de uso es mostrar la mayor cantidad de actividad posible para ayudar a que nuevos miembros se unan.
¿Podríais invitar a grupos a una sala de voz en lugar de a usuarios individuales? Entiendo que eso puede complicarse en la página de miembros si tienes que eliminar a alguien que sigue perteneciendo a ese grupo, etc.
Vamos a implementar esto en algunos proyectos activos orientados al cliente que tenemos en marcha, pero son 17 grupos con personas totalmente distintas ![]()
Sí, esta es básicamente la razón por la que funciona así.
Si quieres restringir toda la función a los miembros de esos 17 grupos, es posible hacerlo mediante la configuración del sitio, pero la invitación de un solo uso es por usuario (es demasiado fácil que se convierta en una amplificación del spam) y la membresía de la sala en sí también es por usuario (mantenerla sincronizada con los grupos sería una mejora para el futuro).
Totalmente de acuerdo. Tampoco parece haber forma de hacerlo a través de la API ![]()
¿Me estoy perdiendo algo con el método del enlace de invitación? Compartí el enlace con una cuenta de prueba que está en los grupos aprobados, pero cuando intento hacer clic con mi usuario de prueba, aparece ¡Ups! Esa página no existe o es privada.
Actualización: O sea, incluso si invito a ese usuario y veo el canal de voz en la barra lateral, al hacer clic en el enlace me lleva a esa página de error.
Ya manejamos parte de esta lógica para agregar y quitar personas de los canales de chat, si el canal está asociado con una categoría privada.
Falco, no recuerdo si ya tenemos una forma de asociar un canal de voz con un canal de chat o no. Sé que lo discutimos en el pasado con los mensajes directos. Pero eso podría ser un enfoque aquí.
Alternativamente, podríamos copiar lo que estamos haciendo para los canales de chat y permitir que las categorías actúen como la capa de control de acceso (aunque sé que hemos discutido a menudo eliminar esa capa de indirección y permitir establecer el acceso directamente a nivel de canal).
Si también deseas restringir la función completa a un conjunto de grupos, creo que eso aún tendría que gestionarse mediante la configuración del sitio. Un flujo de trabajo podría ayudar a gestionar cierto nivel de automatización o verificación de coherencia para ello, quizás.
@martin esto podría tener cierta superposición con lo genérico de control de acceso en lo que has estado trabajando.
Podría ser valioso ponerse al día con @awesomerobot sobre hacer un empuje más amplio con eso pronto para que podamos pensar en cómo aplicar ese aspecto de las cosas de manera más consistente en toda la aplicación.
Eso es raro, ¿están esos usuarios de prueba en algún estado raro, como en un nivel de confianza que no permite el acceso?
Sí, eso está en la hoja de ruta.
Definitivamente no fue un impedimento para el lanzamiento, y es una parte tan enrevesada de la aplicación que nuestros esfuerzos podrían usarse mejor para acertar con lo fundamental del audio y el vídeo, pero algo en lo que seguiré trabajando en los próximos meses.
Respondí en dev, pero el nuevo sistema de ACL debería ser genial para esto, en lugar de usar la antigua y enrevesada herencia de permisos por categoría ![]()
No creo que sea así. Acabo de subir a mi usuario de prueba al TL3, así que definitivamente no es una restricción de TL. Algo del propio enlace de invitación parece estar roto. Miren lo que pasa al acceder a él de la manera habitual (el enlace se comporta de la misma manera, tenga o no mi usuario acceso).
Lamentablemente, estos grupos solo funcionan a través de mensajes directos, por lo que no hay un vínculo por categoría al que recurrir.
Creo que compartir un enlace de invitación en un mensaje directo será suficiente una vez que figuremos por qué no está funcionando ![]()
He notado que cada vez que me uno a una sala de voz con el tipo de sala configurado como abierto, el usuario activa automáticamente su micrófono. Esto también ocurre cuando un orador se une a una sala de voz de escenario. Me pregunto si es posible permitir que el administrador establezca si el micrófono debe activarse automáticamente al unirse.
¿No resultaría confuso?
Las aplicaciones de reuniones de “trabajo”, como Zoom, Teams y Meet, tienen esta característica cuando se supera un umbral de participantes, pero este nunca fue un comportamiento en las aplicaciones de las que nos inspiramos, como TeamSpeak, Ventrillo, Mumble, Discord, etc.
Siento que este paso adicional no tiene mucha precedencia y parece un paso extra que complica aún más la experiencia de usuario para los principiantes.