PolySnd - Page 5

Bon je sais ce que je vais faire, donne ton fichier MIDI et je vais faire une doc sur midi2asm. Après tu verras c'est simple.

J'ai un prob moi, j'ai un port 3.5 soudé depuis pas mal de tps sur ma calculatrice (89 hw1) et j'ai essayé ta lib ce matin avec tes démos, résultat que du mono ...

A là ça vient pas de la librairie, ça vient de toi là j'en suis sûr à 100%. Ton ports est mal fait! Je parie que tu as des baisse de puissance, le son est pourri...

heu nan ...

Tu ne mélange pas les versions?

Et quand tu part mono (normalement par pour toute les démo il y a une mélodie différente par anceintes).

Voilà je propose quelque chose pour le convertisseur MIDi, vous proposez quoi comme utilisation:
-Affichage des tarck disponible dans le fichiers...
-Convertion directe de MIDI en ASM et non de MIDi en TExte puis de Texte en ASM...

Cette nouvelle version sera stable et donc pas de plantage, possibilité de gérer les variations de tempos...

Mais dite moi ce qui serait important de faire ou de ne pas faire. Je serait heureux qu'une parti Musiques soit crée sur le forum pour permettre l'échange de fichiers... ou encore l'utilisation de son dns des jeux...

Je suis en train de développer la version 2.0 de PolySnd qui cette fois régleras tout les problèmes de la version 1.3 ainsi que beaucoup d'améliorations seront apporté sur Midi2Asm.

En ce moment j'ai développé un player de fichiers audio pour PolySnd 2.0 qui permetteras de lire 2 formats de fichiers (mus=pour les fichiers musicaux et son=fichiers brutages). En effet le fonctionnements de ses 2 fichiers et toalement différentes. Les fichiers audio seront compressé donc pour 1 min de musique on arrive à 400 octets.
Ce player est capable d'afficher de nombreuse informations sur le fichiers audio, afficher le temps écoulé et le temps de fichier audio...

La version 2.0 de PolySnd pourras être utilisé dans le développement de jeux en 4 niveaux de gris. Pour l'instant j'i réussit à intégrer du son avec des niveaux de gris et avec le processeur tavaillant derrière. La qualité du son est toujours sur 2 voies minimum et de meilleur qualité car maintenat il est possible de jouer des fréquences dans une plage de 4khz avec distorsion.
En ce moment j'ai intégré la partie de getion audio dans l'interruption mais je suis bloqué dans le développement de la fonction beep qui aurat pour but de régler la fréquences et la durée voulue et qui serat la base pour la suite de cette libraire.
Pour l'instant je développe cette librairie en C mais je voudrais bien la développer en ASM et je voudrais savoir comment gérer une interruption en ASM.

J'espère que lors de la sortie de PolySnd 2.0 beaucoup de personnes l'utiliseront.

J'attends ca avec impatience ...

Merci

Pour cette nouvelle version je compte mélanger 2 mode:
-1 mode pour jouer des musiques sur 2 voies de bonne qualitée mais où il est impossible de jouer du son avec un déroulement de programme derrière je pense que je vais adapter ceci pour jouer du son avec des musiques avec des niveaux de gris.
-1 mode pour jouer des son de moins bonne qualité mais dont on peut les utiliser dans les jeux avec des niveaux de gris.

Je créer ses 2 modes car tout simplement en jouant du son avec déroulament de programme il 'est possible que de jouer 50 fréquences si qui est très peu pour une musique.

A savoir qu'avec ses 2 modes le son pourrat être jouer sur 2 voie.

N'hésitez pas à me donner vos suggestions.

A oui j'oublie le principal défaut de cette librairie vient du fait qu'un interruption seras utilisé (la n°5) et donc les jeux necessiatnt cette interruption devront utiliser la 1.

Question importante:
Je sais que quelque personne sont anti _nostub ou anti kernel et donc je compte développer cette librairie en _nostub et kernel mais voici les points faibles et fort de c'est 2 modes. N'hésitez pas à me dire ce qui serait le mieux.

