Logicielsmoto.com

Nous sommes le 12 Déc 2019, 21:08

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 46 messages ]  Aller à la page Précédente  1, 2, 3, 4  Suivante
Auteur Message
MessagePosté: 01 Fév 2016, 08:33 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 418
Localisation: France
Salut,
Tu peux peut-être demander sur http://wanted.scene.org, le site des petites annonces de la demoscene, pour avoir une musique originale plutôt qu'un fichier MIDI converti (tu peux utiliser ton login pouet.net, même pas besoin de créer un nouveau compte).

Par exemple, Irrlicht Project se propose de réaliser des musiques 1-bit: http://wanted.scene.org/post/8/music-fo ... ices-1-bit


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Fév 2016, 00:59 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1115
Localisation: Brest
Ah tiens, je viens de me rendre compte qu'en ré-initialisant les compteurs à 0 en début de ligne de pattern le son est bien meilleur. On entends plus les bruits stridents faisant penser à du code-Morse sous-jacent. En revanche on entend bien plus la porteuse à 9khz (période du player), mais ca peut rester acceptable.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Fév 2016, 23:34 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1115
Localisation: Brest
Hum... je me demande si on ne peut pas augmenter la vitesse du player en utlisant le couple de registre U et S pour écrire en $E7C1. En effet, ce qui fait perdre du temps c'est le bra qui suit l'écriture en $E7C0 pour équilibrer les deux branches. Or STU ,X et STS ,X ne diffèrent que d'un prefix $10 qu'il suffit de "sauter" pour transformer l'un en l'autre. Aussi on pourrait imaginer faire
Code:
    CMPA  #ratio
    BLO    LBL
    FCB    $10
LBL STU    ,X  ; ecriture U/S en $E7C0
    ..suite..
qui fait gagner entre 2 et 3 cycles.

Mais le hic est là: les deux branches ne sont pas strictement identiques mais diffèrent de 1 cycle. C'est peu, mais ca s'entend.

Pour bien contrebalancer cela il faudrait un saut qui, lorsqu'il est pris, s'exécute en un cycle de moins que s'il n'est pas pris. Et là j'ai un trou de mémoire. Dans la doc 6809 je lis LBLO 5(6).. Le 6 est il pour le cas où la branche est prise ou pas ? Si c'est le cas où elle est prise ([EDIT] oui c'est le cas), alors ca contrebalancerait exactement le $10. :bien: (6+5 dans un cas et 5+6 dans l'autre)

