PolySnd - Page 46

C'est bon!
http://www.isuisse.com/brunni/converti.zip

(je ne sais pas si c'est correct, mais c'est ce que j'ai cru comprendre. J'ai mis une tabulation avant et après dc.b, les éléments sont séparés par des espaces.

Avant il au faut au minimum un espace et après aussi bien sûr mais je préfére dans mon cas et nombreux sont les personnes, utiliser des tabulations en ASM.

Sinon gt venu ici pour annoncer qu'IL EST TERMINE! Et oui! C'est bon, ça marche pour le C ET l'ASM! Et avec 10 codes par lignes:

Je vais pouvoir savoir si mon algo de WAV fonctionne niquel et faire des testes...

Oui mais moi je ne sais pas si mon prog fonctionne niquel... Je n'ai pas les moyens de tester le 2 bit et plus (enfin oui j'ai testé manuellement en comparant les valeurs avec ce qu'elles devraient valoir et ca a l'air bon)
Sinon il fonctionne chez toi? Essaie de t'amuser avec, il y a des petits détails marrants. Clique sur un élément pour obtenir une description dans l'aide à droite. Clique dans l'aide pour savoir ce que c'est Clique dans le nom de fichier en haut pour charger un fichier. Il ne supporte pas (encore) les lignes de commande (pas de nom de fichier en argument donc).
Ah oui! Et les bits sont nommés de 1 à 8. Une valeur 0 ou rien indique que le bit n'est pas utilisé. Tu vas te marrer si tu rentres une valeur pour le bit 3 mais pas pour le 2

Un petit bug dans la convertion en C. Tout à la fin de la liste on obtient:
0x4F, 0xDC, 0x0A, 0x3F,
};

Ca provoque bien sûr une erreur de compilation et plante TIGCC.

Aussi en ASM à la fin aussi: dc.b $4F, $DC, $0A, $3F, $
Et l'extension du fichier et c au lieu d'être asm.

1. L'orthographe correcte est giocatore avec un seul c.
2. Ce mot n'est pas vraiment ce qu'un italien utiliserait pour parler d'un programme qui fait de la musique.

Ah oui. Mais
liste[]={
blabla,
patati,
[...]
patata,
};
Ca marche chez moi...
Pour l'extension je vais corriger.

Ca veut dire quoi?

Kevin Kofler :
1. L'orthographe correcte est giocatore avec un seul c.
2. Ce mot n'est pas vraiment ce qu'un italien utiliserait pour parler d'un programme qui fait de la musique.

Je ne sais pas pourquoi mais je m'en doutais également

geogeo :
Un petit bug dans la convertion en C. Tout à la fin de la liste on obtient:
0x4F, 0xDC, 0x0A, 0x3F,
};
Ca provoque bien sûr une erreur de compilation et plante TIGCC.

Tu utilises quelle version? char liste[]={0x4F, 0xDC, 0x0A, 0x3F,}; compile sans problèmes avec GCC.EXE (GCC) 3.3.1 20030623 (TIGCC prerelease) (pre18).

geogeo
: Ca veut dire quoi?

Si tu te réfères au message n°1355: giocatore = joueur, mais au sens de quelqu'un qui joue à un jeu ou pratique du sport (par exemple giocatore di calcio = joueur de foot = footballeur), pas d'un musicien qui "joue" de la musique (on ne parle pas de "jouer" de la musique en italien, on dit suonare musica (littéralement "sonner de la musique")).

Le musicien, c'est un musicista, pas un giocatore.

OK j'ai compris Kévin! J'ai changé le nom maintenant!
http://www.isuisse.com/brunni/converti.zip
J'ai corrigé deux ou trois bugs.

Je viens d'essayer la version d'avant.
J'ai juste fait un test en 1 bit avec un masque de 8 et ça fonctione pas, le fichier me semble trop petit comparé à ce que faisait sound.exe. J'ai comparé les données et le début et correct mais vers la fin ou je ne sais ou c'est plus ça.