Kernel:
-Librairie indispensable pour le developpement de programme ou musqiues en kernel
-Gain de place en mémoire importante soit 2000 octets, en effet besoin de passer par PolySnd
-Utilisation je pense plus facile surtout en ASM.
-Peut exister des problèmes d'iincompatibilités entre les anciennes et futurs versions.

Nostub:
-Facilitée de programmation en C et ASM.
-Intégration dans un jeux ou autre programme donc possibilitée de manier les fonctions de la librairies en fonction de ses besoins.
-Perte en mémoire selon les fonctions utilisées...
-Aucun problèmes d'incompatibilté puisque la librairie est intégrée.

Ca c'est un des problèmes car pour les débutant c'est déroutant donc est-ce que je dois faire plus fichier zip (un avec la librairie en kernel) et un pour les programmeur avec la librairie en nostub et informations pour la programmation...

Je parle ici de libaririe mais au stade ou elle se trouve je devrait plutot parler de drivers.

J'ai aussi presque fini un player acceptant des fichiers musicaux compressé donc très faible en mémoire mais dois-je l'inclure dans le zip avec la nouvelle librairie ou faire un zip avec des informations sur le player... très détaillé?


Enfin pour le convertisseur MIDI, un problème majeur se pose en effet la futur version seras très évolué et facile d'utilisation et surtout ne planteras pas mais voici les problèmes:

-En effet pour convertir un fichier MIDI il ce peut qu'il utilise plusieurs track par conséquent l'utilisateur pourras choisir le track à convertir mais ne seras pas comment il se présenteras donc cela est abstré.
-Pour les morceau Polynotes il n'est pas possible de les convertir de façon propre donc accentuation de risque de bug donc je propose 2 cas (les convertir en effacant un polynote ou afficher un message d'information).

N'hésitez pas à me dire ce qui ne va pas ou ce que je doit rajouter pour les utilisateurs ou même les programmeur comme par exemple des fonctions supplémentaires, je le rappel mais cette nouvelle version est assez puissante pour être utilisé dans des jeux et dans des programmes audio donc interessante.

A savoir que j'ai pris note de ce que m'as dit squale92 et donc l'int5 seras utilisable donc en utilisant cette libaririe on ne perd rien comme fonctions... En effet l'int 5 auras une fréquence de 8khz sans son et environ 5 à 7 khz avec du son donc assez puissante pour gérer la synchronisation dans des jeux mais pas très précise je pense.

Tu fais un ZIP avec un dossier contenant la version Kernel et un dossier contenant la version _nostub. Et dans le readme, tu expliques les différences entre les deux modes.

je ne suis pas tout a fait d'accord:

Kernel:
-Librairie indispensable pour le developpement de programme ou musqiues en kernel
-Gain de place en mémoire importante soit 2000 octets, en effet besoin de passer par PolySnd
-Utilisation je pense plus facile surtout en ASM. -Peut exister des problèmes d'iincompatibilités entre les anciennes et futurs versions.

Kevin te diras que c'est plus compliqué parcequ'il faut installer PreOS et que ca occupe de la place. C'est en partie vrai si tu n'utilises le kernel que pour un programme ou que tu est trop bête pour lire le readme.
pour les problèmes d'incompatibilité il ne devrais pas y en avoir avec Preos si tu as défini des numéros de version

Nostub:
-Facilitée de programmation en C et ASM.
-Intégration dans un jeux ou autre programme donc possibilitée de manier les fonctions de la librairies en fonction de ses besoins.
-Perte en mémoire selon les fonctions utilisées... -Aucun problèmes d'incompatibilté puisque la librairie est intégrée.

L'utilisation de lib est tout aussi aissée en nostub qu'en kernel.
Il y aurai peut-être un gain si un programme n'utilse que certaines fonction de la lib(et qui bien sur n'est pas liée a d'autres fonction de la lib) dans un seul programme. Ca fait beaucoup d'hypothèses et je pense que dans ton cas en général on ne gagnera pas de place a passer en nostub(hormis la taille de preOS)