[EDIT] Ah mince! Je viens de réaliser que l'usage d'un long-branch ne ferait rien gagner par rapport à l'utilisation du BRA pour équilbrer (-3 par la suppression du bra, et +3 pour le long-branch). Mon interrogation est donc purement théorique. Dommage je pensais avoir trouvé une belle astuce :bah:

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 06 Fév 2016, 00:21 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1115
Localisation: Brest
Chose étonnante, en réduisant la vitesse du player de 111µs à 125µs le son est bien meilleur sur émulateur. C'est sans doute un effet de l'échantillonnage réalisé par ce dernier. Pour écouter ce que cela donne, appuyer sur B avec la D7 jointe.
Fichier(s) joint(s):
Commentaire: Player à 125µs ==> qualité meilleure.
quattropic.zip [23.38 Kio]
Téléchargé 202 fois
(on entend quand même assez bien la porteuse à 8khz exactement, soit 1 tour de boucle, mais c'est pas trop grave)

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 06 Fév 2016, 00:50, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 06 Fév 2016, 00:30 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Je suis assez étonné de la netteté du son. Avec très peu d'effet de souffle, effectivement. Même quand le volume baisse, le son se tient bien. Tu dois être content d'en voir le bout, surtout avec le gros bug qui t'as turlupiné pendant un moment ? Ça relance l'énergie !

_________________
Marche a suivre pour s'inscrire sur ce forum
Do not forget to contact one of the administrators to validate your registration.
Le site des démos de Puls
L'émulateur Teo


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 06 Fév 2016, 00:55 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1115
Localisation: Brest
Oui et je suis assez surpris qu'en baissant la qualité ca rende mieux. Je ne m'attendais pas à ca. Mais je n'ai fait que tester sur émulateur et pas sur machine réele. Si ca se trouve sur une vraie machine la version à 111µs (9khz) serait très bonne elle aussi.

J'envie quand même le Z80 qui fait tourner le même algorithme à 56µs, soit 2x plus vite. La porteuse est deux fois plus haute, quasiment inaudible du coup. J'ai beau me creuser la tête je ne vois vraiment pas comment on peut gagner un facteur 2.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 06 Fév 2016, 14:24 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1115
Localisation: Brest
J'ai testé sur vraie machine. Il n'y a pas à dire: c'est cette dernière version qui est la mieux. Le son est d'ailleurs très très proche de ce que les émulateurs produisent. C'est une bonne nouvelle, ca veut dire qu'on peut travailleur en toute confiance sur PC. Le résultat final ne devrait pas être trop différent de celui d'un vrai thomson.

C'est quand même vraiment marrant que le buzzer arrive à autant de subtilités dans les sons.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 21 Fév 2016, 02:56 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1115
Localisation: Brest
Bon finalement, je m'y suis remis et adapté mon ancien algo de conversion midi vers ce player dont le format a évolué pour ne pas avoir des morceaux trop gros (ils sont encore gros à mon gout, de l'ordre de 20ko pour 5mins).

Si on veut entendre ce que donnent les 4 voix quand elles jouent de la musique classique, on peut se faire une idée avec la version que voici:


Fichiers joints:
Commentaire: Spéciale dédicace à JS.
disk.zip [47.86 Kio]
Téléchargé 182 fois

_________________
Good morning, that's a nice Tnetennba
Haut
 Profil  
Répondre en citant le message  
MessagePosté: 21 Fév 2016, 09:47 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Samuel Devulder a écrit:
Bon finalement, je m'y suis remis et adapté mon ancien algo de conversion midi vers ce player dont le format a évolué pour ne pas avoir des morceaux trop gros (ils sont encore gros à mon gout, de l'ordre de 20ko pour 5mins).

C'est déjà un excellent rapport. 5 minutes de musique pour si peu d'occupation !

Samuel Devulder a écrit:
Si on veut entendre ce que donnent les 4 voix quand elles jouent de la musique classique, on peut se faire une idée avec la version que voici:

Wow ! Toute la Toccata et Fugue en Ré Mineur de Bach ! Cool !
Encore quelques petites imperfections du côté du rendu et du tempo, mais la musique est absolument reconnaissable. On est loin de tes premières démos de conversion de fichiers MIDI :good:

_________________
Marche a suivre pour s'inscrire sur ce forum
Do not forget to contact one of the administrators to validate your registration.
Le site des démos de Puls
L'émulateur Teo


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 23 Fév 2016, 01:46 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1115
Localisation: Brest
Bon j'avance un peu plus dans la conversion. A présent j'ai des "drums" qui commencent à ressembler à quelque chose. Pour fêter ca, je propose un petit David Guetta avec de beaux accords au début utilisant tous les canaux. Je trouve que ce morceau rend vraiment très très bien sur le buzzer. :)

Spéciale Dédicace à FoolDuplex au passage!


Fichiers joints:
Commentaire: David Guetta
disk.zip [53.91 Kio]
Téléchargé 194 fois

_________________
Good morning, that's a nice Tnetennba
Haut
 Profil  
