PolySnd - Page 48

Pour ce qui est de la méthode 2 elle est plus rapide.

Ben demande à Brunni qu'il adapte son convertisseur de manière à produire un code utilisable avec la deuxième option...

Dans ce cas je te le demande, j'espère que ce n'ai pas trop compliqué à faire, le mieux dans le convertisseur serait de choisir son format.

Je pense me remettre à coder ma librairie dans peu de temps et mettre en pause mon palyer, toute façon le player est presque terminé.

#1409 : je suis d'accord sur se point, mon affirmation de mon point de vu me parrait juste mais j'aimerait bien voir quand meme des tests

il n'y a absolument aucune raison que la méthode 2 ne soit pas valable et elle poste plus a compression que la 1 (en tte logique) d'ailleur pour info cette méthode est utilisé dans certain type de transmition fillaire (1 = changement d'etat, 0 = rien ne change)

Elle est valable, mais je ne pense pas qu'il y ait un intérêt à l'utiliser. De plus, elle n'est pas valable dans notre cas (geogeo et moi), car mon convertisseur fournit des données qui sont prévues pour être utilisées avec la méthode #1 car elles représentent justement l'état courant auquel devrait être le port.
A part ça, j'ai été étonné par la qualité du WAV 1 bit (eh oui la pratique n'est pas toujours mortuaire par rapport à la théorie ). Le seul problème est qu'on obtient beaucoup de parasites en 1 bit (normal, de petites oscillations autour du milieu du graphe prennent une ampleur énorme alors qu'elles sont parasitaires dans bien des cas). Mais je vois une solûtion logicielle pour parer à ce problème; je l'intégrerai peut-être à mon convertisseur, reste à voir ce que ça vaut

oui si il faut du traitement sur le son c au niveau du convertiseur, plus le "player" est simple mieux c'est

et a mon avis dans un premier temps tu devrai faire un simple convertisseur "mode 1" a "mode 2"

pour qu'il puisse tester

Je ne suis (heureusement) pas obligé d'envoyer le résultat à geogeo pour mes tests. J'ai mon propre lecteur WAV pour TI tout con (extraction bits en boucle et mise de la valeur sur le port) et je teste ça ainsi. Imagine s'il y avait des bugs à corriger... ce serait impossible (je lui enverrai tout le temps de nouvelles bêta test et tout et tout)

Je ne suis (heureusement) pas obligé d'envoyer le résultat à geogeo pour mes tests.

Je n'ai pas encore crée les routines de gestion 1 , 2 et 4 bits mais seulement 1 bit, je n'ai pas trop de temps en ce moment mais ej compte mis mettre ce soir.
Je sais ça ne ce fait pas de ne pas teste run prog à fond or je ne pouvais pas, excuse moi. Dans tou les cas j'ai aussi pensait à une autre fonction qui risque de prendre du temps aussi, elle permettera de gagner énorméménent de ressource CPU. Cette fonction permettera en quelque sorte de régler le port I/O en mono ou stéréo.

Promis dès que j'ai fait les 3 modes sur les 2 voies je fait des tests pointue...

Parce que ça fonctionne en 2-4 bits?

Le convertisseur je ne sais pas, mais je pense que ça doit fonctionner.
L'algo qui faisait du 4 bits fonctionne très bien mais comme je l'ai dit je n'ai pas fait les fonctions dans PolySnd v2.0 pour gérer les modes....
L'algo pour le son en 2 bits aussi fonctionne.

Je n'ai plus essaye qu'avec les données de Wave2asm.

geogeo
: olalala, déjà avec une version dynamique en C et ASm+ noistub en C et ASm aussi c'est difficile à mettre à jours alors encore une version de plus, là je pete un cable.

Jette la version dynamique! Elle ne sert à rien, tout le monde peut utiliser la version statique.

Bon t'en as pas marre d'essayer d'empêcher les gens de faire ce qu'ils veulent? Il veut faire les deux versions, de quoi tu te plains?

Alors pas de flameware dans ce topic!
-> incident clos (sinon ce seront les posts qui seront clos)

Ximoon
: Bon t'en as pas marre d'essayer d'empêcher les gens de faire ce qu'ils veulent? Il veut faire les deux versions, de quoi tu te plains?