Bizarre... Il y a peut-être un bug dans la conversion HEX... Moi j'ai testé et du début à la fin j'ai bon (sauf que j'ai 1 octet de plus avec Sound.exe)
Je n'ai pas testé avec mon prog de lecture (je vais le faire) mais manuellement (avec la ti et les nombre 0h et 0b!)
J'ai testé sur un fichier de 5 sec. Le fichier de sortie est naturellement plus petit du au format hexa. Sound.exe utilise du binaire!

Voici avec quoi j'ai essayé:
http://perso.wanadoo.fr/tisofts/divers/will.wav

Sur TI il fait 1387 octets avec du code, ça me paraît extrêment petit pour 8 sec.
L'octet que tu as en plus vient de la , à la fin. Je pense qu'il serait quand même mieux d'enlever cette virgule.

Je vais reessayer.

dc.b $4F, $DC, $0A, $3F

Surtout ne met pas d'espace après les virgules. TIGCC ne le détectera pas comme une erreur il me semble.

geogeo
: L'octet que tu as en plus vient de la , à la fin.

Non.
char liste[]={0x4F, 0xDC, 0x0A, 0x3F,};
est compilé en:

liste:
	.byte	79
	.byte	-36
	.byte	10
	.byte	63

Pas d'octet supplémentaire.

C'est donc pour ça en ASM.

En C je viens d'essayer et ça fonctionne. Mais en ASM, le compilo doit prendre que le première octet par ligne.

Nerick
:

dc.b $4F, $DC, $0A, $3F

Surtout ne met pas d'espace après les virgules. TIGCC ne le détectera pas comme une erreur il me semble.

A68k plutôt, mais à part ça tu as raison.
D'ailleurs, ça serait bien de voir l'assembleur GNU supporté. Syntaxe:
.byte 0x4f,0xdc,0x0a,0x3f
Et il me semble que GNU as comprend les espaces. Pourquoi tout le monde utilise-t'il encore l'assembleur obsolète qu'est A68k? GNU as est généralement mieux que A68k. À l'époque où j'ai fait la chasse aux bogues dans A68k, il avait encore des avantages (GNU as ne permettait pas encore incbin, par exemple), mais ce n'est plus vraiment le cas maintenant.
A68k a aussi des tas de limitations arbitraires (32766 lignes maximum etc.). J'ai augmenté les valeurs de certains de ces maximums, mais ce sont toujours des maximums fixés arbitrairement.

GNU AS est maintenu par qui au fait ?
Personnellement, je trouve que la syntaxe de A68k est plus légère, moins chargée.

Brunni> Tu devrais numéroter les bits de 0 à 7, c'est plus conventionnel

Au faite le fichier généré et par exemple will.wav.c le mieux serait will.c ou will.asm

jackiechan
: GNU AS est maintenu par qui au fait ?

Par ces gens-là: http://sources.redhat.com/binutils/.
Quant au portage TIGCC, c'est maintenu par moi, mais il n'y a pas eu grand chose à faire.

Personnellement, je trouve que la syntaxe de A68k est plus légère, moins chargée.

--register-prefix-optional, c'est pour les chiens?

Kevin Kofler :
--register-prefix-optional, c'est pour les chiens?

Pour ExtGraph, j'ai été obligé de me plier à l'autre syntaxe.

Sinon, est-ce que tu peux me dire ce qu'il a de plus que A68k, et ce que A68k a de plus que GNU AS, ou bien m'indiquer où trouver ces informations (sans avoir à éplucher leur docs entières si possible). Merci

jackiechan
:

Kevin Kofler :
--register-prefix-optional, c'est pour les chiens?

Pour ExtGraph, j'ai été obligé de me plier à l'autre syntaxe.

Plains-toi chez Lionel.
Non, sérieusement, il a raison, parce que TIGCCLIB n'est pas compilée avec --register-prefix-optional non plus (et qu'il vaut mieux commencer tout de suite à suivre les mêmes conventions).

Sinon, est-ce que tu peux me dire ce qu'il a de plus que A68k, et ce que A68k a de plus que GNU AS, ou bien m'indiquer où trouver ces informations (sans avoir à éplucher leur docs entières si possible). Merci

