PolySnd - Page 18

Merci. J'ai mis du temps car tout simplement je n'avais peu de temps à me consacré à cette librairie du à la robotique, cours.... Mais pendant les vacances ça avanceras vite.

Mais il y a encore beaucoup de travail là dessus, et si tu regarde les fonctions que je propose dans le fichier polysnd.h en C et en ASM tu verras que le son peut s'intégrer dans différent projets.

J'apprend sans cesse et j'améliore la façon de coder et surtout mon code, quand je suis arrivé ici je venait juste de programmer en C sur TIGCC et donc je codé très mal, par exemple j'utilisé les fonction de Graph.h pour tout ce qui était graphique mais maintenant, je code toujours mal mais moins qu'avant et grace à vos conseil et à votre aide, je progresse.

franchement geogeo pour un "nioob" (excuse moi l'expression) je pense que tu fait vraiment partit des "pros" rare sont ceux comme toi qui a peine arrivé (bon sa fait deja qq mois qd meme) on proposé des trucs aussi interessant, surtout sur le domaine ultra hazardeux qu'est le son sur TI (bcp d'anciens "pro" s'y sont "cassé les dents" dessus..)

C'est vrai. Les deux derniers c'était Dark Angel et HerveRV qui ont malheureusement disparu vite après. Espérons que ce ne soit pas ton cas

... vraiment dommage d'ailleurs (Je me souviens sourtout de Dark Angel, pour RV, ça a été la grosse période où j'ai stoppé l'utilisation de la TI)

nil> Me too..

En effet. Le boulot de geogeo est impressionnant...

Il y en a un autre qui devrait faire de la pub pour sa librairie, c'est hibou (CompLib).

Complib est bien mais c'est pas d'un grand niveau de programmation, c'est juste une reprise de 2 algos de compression connus. Par contre HibView est vraiment génial

> Complib est bien mais c'est pas d'un grand niveau de programmation, c'est juste une reprise de 2 algos de compression connus.
En effet, mais c'est à ma connaissance la seule lib utilisable par tous qui fasse ça. Et d'autres algorithmes vont arriver...

> Par contre HibView est vraiment génial
Par rapport ce qu'il remplace (je veux parler de txtrider), c'est sûr qu'il est génial...
Je n'ai pas testé HibView et extrêmement peu testé HibText, je ne m'en sers de toute façon pas (pas de pompes pour les examens...).
J'ai déjà mentionné que je n'ai jamais réussi à lire un texte avec txtrider, malgré plusieurs essais sur plusieurs machines différentes (HW1 / HW2 sous divers AMS, avec divers kernels dont le plus récent est DoorsOS II 0.98; il n'y avait que ça dans mon lycée, et je n'allais pas changer ça:
"
- C'est pas bien, ça fait que de planter !
- je sais, ça n'est pas de ma faute, mais c'est normal, c'est kernel...
"
)... En revanche, j'ai pu lire un texte du premier coup avec HibText...
Je sais que txtrider est stable sous UniversalOS.

il n'y avait que ça dans mon lycée, et je n'allais pas changer ça

dans ma classe (bon, ok, on etait que 9, dont 5 avec des 68k, il me semble), ils sont tous passes a UniversalOS des que je leur ai mis sur une HW2 avec les grays qui ne clignotaient plus

ba de tte les plantage de txtrider proviennent pas du kernel, mais de txtrider.. faut pas oublier que txtrider, sa fait + de 3ans qu'il est pas maintenu et que le code (et l'usage des romcall) doit parraitre sale a coté de se qu'on fait now

oue, clair

En effet, mais c'est à ma connaissance la seule lib utilisable par tous qui fasse ça. Et d'autres algorithmes vont arriver...

au hasard : ziplib et flib c'est juste une reprise des deux.
komp est un format qui n'aurait jamais du voir le jour a mon avis. c'est dommage que fl n'ait pas tout simplement adapté ziplib.
quant au zip ca ne gène que kernelo-phobes je m'en sert depuis toujours

Par rapport ce qu'il remplace (je veux parler de txtrider), c'est sûr qu'il est génial...

he bien disons que pour le moment il est exactement pareil(mêmes fonctionalités et complètement instable sous certaines configs) mais Hibou travaille encore dessus alors que txtrider est abandonné

Uther Lightbringer a écrit :
alors que txtrider est abandonné

Hum personne na encore tenté 1 ttdasm dessus pour essayer de remettre les sources au gout du jour ?

le code désassemblé très peu pour moi merci sourtout ci ca a été codé a l'origine en C