geageo: l'asm kernel est plus 'facile' à programmer que l'asm nostub ... y'a pas de libs pour le nostub .. que les ROM_CALLS pis des archives ...

neurone> Kevin va te tuer!

bah il a encore le droit de s'exprimer ! c'est la moindre des choses qd même !

Non c'est juste que je crois qu'il a dit une connerie : on peut utilser les lib statique en ASM aussi il me semble bien (ou alors c'est moi qui vait me pendre)

Oui mais nEUrOne n'a pas dit le contraire, il a dit " que les ROM_CALLS pis des archives ..."
On peut utiliser les librairies statiques en asm.

pas on-calc...
on calc, il n'y qa quel les dynamiques
(dommage que AS ne fasse pas le mode kernel)

...
Ca veut rien dire.
Tu dis qu'on calc il n'y a que les librairies dynamiques, mais ensuite tu dis que AS ne gère pas le mode kernel. Donc AS ne gère ni les librairies statiques ni les librairies dynamiques. On parlait de programmation sur PC.

> Nostub:
> -Intégration dans un jeux ou autre programme donc possibilitée de manier les fonctions
> de la librairies en fonction de ses besoins.
> -Perte en mémoire selon les fonctions utilisées...
Tu parles d'une lib dynamique, là ? Parce qu'avec une lib statique, il n'y aura justement pas de perte en mémoire selon les fonctions utilisées...
Et la perte de place avec les fonctions inutilisées, dans une lib dynamique, est valable à la fois en kernel et en _nostub.
Peut-être que tu devrais fractionner au maximum pour réduire la perte de place ?


Mais, il est évident que dès que beaucoup (le nombre exact dépend du nombre de fonctions, de la taille des fonctions, de la nature de la librairie, des programmes eux-mêmes) de programmes différents sont en même temps sur la même machine, et utilisent les mêmes fonctions (il y aura forcément des fonctions qui seront utilisées dans les trois), la lib dynamique devient une solution intéressante (la place perdue par les fonctions inutilisées étant compensée par le fait de n'avoir qu'une fois au lieu de plusieurs les mêmes fonctions).

Bihi> à force de faire 6h de glande par jour, tu arrives à plus trop faire gaffe à ce que tu poste, tant que ça t'occupe

Est-ce que je pourrais avoir un exemple de librairie Nostub en ASM? Je sais que j'en demande beaucoup mais je n'est jamais fait de libaririe Nostub en ASM, là je parle de librairie Dynamique car en statique je sais comment faire.
Merci d'avance.

Kevin rectifiera si je dis n'importe quoi, mais le nostub de permet pas de supporter nativement les librairies dynamiques. Il faut que tu codes toi-même un code de chargement de la lib. Ou bien utilise un DLL, mais là Kevin va crier parce qu'à la base, elles n'ont pas été utilisées pour ça (même si ça pourrait être utile en fait)
En _nostub on utilise plutôt les lib statiques. Pourquoi tu ne fais pas une lib statique ?

Bas c'est ce que je pense donc je reviens au post #131 ou je dis que le nostub ça sera statique et kernel dynaique et statique.

Tu vas faire une version kernel statique ?
Pourquoi ne pas utiliser la version statique _notub en kernel ?

C'est ce que je vasi faire utiliser la version statique du nostub pour le kernel.

de toute facon le problème ne se poste pas le kernel est compatible avec les lib nostub. donc il n'y a pas en théorie besion de faire une lib kernel statique. tu fait :
- une lib statique nostub qui pourra être utilisée par les prog kernel et nostub(même si se serait une erreur d'utiliser la lib statique en mode kernel a mon avis)
- une lib dynamique kernel

C'est ce que je penais faire merci Uther Lightbringer.
Mais pour les jeux quelles serait les fonctions utile voir importante?