Je ne pense pas qu'une comparaison point par point existe.
La différence probablement la plus importante est au niveau des optimisations: GNU as a une optimisation des branchements et absolu->PC-relatif généralement meilleure (par exemple, on peut utiliser jbne pour avoir non seulement du bne.s ou du bne.w, mais aussi du beq.s skip;jmp;skip:, et puis GNU as optimise aussi les références à l'avant absolu->PC-relatif, A68k seulement celles en arrière), mais A68k a d'autres optimisations, de style move->moveq, adda.l->lea etc. (cf. documentation), pour lesquels GNU as attend en général de toi que tu sais quelle instruction tu veux utiliser.
Il y a aussi les limites arbitraires de A68k qui n'existent pas sous GNU as (du moins pas sous cette forme).
Autre différence: La taille d'une section sous A68k est toujours multiple de 4, sous GNU as, elle ne l'est pas forcément (et dans la version patchée pour TIGCC 0.95, elle ne sera même plus forcément paire! Le nouveau linker rajoute du padding pour toutes les sections sauf pour la dernière; la table de relogements au format AMS peut donc se trouver à une adresse impaire comme explicitement prévu par EX_patch).
Comme tu vois, les différences sont surtout des détails comme ça.

Donc on perd en lisibilité pour finalement pas grand chose c'est ça ?

Geogeo! Tu utilises la vieille version! Utilise la nouvelle avant de te plaindre!
Et sache que ça n'a pas été facile de la faire ton app! Parce que perso je n'y ai aucun intérêt, je l'ai faite pour toi, et c'est tout juste si tu me dis pas que c'est nul...
-------------------------------------------------------------------------------------------
Bon, j'ai corrigé un paquet de ces bugs;
dans la version 1.2, il y aura en plus:
la possibilité de faire des sauts plus petits (exemple : "/4" saute un octet sur quatre, donc donne du 6 kHz)
-le support ligne de commande
-le fichier est automatiquement ouvert avec le bloc-notes à la fin
à part ça la version 1.1 (disponible):
-extensions .c, .asm ->will.c, will.asm
-plus de virgule en trop

geogeo:> Tu dis que tes fichiers convertis ne fonctionnent pas... C'est bizarre, j'ai fait des essais de 5 à 60 ko et j'ai jamais eu aucun problème (au contraire la qualité est superbe). A mon avis, c'est ton algo qui est faux. Essaie de repartir sur la base du mien (plus simple tu meurs), car là ça marche niquel.
En plus de ça, la conversion est largement plus rapide qu'avec Sound.exe, la compilation est impressionnemment plus rapide (plus de 2 minutes -> moins de 10 secondes pour 60 ko de code)
Téléchargez ici

Geogeo! Tu utilises la vieille version! Utilise la nouvelle avant de te plaindre! Et sache que ça n'a pas été facile de la faire ton app! Parce que perso je n'y ai aucun intérêt, je l'ai faite pour toi, et c'est tout juste si tu me dis pas que c'est nul...

Je t'assure je suis vraiment content de ce convertisseur car il est vraiment pratique et surtout on peut tout régler. Mais bon c'est aussi pour le distibuer et donc malheuresement tout progs n'ai pas parfait et donc il faut améliorer.

Et sache que ça n'a pas été facile de la faire ton app! Parce que perso je n'y ai aucun intérêt, je l'ai faite pour toi, et c'est tout juste si tu me dis pas que c'est nul...

Je le sais bien et je t'en remercie. J'ai pas dis que c'est nul bien au contraire mais juste qu'il faut 2 petites améliorations.

Geogeo! Tu utilises la vieille version! Utilise la nouvelle avant de te plaindre!

Hier quand tu as écrit le post #1361 le fichier que j'uploadé était identique à la version précédente en date et contenu et donc je n'ai pas osser te le dire, donc je me suis dit que j'allais tester cette version aujourd'hui.

geogeo:> Tu dis que tes fichiers convertis ne fonctionnent pas... C'est bizarre, j'ai fait des essais de 5 à 60 ko et j'ai jamais eu aucun problème (au contraire la qualité est superbe). A mon avis, c'est ton algo qui est faux. Essaie de repartir sur la base du mien (plus simple tu meurs), car là ça marche niquel. En plus de ça, la conversion est largement plus rapide qu'avec Sound.exe, la compilation est impressionnemment plus rapide (plus de 2 minutes -> moins de 10 secondes pour 60 ko de code)

Comme tu le sais je met à jours souvent polysnd2 et comme j'ai 4 versions à suivre dans les header et source (dynamique/ C |ASM et statique/ C|ASM) ce n'ai pas faicile toujours de s'y retrouver correctement donc je préfére pour tester ma librairei faire des tests en ASM, or dans ton programme qui donné des données en ASM on obtenait un octet par ligne, j'ai donc fait un test en C et là ça fonctionné très bien. cf #1367

j'ai fait des essais de 5 à 60 ko et j'ai jamais eu aucun problème (au contraire la qualité est superbe).

Donne moi les fichiers avec ce genre de qualitée ou essaye de nous faire écouter un enregistrement.Je ne dis pas que tu as tort mais je veux juste dire que ça ne marche pas dans tout les cas surtout les fichiers WAV qui contiennent plusieurs instruments....

Tu as testé sur TI avec ton algo en C du jeux tetrisse?

Essaie de repartir sur la base du mien (plus simple tu meurs), car là ça marche niquel.

Je crois pourtant l'avoir dit, en 1 bit voici ce que je fait:

Si bit en cours et à 1 impulsion sinon pas impulsion, donc comme toi. En plus de ça il existe une fonction pour répéter ce bit plusieurs fois et ça améliore la qualitée en 1 bit mais la consommaton CPU monte.

En 2 bits c'et idem, sauf que je fait ça par paquet de 2bits et 4 bits c'est pareil. A savoir que le résultat au point d evue audio est comme wave2asm mais que la fréquences aigus et plus faible en volume et fréquence et surtout hachée. Le seul repproche que je peux faire de cette algo c'est que la qualitée 1 bits et amplifié ici. En bref en 4 bits le bit 7 et 3 domine.

Ximoon
: Donc on perd en lisibilité pour finalement pas grand chose c'est ça ?

--register-prefix-optional, c'est pour les chiens?

Tu radottes petit
Ceci dit y'a pas que ça ...
a68k rules