nan !!
TxtRider na jamais été codé en C mais 100% pur ASM (TIGCC existait pas encore a l'epoque, ou emergeait juste)

Oui, m'étonnerais qu'il ait été fait en C ...

XDanger
a écrit : Il y en a un autre qui devrait faire de la pub pour sa librairie, c'est hibou (CompLib).

je sais pas faire de pub comme Thibault à su le faire pour einstein faudrait qu'il me donne des cours d'auto-pub
et complib n'est pas encore arrivé à maturité pour etre largement diffusé. J'essaye de bien la faire marché avec hibview. deja avec Sh'l c'est dejà parti en couille
Et cette lib n'est pas du tout optimisée : je suis convaincu que ziplib va plus vite. Pour moi, l'interet de ma lib est d'etre en C donc facilement maintenable, et d'etre nostub.

qd à hibview, son avenir va se faire tout seul j'ai plein d'idées (idées proposées aussi) qui mijotent : j'ai juste pas le temps de les faire car il faut d'abord débugger ce qui existe déjà.

Mon travail aussi est loin d'être terminé.
Mais ce que je trouve bizarre c'est que depuis que je suis partie du fichier Sound6D de Laurent Poncey, j'ai tout de suite accroché sur l'idée de faire une librairie puissante de son sur TI, pour moi mon travail s'arrête à PolySnd 1.0 qui avait pour but de modifier le fichier de Laurent Poncey en Librairie permettant la création de morceaux de musiques et sans plus tout en restant avec le code d'origine mais depuis que j'ai tout refait surtout en ASM (le langage ou je code le plus mal), la librairie est vraiment plus puissante mais n'ai pas encore terminé, reste plus que le plus fastidieux.

Les jeux ne seront-ils pas considerablement ralentis a cause du son?
De combien de CPU aura besoin polysound pour fonctionner pleinement?

(j'espere qu'elle veut dire un truc ma derniere phrase sinon )

Les jeux ne seront vraiment pas ralentie, environ j'estime à une perte de 3 fps dans un jeux avec du son mais c'est faible je trouve.
Pour le temps CPU je ne sais pas mais je verrais bien au fur et à mesure des teste, mon code n'ai pas très optimisé en mémoire mais ce n'ai pas le but.

ah passque c'est pas un ancien?
whaou IMPRESSIONNANT!

Mais ma librairie n'est pas encore terminée

moi j'aatne dqu'elle soit fini avec impatience

Au faite PiNGoO n'hésite pas à me contacter au sujet de tes projets.

Par "d'autres algorithmes vont arriver" (j'ai d'ailleurs peut-être oublié "probablement" ?), je voulais dire que je lui ai donné le droit de prendre tout ce qu'il y avait dans PackLib commencée par TICT (LZO12 et LZRW3A, en l'occurence).
Et hibou est (ou a été) en relation avec Francesco Orabona qui a modifié un algorithme existant. Cf le forum suggestions du forum de TIGCC / TICT, http://pub26.ezboard.com/ftichessteamhqfrm3

Un compresseur et decompresseur on-calc c'est vraiment pratique

En effet.
ziplib, KOMP, LZO12, LZRW3A, l'algorithme de Francesco Orabona sont faits pour la compression/décompression rapide on-calc...
L'algorithme PPG ne l'est malheureusement pas, il est efficace mais la mémoire de nos calculettes est bien trop petite pour la compression...

Comment ça trop petite, le format PPG demande beaucoup de mémoire?

J'ai encore une autre idée de gestion des ondes pour avoir d'autres fréquences, je l'ai teste toute et je prend la meilleurs.

Que pensez vous si je compte le nombre d'impulsion et que je remet l'état du port à 0 puis à 1 rapidement de telle sorte que je puisse obtenir beaucoup de fréquence car ce qui est bizarre c'est même avec 8khz j'ai pas énormément de notes, c'est bizarre. Il faut juste que je trouve la meilleurs méthode.

J'ai écrit au créateur de CalcMod sur TI-83+ pour avoir plus d'information sur la gestion d'ondes carrés. J'espère qu'il va me répondre

En ce moment je suis bloqué sur ça et c'est un gros problème soit je change de méthode ou soit je garde la même mais faut que je me casse la tête pour créer la table des notes.

Pour la table des notes, tu calcules la fréquence moyenne et tu en déduis la note. (Divise par 440 Hz, et prend le logarithme de base la racine 12^ème de 2 pour avoir la différence en demi-tons par rapport au LA de référence.) Il est certainement plus simple de partir de l'onde carrée et d'en déduire la note que l'inverse. Après, tu jettes les fréquences qui sont trop loin d'un demi-ton entier, ainsi que les ondes qui donnent le même demi-ton qu'une autre onde avec une distorsion plus faible, et tu finiras bien par avoir une table de notes utilisable.