Répondre en citant le message  
MessagePosté: 27 Fév 2016, 02:21 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1115
Localisation: Brest
Ce soir, grosse avancée dans la compression des données. A présent la toccata&fugues n'occupe plus que 6.5ko de mémoire, et l'ensemble des morceaux de Carmina Burana (1h) tient dans 22Ko (contre 260ko à l'origine). Les morceaux "typiques" de musique pop tournent autour de 5 à 7ko.

Je posterais un message décrivant comment on arrive à occuper si peu de place plus tard, mais en attendant voici la musique du jeu Turrican qui est passée de 56k (impossible à faire tenir en ram simplement) à seulement 7ko.


Fichiers joints:
Commentaire: Turrican
disk.zip [55.46 Kio]
Téléchargé 188 fois

_________________
Good morning, that's a nice Tnetennba
Haut
 Profil  
Répondre en citant le message  
MessagePosté: 27 Fév 2016, 08:48 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Un bit pour un octet ?

_________________
Marche a suivre pour s'inscrire sur ce forum
Do not forget to contact one of the administrators to validate your registration.
Le site des démos de Puls
L'émulateur Teo


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Les bases
MessagePosté: 28 Fév 2016, 17:01 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1115
Localisation: Brest
Prehisto a écrit:
Un bit pour un octet ?

Pas tout à fait.

Déjà il faut voir comment la musique est produite par le player.

Ce dernier anime 4 compteurs 16 bits. Chaque compteur est comparé à une valeur de seuil. S'il est au dessus, le buzzer est à 1, sinon il est à 0. Le buzzer prend donc 4 valeurs différentes le long des 125µs que représentent un cycle de la boucle principale du player. Le buzzer garde sa valeur environ 125/4=31µs ce qui est très faible, tellement faible que le haut-parleur prend une position reflétant la moyenne des 4 valeurs que lui donnent chacun des compteurs. On retrouve ainsi les positions 0% (tout en bas), 25%, 50%, 100% (tout en haut) de la menbranne du haut-parleur. C'est cela qui permet d'avoir l'illusion d'avoir 4 voix indépendantes avec le buzzer, même sans utiliser le convertisseur numérique analogique de l'extension "musique et jeux". En principe plus la boucle principale tourne vite, meilleur est le moyennage. Au mieux j'ai obtenu 111µs, mais cette vitesse introduit un siflement désagréable à l'oreille sur émulateur lié à la fréquence d'échantillonnage de ce dernier. Une valeur qui convient bien est 125µs, cette valeur est en outre un diviseur exacte de la seconde ce qui simplifie les expressions et les calculs manuels.

Ok, donc le compteur compte, mais à quelle vitesse au juste? C'est une bonne question. Supposons que le seuil soit à $8000. Le compteur part de 0 et va jusqu'à $7FFF. Pendant ce temps le buzzer est à 0, puis il passe à $8000 et termine à $FFFF avec le buzzer à 1. Enfin il retombe à $0000 et le cycle reprend. Le buzzer fait donc une alternance régulère de 0 et de 1, à la même vitesse que le compteur en met pour aller de $0000 à $FFFF. Si l'incrément du compteur vallait $8000, il y aurait alternance de 0 et 1 à chaque nouveau tour de la boucle principale. On produit alors un son de période 2*125=250µs (4khz). Plus généralement si l'incrément du compteur est (delta), il faudra (2*$8000/delta) tours de la boucle principale pour faire un cycle audio. C'est à dire que l'on fait un son de période ($10000/delta)*125µs=(8192/delta) ms. Sous forme de fréquence on a donc la relation f = (delta/8.192) hz ou delta = (freq_note_hz * 8.192). Le plus petit delta vaut 1, ce qui correspond à un son de période 8.192s, ce qui est tellement bas que seuls les éléphants peuvent l'entendre (infrason). En pratique on ne joue pas des sons aussi bas. On utilise plutôt les 5 octaves de la gamme tempérée (http://davbucci.chez-alice.fr/index.php ... /scala.inc) allant de 65.404hz (delta=536) à 1975.53hz (delta=16184). Le LA440 s'obtient pour delta = 8.192*440 = 3604.

Et le seuillage, on peut le changer? Oui! On a vu qu'un seuillage à $8000 faisait faire des créneaux au buzzer de telle sorte que la durée à 0 soit la même que celle à 1. Descendons le seuillage à $4000. Le compteur part de 0, et atteint $3FFF et pendant ce temps le buzzer est à 0, puis le compteur passe à $4000 et va jusqu'à $FFFF avec le buzzer à 1 tout ce temps. Le rapport des durées à 1 et à 0 a maintenant changé. Il passe 3x plus de temps à 1 qu'à 0. Si on passe le seuil à $2000, le buzzer sera 7x plus de temps à 1 qu'à 0. On fait donc varier le rapport cyclique de la note jouée rien qu'en altérant le seuillage. Il vaut 1 avec un seuil à $8000, il vaut 1/3 avec un seuil à $4000, puis 1/7 avec un seuil à $2000. Plus généralement parlant avec un seuil à (thr), le rapport cyclique vaut r=thr/($10000-thr). Donc pour avoir le rapport cyclique (r), il faut utiliser le seuil $10000*r/(r+1). En pratique on a pas besoin d'un seuillage sur 16bits. On peut se contenter de comparer l'octet de poids fort du compteur à une valeur 8 bits. C'est plus rapide et nécessite moins de mémoire.

Reste encore un dernier paramètre pour caractériser la boucle principale du player: sa durée. On sait que le player fait un tour en 125µs, donc s'il tourne (y) fois, il dure (y*125)µs. Un tempo standard est de 120bpm. Il y a donc 120 temps (i.e. 120 noires) dans une minute. Une noire dure donc 60/120s = 1/2 seconde, ce qui correspond à y = 500 000µs/125µs = 4000. Il faut donc itérer exactement 4000 fois la boucle principale pour faire une noire. Mais une blanche alors? Ben ca vaut 2 noirs, donc exactement 8000 tours de boucle. La croche vaut elle 1/2 noire, donc 2000 tour de boucle. Facile! On pourrait stocker ce nombre de tour sur 16bits, mais c'est un peu trop précis car la plus petite unité de temps étant disons la quintuple croche correspond à 125 tours de boucle (au delà il faudrait un nombre de tour non entier). On pourrait compter les durées en multiples de la quintuple croche (1/32ème de battement). Elle aurait la durée 1. La quadruple croche aurait la durée 2, la triple croche la durée 4, la double croche la durée 8, la croche 16, la noire 32, la blanche 64, et la ronde 128. Pas mal: toutes les durées de notes tiennent dans un octet. On peut même dépasser la durée d'une ronde tout en restant dans un octet: la ronde pointée vaut 128+64=192. Impec!

Donc, résumons. Notre player joue 4 note chacune ayant sa fréquence (2 octets) et son rapport cyclique (1 octet), pendant une certaine durée codée sur un octet. Il faut ajouter que le player est aussi capable de faire du bruit sur sa 4ème voix. Pour cela il faut un octet supplémentaire indiquant si l'on va jouer les 4 voix ou juste 3voix plus du bruit. Cela nous fait 3*4+1+1=14 octets pour configurer le player pour jouer de la musique pendant un certain temps. Ils sont organisés comme suit
Code:
<flag:1> <durée:1> (<seuil:1> <freq:2>) (<seuil:1> <freq:2>) (<seuil:1> <freq:2>) (<seuil:1> <freq:2>)
total: 14 octets
On appelle une telle ligne un "pattern". Un morceau de musique est constitué par un ensemble de lignes indiquant les notes à jouter. Exemple:
Code:
* Bach_Toccate_Fugue_BWV565.mid
zik
 fcb $82,$20,$80,$16,$56,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$20,$80,$13,$e7,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$40,$80,$16,$56,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$20,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$10,$80,$13,$e7,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$10,$80,$11,$ba,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$10,$80,$10,$bc,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$10,$80,$0e,$e9,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$20,$80,$0e,$14,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$20,$80,$0e,$e9,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$c0,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$20,$80,$0b,$2b,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$20,$80,$09,$f3,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$40,$80,$0b,$2b,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$20,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$20,$80,$08,$5a,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$20,$80,$08,$dd,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$20,$80,$07,$0a,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$40,$80,$07,$74,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$e0,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$20,$80,$05,$91,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$20,$80,$04,$f5,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$40,$80,$05,$91,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$20,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$10,$80,$04,$f5,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$10,$80,$04,$6a,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$10,$80,$04,$28,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$10,$80,$03,$b6,$00,$00,$00,$00,$00,$00,$00,$00,$00
 fcb $82,$20,$80,$03,$85,$00,$00,$00,$00,$00,$00,$00,$00,$00
 ...


Quelle place ca prend ? Le player est tout petit, il tient dans 256octets facilement, par contre les patterns sont volumineux. Un player de MOD typique met à jour les registres musicaux toutes les VBL. Ca veut dire qu'on consomme 14 octets 50 fois par secondes, soit 700 octets/seconde. Une minute de musique consomme donc 42ko, et un morceau de 3 minutes 168ko. C'est énorme! Alors on peut essayer de ne pas mettre à jour à chaque VBL, mais disons une sur 5, ce qui fait 33.6ko, ce qui tient en RAM. Mais s'il faut utiliser la commutation de bank mémoire ce qui complexifie le player, c'est surtout que la plus petite note possible dure 100ms, environ 1/4 de noire: une double croche (quarter note chez les anglos-saxon). Les effets plus rapides que 100ms ne seront pas reproductibles. C'est pas terrible. :L

Il faut trouver une solution...

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 29 Fév 2016, 11:44, édité 2 fois.

Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Les partitions
MessagePosté: 28 Fév 2016, 17:04 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1115
Localisation: Brest
Les partitions

Ce problème n'est pas spécifique à notre player mais existe depuis la conception des trackers et donc une solution a été trouvé très tôt dans l'histoire. La première chose à remarquer est qu'un morceau de musique n'est pas une suite de notes aléatoires. Il y a de la structure. Les notes se répètent (penser aux refrains par exemple). Le format orginel MOD a donc eu l'idée de regrouper les notes en partitions. La partition représente une phrase rythmique formée de quelques mesures. Elle identifie la succession des notes de musique jouées par un instrument à un moment précis. Originairement, il est possible de placer 64 notes à la suite pour chaque canal dans une partition. Les partitions peuvent être répétées ou jouées dans un ordre défini dans une séquence de partition, et permettent au musicien de créer le morceau de musique final.

On morceau de musique est ainsi souvent codée comme suit:
Code:
* table des partitions
table
  fdb part1,part1,part2,part3,part1,part1,part4,part5,..,$0000

* partition 1
part1
  data pattern1 (14 octets)
  data pattern2 (14 octets)
  data pattern3 (14 octets)
  ...
  fdb $0000

* partition 2
part2
  data patternX (14 octets)
  data patternY (14 octets)
  data patternZ (14 octets)
  ...
  fdb $0000

* partition 3
part3
  ... (14 octets)
  ... (14 octets)
  fdb $0000

* partition 4
part4
...
...
C'est vraiment un format très compact, permettant de faire tenir plusieurs minutes de musique dans moins dans quelques dizanes de Ko (une partition occupe 1ko, et il faut facilement 16 à 32 partitions distinctes). Même avec 20ko, un morceau de musique est quand même très gros pour thomson. Il n'y aurait qu'au plus 12ko pour les effets, sans compter le temps de chargement. Il faut donc aller plus loin que ce principe de partitions.

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 28 Fév 2016, 21:35, édité 2 fois.

Haut
 Profil  
Répondre en citant le message  
 Sujet du message: FACTORISATION
MessagePosté: 28 Fév 2016, 17:05 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1115
Localisation: Brest
FACTORISATION

Fondamentalement, le player lit les pointeurs vers les paritions un à un dans la table. A chaque nouveau pointeur il lit la partition pattern par pattern jusqu'au $0000 final. A ce moment là il revient à la table et lit l'addresse de la partition suivante, y saute, etc. Ca ressemble à un couple JSR/RTS ce truc: on saute "dans" un pattern que l'on execute, et le $0000 nous fait revenir au pointeur de partition suivant. D'une certaine façon le player execute des instructions. On peut donc intepréter la table des partitions précédente comme un programme qui appelle des sous-routine (les partitions):
Code:
* table des partitions
table
  JSR part1
  JSR part1
  JSR part2
  JSR part3
  JSR part1
  JSR part1
  JSR part4
  JSR part5
  ...
  RTS

* partition 1
part1
  PLAY pattern1 (14 octets)
  PLAY pattern2 (14 octets)
  PLAY pattern3 (14 octets)
  ...
  RTS
* partition 2
part2
  PLAY patternX (14 octets)
  PLAY patternY (14 octets)
  PLAY patternZ (14 octets)
  ...
  RTS
...

L'avantage de voir ca comme des jsr/rts est qu'on a pas de raisons de se limiter à une profondeur de 1. Il se pourrait que patternX et patternY de la partition2 soient identique aux patterns 1 et 2 de la partition1. On pourrait alors avantageusement les factoriser:
Code:
* partition 1
part1
  JSR  part_common
  PLAY pattern3 (14 octets)
  ...
  RTS
* partition 2
part2
  JSR  part_common
  PLAY patternZ (14 octets)
  ...
  RTS
part_common
  play pattern1 (14 octets)
  play pattern2 (14 octets)
  RTS

Ce qui fait gagner quelques octet. Il y a du progès. Reste à coder les JSR, les PLAY et les RTS.

On pourrait ajouter un octet de plus mais ca annulerait le gain de la factorisation. Hum... si au lieu de coder le JSR avec un addresse absolue, on stockait son offset par rapport au début du morceau de musique on aurait que des valeurs positives (pour les morceaux de moins de 32ko), et le format serait translatable en mémoire. Interessant: disons donc qu'une donnée 16bits positive soit interprétée comme un JSR, ce dernier ne prendrait finalement pas plus de place que le pointeur vers la partition, c'est cool! A noter qu'on ne va jammais faire un JSR vers le début de morceau, donc l'offset $0000 ne sert pas. Disons qu'il encodera le RTS qui ne sera pas plus long que le $00000 du format initial. On est toujours dans les clous. Reste le cas du PLAY. On a vu qu'un pattern commence par un flag 0/1 suivant que la dernière voix doit produire du bruit ou pas. Son bit de poids fort est donc libre. Si on l'impose à être à 1, on arriverait à distinguer un PLAY d'un JSR/RTS. Ok a donc l'algo suivant issu de notre codage:
Code:
  lire 16bits
  si <0, c'est un PLAY
  si >0, c'est un JSR
  si =0, c'est un RTS
Pas mal: on garde le même format et la même occupation que celui par table de partition, mais on l'a généralisé en autorisant d'avoir un JSR (donnée 16bits>0) en plein milieu d'une partition.

Avec ca on peut factoriser au max les répétitions en les recherchant systématiquement dans les données sans avoir besoin de la régularité stricte du format par table de partition. Ca nous convient bien. Quand on fait ca, la Toccata et Fuge de J-S Bach arrive à tenir dans 22ko environ (voir plus haut). C'est mieux que les 168ko d'origine, mais ca reste quand même imposant pour la mémoire d'un Thomson. Si on veut ajouter du code et d'autres données autour on sera vite limité. Il faut réduire encore plus l'occupation...

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 23 Mar 2016, 08:06, édité 2 fois.

Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 46 messages ]  Aller à la page Précédente  1, 2, 3, 4  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 8 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com