C'est lui qui se plaint d'avoir à maintenir 2 versions (cf. citation), donc je lui propose la solution logique.

et t'en a pas marre de vouloi imposer ton point de vue partout ?

Tu as déjà essayé de le convaincre dans ce même topic, pas besoin de relancer le débat.

Jette la version dynamique! Elle ne sert à rien, tout le monde peut utiliser la version statique.

Bon t'en as pas marre d'essayer d'empêcher les gens de faire ce qu'ils veulent? Il veut faire les deux versions, de quoi tu te plains?

Arrête Kevin de encore relancer un débât qui n'a pas ça place ici. J'ai fait ce choix et je crois avoir bien expliqué pourquoi dans ce topic, ce débat n'a pas place ici.

J'ai fait la fonction qui gére le 1, 2 et 4 bits.
Reste plus qu'à l'optimiser parce que franchement avec des varaibles c'est pas très très rapide.

Brunni> Le convertisseur fonctionne très bien avec du 1 bit et 2 bits mais en 4 bits ça fonctionne pas, les bits de pouids faible me semble privilégié et donc on entend plus des crachouillie plutôt qu'autre chose. J'ai fait juste un test car j'ai pas trop le temps. Je vais voir si ça peut s'améliorer avec les réglages de masques...

Juste pour mettre mon grain de sel, je vais peut-être dire une connerie mais je pense que la méthode 2 (1 = changement d'état, 0 = pas de changement) n'est pas bonne pour du son car si dans un lecteur on souhaite avancer dans une musique on ne connaîtra pas l'état du port à l'instant qu'on souhaite jouer.
On peut donc se retrouver avec les ports à l'inverse de ceux souhaités, si on 'saute' à un endroit où le port est censé être à 1 et qu'il est à 0.

sa dépend comment geogeo fait l'avance rapide mais c'est vrai qu'il y a se pbm mais qu'est-ce que sa va faire dans se cas ? (au niveau son) sa serait a tester..

L'avancement rapide ce fait avec le temps et ici il est pas question du player.
Le player pour l'instant ne joue que le format MIDI.

Juste pour mettre mon grain de sel, je vais peut-être dire une connerie mais je pense que la méthode 2 (1 = changement d'état, 0 = pas de changement) n'est pas bonne pour du son car si dans un lecteur on souhaite avancer dans une musique on ne connaîtra pas l'état du port à l'instant qu'on souhaite jouer. On peut donc se retrouver avec les ports à l'inverse de ceux souhaités, si on 'saute' à un endroit où le port est censé être à 1 et qu'il est à 0.

Heureusement ça ne change rien Ce sont les changements d'états qui créent du son:
-> 0 passe à 1 = 1 passe à 0
-> tout le long 0 = tout le long 1 (= pas de son )
De toutes façons la méthode 2 n'est pas valable, et on ne va certainement pas l'utiliser.

Arrete de dire qu'elle n'est pas valable elle l'est AUTENT que la méthode 1 !

Tu la testé au moins ???

Oui. Au niveau audio ca ne change rien. Au niveau compression ça ne change quaisment rien (au contraire elle est souvent plus volumineuse, bien que parfois elle me permette de gagner cinq ou six octets sur les cinquante ko!)
En plus de ça, la méthode #1 demande moins de CPU que la #2.

Avec ton convertisseur les données 2 et 4 bits ne sont pas correct.
Quand j'essaye avec les données de wave2asm la ça fonctionne bien.

Là je peut affirmer que ça vient du convertisseur car les 2 algos sont identique.

Je vais vous faire des enregistrement ce soir pour comparer et les qualitée et les convertisseur.

Par contre j'ai amélioré l'algo qui sort du 1 bit, sans fconsomer en plus des ressources, le son sera mieux dans des sons avec pas énormément de voies...

Brunni> Il me semble pourtant qu'on peut coder la méthode 2 très simplement, de façon à ce qu'elle demande moins de CPU que la 1

Brunni
: En plus de ça, la méthode #1 demande moins de CPU que la #2.

tu raconte n'importe quoi....

L'algo 1 nessecite sa :

if (bit == 0)
 bitclear(PORT_IO,RED_WIRE);
else
 bitset(PORT_IO,RED_WIRE);

ou en ASM

 tst.b d0
 beq NotSet
 bset #RED_WIRE, PORT_IO
 bra End
NotSet:
 bclr #RED_WIRE, PORT_IO
End:

L'algo 2 nessecite sa :

if (bit == 1)
 bitcchg(PORT_IO,RED_WIRE);

ou en ASM

 tst.b d0
 beq End
 bchg #RED_WIRE, PORT_IO
End:

Alors me dit pas que la méthode 2 consome plus de CPU c'est tres loin d'etre le cas !!


PS: RED_WIRE correspond au bit a changer pour le fil "rouge" du cable TI et PORT_IO correspond a l'addresse du port pour changer l'etat du port IO

Mais on ne change pas qu'un bit à la fois!
J'ai testé le CPU après avoir implémenté ça en C, et je ne suis pas sûr que la méthode que j'aie utilisée soit la meilleure.

geogeo :
Avec ton convertisseur les données 2 et 4 bits ne sont pas correct.
Quand j'essaye avec les données de wave2asm la ça fonctionne bien.

Là je peut affirmer que ça vient du convertisseur car les 2 algos sont identique.

Je vais vous faire des enregistrement ce soir pour comparer et les qualitée et les convertisseur.
Par contre j'ai amélioré l'algo qui sort du 1 bit, sans fconsomer en plus des ressources, le son sera mieux dans des sons avec pas énormément de voies...

C'est bizarre, mais j'avais une idée... Si on faisait deux "sprites" pour notre son? Un qui contient le premier bit et un qui contienne le deuxième? Parce que j'ai testé théoriquement les valeurs sortantes (son 8 bits -> 2 bits)
0-63 -> 00
64-127 -> 01
128-191 -> 10
192-255 -> 11
ce qui est parfaitement logique. Es-tu sûr que tu ne te gourres pas de bit poids fort - poids faible? (en fait je devrais poser cette question à moi car si quelqu'un s'est trompé, c'est moi, mais tu peux toujours inverser)
Il faut toujours que je passe le converto v1.2 sur mon serveur.

tu change deux bits et alors ?

il suffit de mettre bout a bout test et bset/bclr ou bchg

Il y a un truc que j'ai pas compris a ton format geogeo, tu utilise 1 octet pour 1 "frame" de son ????

C'est bizarre, mais j'avais une idée... Si on faisait deux "sprites" pour notre son? Un qui contient le premier bit et un qui contienne le deuxième? Parce que j'ai testé théoriquement les valeurs sortantes (son 8 bits -> 2 bits)
0-63 -> 00
64-127 -> 01
128-191 -> 10
192-255 -> 11
ce qui est parfaitement logique. Es-tu sûr que tu ne te gourres pas de bit poids fort - poids faible? (en fait je devrais poser cette question à moi car si quelqu'un s'est trompé, c'est moi, mais tu peux toujours inverser) Il faut toujours que je passe le converto v1.2 sur mon serveur.

Faut tester.

Moi je peux encore améliorer l'algo mais maintenant tout doti ce passer par le convertisseur et non la librairie, il faut que la librairie travail le moins possible ce qui est le cas ici.

J'ai fait un test avec un 1 en 2000 hz, on peut mettre 4 min dans 64 ko. Le son n'ai pas top mais acceptable. Le seul pb c'est qu'il y a trop de fréquences parasites et je ne voit pas comment les retirer.

Il y a un truc que j'ai pas compris a ton format geogeo, tu utilise 1 octet pour 1 "frame" de son ????

frame=échantillions pour toi?

Bas non, si le mode est en 1 bits, je ferait 8 échantillions par octets. 2 bits = 4 échantillions par octet et 4 bits 2 échantillions.

ok j'avais cru comprendre 1 echantillon par octet, j'ai eu peur

PS: geogeo: tu pourrait m'envoyer par mail le code de la partie wav de polysound stp ? (je te promet de pas la diffuser) je veux voir un truc dessus
merci =

Bas pour le format wave2asm, je peux tester que comme ça donc il y a une très faible modifiation de l'algo.


Brunni voilà un truc pour t'aider avec les bits.

Ici c'est un echantillions de 8 bits

1011 0110

Pour la qualitée 1 bit j'extrait que le bit 7, 2 bits je fait le 7 et 6 et 4 bits je fait le 7,6,5,4 et on passe à l'octet suivant, là je parle du convertisseur.