Pourquoi réinventer la roue ?
Sinon entre 0ms et 15ms, cela reste très jouable.
En MiDi ça doit etre possible, à peu pres.
Il faut que le délai soit de moins de 15 ms.
Si tu veux un conseil qui va te rendre riche : il faut que les notes midi soient envoyés au serveur avant d’etre jouées sur le client. Et que les notes jouées sur le client ne soient que les notes envoyées par le serveur, et de tous les instruments en meme temps.
Comme ça le délai entre les instruments est uniforme, et en utilisant les spécificités du protocol IPv6 sur les flux prioritaires tu devrais pouvoir t’en tirer avec une latence d’environ 15 ms. (m’étonnerais que tu fasses mieux, le net c’est une grosse pourriture, car les backbones sont en ATM, donc un paquets ne transite pas toujours dans le même temps donné).
(mais pour de l’audio c’est peine perdue, j’y avais déjà réfléchi)
j’ai rien compris à l’histoire de no-one mais là où ça me paraît hasardeux, c’est que pour jouer de la musique il faut s’entendre jouer soi même certes mais aussi entendre les autres, le tout dans un mix...donc si moi je joue, il faut que le mix que j’entends soit composé de mon accord plus de la mélodie jouée par le soliste sur mon accord et il faut que le tout me revienne...donc la latence est doublée...au delà de 20 ms environ on a un écho perceptible.
malgré toute la merde de l’IP et de l’ATM je pense que cela reste possible d’obtenir de bonnes performances, y a qu’à voir les softs de voix sur IP, ça marche pas mal. Peut-être que concevoir un modem logiciel pour passer des données midi au dessus d’un moteur de VOIP peut fonctionner, non ?
on peut même imaginer développer ça sur MSN...succès commercial assuré.
j’ai rien compris à l’histoire de no-one
normal
Sinon, pour le VOIP comme pour MSN, aucune chance de passer en dessous de 50 ms de latence.
Rien qu’un téléphone portable a une latence de plus de 20ms.
(question de codage de flux de la voix)
Peut-être que concevoir un modem logiciel pour passer des données midi au dessus d’un moteur de VOIP peut fonctionner, non ?
j’ai vraiment des idées complètement stupides moi desfois....enfin surtout pour le coup du modem puisque on perd tout le bénéfice d’optimisation de la bande passante du midi par rapport à l’audio....je pensais en fait surtout à insérer des paquets de données midi dans le flux VOIP. L’intérêt étant de pouvoir communiquer par la voix avec la même interface, skype ou MSN...
Rien qu’un téléphone portable a une latence de plus de 20ms.
(question de codage de flux de la voix)
bah oui pour de la voix justement mais là le truc est de coder des données midi donc à priori on peut imaginer s’en sortir mieux. N’empêche que pour rendre le sustain m’est d’avis que ça va être chaud.
Oui, je pense surtout que c’est tout un protocole à concevoir.
Et ce n’est pas une mince affaire.
Sans compter que des musiciens qui répètent aiment bien se voir pour communiquer visuellement, ça devient super compliqué s’t’affaire.
Sans vouloir te décourager, en temps réel ça va être très chaud… En fait ça va être impossible.
Il faudrait que tout le monde ait des instruments Midi et ça ne concerne qu’une infime partie des musiciens (combien de bassistes ou de guitaristes ont une guitare Midi ?).
Connais-tu PeerSynth ? www.peersynth.de
C’est un peu la même idée de base, sauf que si mes souvenirs sont bons (le soft étant loin d’être aboutit, j’ai lâché très vite), on joue sur des boucles d’où une importance moindre du temps réel.
A mon avis, plutôt que de penser au jeu en temps réel, tu devrais essayer de faire quelque chose en différé mais agréable.
Ayant moi aussi réfléchi à la question, voilà ce que j’avais envisagé - des fois que ça puisse te donner des idées, de toute façon je ne le réaliserai jamais, j’ai déjà un emploi du temps assez chargé comme ça :
- On commence par un mode brouillon : tout le monde peut jouer sur, mettons, 16 mesures. Tout le monde a le même clic, sur lequel se base la synchro : même si c’est en différé, chaque client est calé par rapport à ce clic à la prochaine boucle.
Quand quelqu’un est satisfait de sa partie, il la fige : sa piste passe en vert, par exemple, ce qui signifie qu’il est prêt à passer à autre chose. Dans le même temps, la version audio de sa partie est transférée aux autres zicos.
Les chanteurs/chanteuses peuvent utiliser un mode d’enregistrement audio direct.
Chacun a accès aux réglages de sa piste et règle son volume et l’eq pour que ce soit proche d’une répèt : impossible de modifier le réglage de la piste d’un autre Zicos.
Seul le master et la balance du volume Midi/Audio est réglable individuellement.
- Quand quelque chose se met en place, on peut conserver et passer à un autre pattern.
- On définit ensuite l’enchainement des patterns comme sur un tracker.
Chacun peut ensuite rejouer sa partie comme il le souhaite, en refaisant une boucle ou bien en rejouant l’intégralité du morceau en temps réel.
Ou bien encore, il peut envoyer un mp3 de sa piste (attention au calage, le MP3 doit pouvoir être recalé et ce décalage se propage aux autres clients)
- Un espace spécial de suggestions permet à chacun de pouvoir faire un essai en changeant la piste d’un autre et de la proposer, histoire de garder le fameux "essaye de faire un truc comme…. sur le couplet A" des répèts.
Dans les suggestions, on peut aussi changer le nombre de mesures d’un couplet, d’un refrain… bref, agir aussi sur la structure.
Voilà, pour les grandes lignes.
En tout cas bon courage, c’est très ambitieux comme boulot !
Edit : bien sûr, un morceau peut commencer directement sur une "suggestion" : quelqu’un envoie un morceau inachevé et chacun peut bosser sur ce qu’il veut, de manière un peu anarchique. Ou bien celui qui a composé peut être directif et bloquer tout le monde sur le couplet par exemple, et balancer des commentaires au fur et à mesure (via une fenêtre de chat). C’est une approche "groupe avec leader".
Pour le Voice Over IP ou MSN ce n’est pas variment comparable car la voix utilise un largeur de spectre ridicule comparé aux instruments. Et pour restituer un son de qualité à travers un flux numérique, il faut tabler sur des ratios importants tels que 1 min = 2 Mo au minimum (un débit 34ko/s pour une piste contrairement à 4ko/s pour de la voix). Bref, l’audio n’est pas le sujet mais le MIDI..
Sache également que le MIDI Over IP est une technologie qui existe déjà et qui est utilisé sur des réseau locaux (LAN) 100Mbps sans difficulté car les temps de latences sont négligeables. Par exemple, il existe des PC Racks 1U sans port MIDI que l’on peut contrôler via le port Ehternet.Mais de là à vouloir utiliser cette technologie sur le Web, il y a encore du chemin à faire sur les architectures réseaux pour réduire la latence même en utilisant l’UDP
J’ai deux liens là-dessus :
http://www.openmuse.org/transport/mip_intro.html
Un peu de code utile
(mais pour de l’audio c’est peine perdue, j’y avais déjà réfléchi)
Oui pour l’insant...
Mais attendez quelques années vous allez voir!
Je connais quelqu’un qui bosse dans la technologie de recherche sur justement le très haut débit wifi, et par plusieurs Gigas/ secondes!!!!!
Il m’avait expliqué un peu… mais moi j’suis nullos là dedant, j’ai retenu grand chose… je sais juste qu’on est à la préhistoire de l’ADSL...
Je dirais que dans quelques années, ont pourra former un groupe, "Franco-Hong kong-New yorkais "
Et pas juste en MIDI! en Audio..!
PS: Mais ne va t-on pas regretter notre bonne vieille salle de répète, avec nos pauses où on buvait un p’tit café ensemble…
les gros débits c’est bien, mais ça ping à combien ? le transfert est-il continu où est-ce que ça marche par paquets qui peuvent arriver dans le désordre ?
Parce que bon, on en est déjà à 20Mb/s pour certaines personnes, théoriquement ce serait déjà possible de faire de l’audio (même si ce serait vite limité ou assez lo-fi). Mais en pratique...
y’a juste une chose que vous oubliez, c’est que acquérir l’audio par la carte son, le compresser ça fait déjà au moins 3 ms.
Le décompresser, et le restituer, ça fait 3 ms de plus, au moins !
Donc ça fait déjà 6 ms de latence (avec les meilleures cartes du marché) sans compter le transport sur la toile.
Car, les réseaux ATM à 80 Gb/s ça existe déjà.
pourquoi tu veux le compresser avec un tel débit ?
bref, retour sur terre : l’idée d’un soft de répèt virtuelle est très intéressante, mais le problème actuel vient des instruments Midi : tout le monde ne joue pas du clavier, n’a pas un instrument midifié, et les convertisseurs Midi entrainenent des délais variables mais surtout très longs sur les basses fréquences : à la basse c’est injouable (j’ai testé pour vous )
Donc finalement le différé c’est pas mal, encore faut-il que ce soit fait avec une interface efficace (qui signale que machin modifie sa ligne sur telle partie du morceau par exemple) et une vitesse acceptable (transferts rapides, streaming et grande réactivité du logiciel).
Ceci dit, si y’a des développeurs que ça intéresse et qui veulent essayer de réaliser ça en opensource, je veux bien participer à la conception, à l’interface et aux tests.
Pour le code, ça ne sera pas possible, par contre.
Oui mais les latences dûes aux conversions A/N N/A sont les mêmes qu’en local, ça ne change rien donc le réseau n’est qu’une couche supplémentaire qui ne modifie pas ces temps. Ces "6ms" seront les mêmes.
Zikinf> Les 20Mo descendants c’est bien pratique mais pour envoyer ce que tu joue, c’est le débit montant qui sera le facteur limitatif. Et pour les plus chanceux d’entre-nous, on ne dépasse pas le 152k
Et pour les plus chanceux d’entre-nous, on ne dépasse pas le 152k
Pour du mono ce serait suffisant. A priori on n’envoie qu’une piste, de toute façon.
Mais bon, oublions cette utopie de temps réel...
Pour Zikinf :
Compresser : parce que c’est comme ça, sur internet on diffuse pas du contenu inutile ;-)
Oui mais les latences dûes aux conversions A/N N/A sont les mêmes qu’en local, ça ne change rien donc le réseau n’est qu’une couche supplémentaire qui ne modifie pas ces temps. Ces "6ms" seront les mêmes.
Oui, sauf que j’espere que quand tu joues en local, tu utilises les option de "zero latency monitoring", qui font que le flux que tu écoutes ne passe pas par le PC :D
Zikinf> Les 20Mo descendants c’est bien pratique mais pour envoyer ce que tu joue, c’est le débit montant qui sera le facteur limitatif. Et pour les plus chanceux d’entre-nous, on ne dépasse pas le 152k
Faux, au moins 384 avec free. Et d’où la compression
Compresser : parce que c’est comme ça, sur internet on diffuse pas du contenu inutile
Oui bon tu peux faire une compression vectorielle si ça te branche, mais pour les trucs style MP3 c’est impossible : frames + gros calculs = grosse latence.
Et on est toujours dans l’idée d’un réseau parfait, évidemment avec un système comme TCP t’as plutôt intérêt à avoir le moins de paquets possibles.
Enfi bref, oulions ces délires : il faut faire du différé, je crois qu’on est tous d’accord là-dessus non ?
Tiens au fait il est parti faire un barbecue l’auteur du thread ?
Faux, au moins 384 avec free. Et d’où la compression
Désolé je voulais taper 512k
Enfi bref, oulions ces délires : il faut faire du différé, je crois qu’on est tous d’accord là-dessus non ?
A 100%. C’est pour cela que le seul intérêt que j’y vois pour le moment c’est enregistrer sans se déplacer en studio
Faux, au moins 384 avec free
oui, enfin free...entre ce qu’ils annoncent et ce que t’as et à condition que la freebox tombe pas en panne....
faut voir que aujourd’hui les 8 Mo et les kbits en upload sont en partie destinés à la voix et à la visio, c’est pas ce que tu obtiens par l’internet.
Sinon le gros problème quand on pense élargir la voix sur paquets à la musique, par l’accroissement futur de la bande passante et tout, c’est que les algorithmes d’annulation d’écho saccagent la musique. (on commence à avoir le problème avec certaines attentes téléphoniques dans les sociétés équipées de PABX pour voix sur IP)
tiens, je viens de voir ca sur macmusic… c’est pas exactement la même chose que proposé mais ca s’en rapproche:
www.source-elements.com/Source-Connect/
en fait, personne ne s’interresse vraiment à la question posée : le temps d’erreur admissible.
alors je me lance. Prenons le cas le plus défavorable, où on joue très vite.
Mettons 180 à la noire. Des doubles-croches à 180 ça fait 4 notes par temps, soit 720 notes à la minutes, ce qui représente 60/720*1000 = 83 ms.
Soit une note toute les 83 ms.
Donc je pense que l’on peut admettre 83/2 comme erreur, soit 40 ms.
le but, c’est pas de jouer "pas décalé" c’est de jouer ensemble.
Peut importe le tempo, un decalage est un decalage, et en l’occurence, un musicien qui joue 20ms avant ou apres, ça s’entend tres tres bien.
Vi surtout que comme on s’entend fatalement en local et par le mix retour, il se trouve que 20 ms suffisent pour provoquer un echo perceptible, quel que soit le tempo.
vous vous basez sur quoi pour prétendre que 20 ms ça "s’entend très très bien ?"
parce que je peux dire aussi que 3 us ça s’entend aussi.
l’experience, tout simplement l’experience.
C’est bien beau de pouvoir ecrire des lignes et des lignes de calculs, mais l’important en physique, c’est d’interpreter les resultats et d’avoir un peu de recul.
vous vous basez sur quoi pour prétendre que 20 ms ça "s’entend très très bien ?"
ben en fait tu regardes les pédales de delay et les réverbes… disons que aux environs de 20ms t’as un effet de réverbe voir d’écho.
Ouaip a 180 BPM 20 ms correspond a la durée d’une quadruple croche (cf tableau des delay: https://www.zikinf.com/rec/tableau_delay.php
Donc si on prends la peine de noter les quadruples croches dans les partitions ca doit s’entendre...
mon expérience à moi c’est mon métier d’ingénieur en génie logiciel qui me dit que l’on ne commence jamais à faire un logiciel par les détails techniques d’implémentation, et ni par des contraintes subjectives !!
D’abord on commence par ce que l’on veut, ensuite on établit les contraintes le moins empiriquement possible, ensuite on commence la conception, et enfin seulement on envisage l’implémentation.
Pour l’instant on en est à établir les contraintes/spécifications; et se fixer une contrainte aussi pointue que "20 ms de temps de réponse" sur un logiciel temps réel par réseau, sous des systèmes d’exploitation grand public, c’est vraiment TRES contraignant. Pourquoi ? tout simplement parce que sous Windows (par exemple) le temps minimum de réaction communément admis pour les logiciels conventionnels est 30-40 ms, mais c’est du domaine de l’implémentation
Mais revenons-en au problème de base, il vous plaît pas mon petit calcul ? il montre pourtant le delta mini qu’il peut y avoir entre deux notes, a priori, et en gros, je vous l’accorde.
aïe, les posts se sont croisés, alors ok pour les 20 ms, mais ça me semble vraiment très peu, j’essaierai avec Guitar pro de faire sonner deux impacts de caisse claire par exemple décalés de 20 ms, pour voir.
comme dit Jeanflo ca te creera un petit effet de reverb, certainement que pour entendre une quadruple croche il faut etre un musicien experimente (moi j’ai deja du mal a localiser le contre temps d’une croche ) mais bon...
mon expérience à moi c’est mon métier d’ingénieur en génie logiciel qui me dit que l’on ne commence jamais à faire un logiciel par les détails techniques d’implémentation, et ni par des contraintes subjectives !!
Non, on commence par un cahier des charges, et le temps de latence doit y figurer.
tout simplement parce que sous Windows (par exemple) le temps minimum de réaction communément admis pour les logiciels conventionnels est 30-40 ms, mais c’est du domaine de l’implémentation
Windows n’est pas fait pour le temps réel, c’est sur (pas plus que linux ou BSD), mais de nombreux processus tournent avec une latence de moins de 5ms, il n’y a qu’à commencer par tout ce qui est cubase, logic audio, pro tools.....
Il n’y a pas de secret, quand on fait de la musique, on ne fait pas des mathémtiques. La musique c’est avant tout subjectif, et c’est donc empiriquement qu’on définit les parametres, et non mathématiquement.
hih ça me fait hurler de rire ton post :
sans vouloir te vexer :
on ne commence jamais à faire un logiciel par les détails techniques d’implémentation, et ni par des contraintes subjectives !!
bon on t’a expliqué dans le post croisé que ce délai n’avait rien de subjectif et tu as l’air convaincu à présent. Ceci dit, avant les détails techiques d’implémentation (mot non français qui ne veut rien dire à éviter siouplait messieurs les softeux) on fait en général une étude faisabilité. A l’issue de cette étude dont on dégage un certain nombre de contraintes telles que ce fameux délai on parvient à déterminer la meilleure structure, et ça évite souvent pas mal de bugs et d’efforts de redesign. Mais je pense qu’on est d’accord là dessus !
Pour l’instant on en est à établir les contraintes/spécifications; et se fixer une contrainte aussi pointue que "20 ms de temps de réponse" sur un logiciel temps réel par réseau, sous des systèmes d’exploitation grand public, c’est vraiment TRES contraignant
.
ah mais on a jamais dit le contraire n’empêche qu’il faudra faire avec !
Pourquoi ? tout simplement parce que sous Windows (par exemple) le temps minimum de réaction communément admis pour les logiciels conventionnels est 30-40 ms
en fait c’est là que j’ai hurlé de rire....windows...réaction ? 40 ms....desfois mon sablier il tourne pendant 10 secondes lorsque je clique sur agrandir la fenêtre....
bon y en a même qui font du temps réel sous des OS windows embarqués mais quand même...
vous vous basez sur quoi pour prétendre que 20 ms ça "s’entend très très bien ?"
Regarde nous sommes plusieurs à avoir donné à peu près la même réponse (j’avais dis < 15ms), donc il y a une logique dans nos réponses.
Pour ma part c’est l’habitude de jouer avec des instruments et effets virtuels et quand la latence deviens > 15ms cela devient génant.
Remarque : cela s’applique aux instruments avec un attaque franche pas pour les pads par exemple.
Autre remarque : La latence fait bien parti des contraintes d’utilisation qui doivent être écrites dans le cahier des charges initial.
eh bien, je vois que je suscite des réactions !
Alors, "détail technique d’implémentation", ça veut bien dire quelque chose… mais on va pas faire un cours de Génie Logiciel. Ca va être par exemple les règles de codage, etc…
Pour le temps de latence, je suis d’accord avec vous, il doit figurer dans les spécifications logicielles. Cependant je maintiens qu’il est possible de le calculer. Et au risque (d’encore plus) choquer certains, je me permettrai de citer ChaiPluKi : "la musique, c’est les maths qui chante".
Maintenant les fameuses 40 ms… On s’enflamme pas les gars. Dans le cadre de Windows, le time slice alloué à chaque thread est de 10 ms.
Ce temps de 40 ms correspond à ce que l’on peut espérer dans le cadre de communication inter-thread. Exemple, il est difficile de faire des timer logiciel à moins de 40 ms. Et dans le cadre de ce logiciel, il y aura a priori ce genre de com : ce que l’utilisateur joue, et ce que les autres font.
Mais bon, tout ça est sans grande importance puisque l’auteur du post n’a pas réagi !
[/b]
Maintenant les fameuses 40 ms… On s’enflamme pas les gars. Dans le cadre de Windows, le time slice alloué à chaque thread est de 10 ms.
Ce temps de 40 ms correspond à ce que l’on peut espérer dans le cadre de communication inter-thread. Exemple, il est difficile de faire des timer logiciel à moins de 40 ms. Et dans le cadre de ce logiciel, il y aura a priori ce genre de com : ce que l’utilisateur joue, et ce que les autres font.
Je n’aurais jamais pensé discuter de ça ici :lol:
Il existe des timers multimedia sous Windows qui permettent d’obtenir des précisions un peu plus fines. (j’ai bien dit un peu, on est sous Windows quand même :P)
Pour ton calcul, ce que tu ne comprends pas c’est que tu t’es basé sur la rapidité de jeu maxi… Ce n’est pas important (mis à part pour le calcul de débit maximum). Ce qui est important c’est le temps écoulé entre l’évênement NOTE-ON sur le clavier commandeur et le déclenchement du son sur le client à distance, autrement dit, le temps de réaction du système informatique. Si tu veux vraiment t’amuser à calculer ça mathématiquement, tu dois tenir compte du temps de réaction de l’oreille humaine et la vitesse de propagation des informations dans le cerveau pour trouver la valeur qui rendra la latence négligeable. (ou alors je n’ai pas compris ton explication et je m’en excuse)
Sachant qu’il faut multiplier ce temps par 2. Car si le 1er zikos "A" est un batteur qui joue son petit pattern sur sa batterie MIDI et que le second est un guitariste "B" à distance. Quand le guitariste joue son riff, il le joue sur une partie de drums avec un temps de latence (A > B) et le batteur recevra le retour du batteur avec les deux temps de latences cumulés (A > B > A).
Donc si le temps de latence minimum pour un jeu agréable est de 20ms, alors il faut que les données transitent de pair à pair en moins de 10ms (on est mal).
en fait ablaze l’a dit, ce qui est important c’est la durée de l’attaque.
c’est en effet l’attaque d’un son qui contient le contenu harmonique permettant de déterminer un instrument : si on écoute un son en prenant uniquement le sustain on est incapable de distinguer un violon d’une clarinette. C’est peut-être dur à croire mais c’est surtout que l’expérience est dure à réaliser, mais essayez avec votre soft de wav, vous verrez bien (noter que de toute façon l’oreille percevra une attaque neutre)
donc le truc c’est que si une attaque de note arrive retardée pendant le sustain de la note simultanée, et bien on a l’impression qu’une seconde note vient d’être jouée.
donc le délai acceptable doit être situé à une certaine portion de la durée d’attaque.
Wouaou !!!!
J’avais enormement de boulot ces derniers temps puisque j’ai un document a taper pour ce fameux logiciel. J’en avais un peu oublier ce post
Apres que ce me soit subitement revenu a l’esprit, je suis venu voir si j’avais au moins une reponse ou deux qui pourrait se reveler interressante...
Et la !!!! , 4 pages de debats enflammes avec des arguments technique et plein d’idees pour mon logiciel Merci merci ! J’en demandais pas tant !!!! Je vais soigneusement lire tout ca et essayer d’en retirer le meilleurs conseils...
Merci merci a tous, je vous tiens au courant quand j’ai un peux plus de temps.
Au fait, un truc qui pourrait vous interresser. J’ai fait des tests de base sur un reseaux local: je branche un clavier MIDI sur mon ordi, je joue et ca sort le son sur un autre ordi du reseau. Resulat: de 0.1 a 0.3 milisecondes de delai… Il me semble donc que ca devrait au moins marcher en local !! Et si ca marche en local maintenant, ca marchera probablement sur internet dans quelques annees… le temps que les debits augmentent
Merci encore, je reviens bientot quand j’aurais plus de nouvelles
Haut |