Logicielsmoto.com
http://www.logicielsmoto.com/phpBB/

MOD ?
http://www.logicielsmoto.com/phpBB/viewtopic.php?f=3&t=549		 Page 4 sur 19
Auteur:  Prehisto [ 31 Jan 2017, 19:05 ]
Sujet du message:  Re: MOD ?
Et sans le test clavier, ça donne quoi ?
Auteur:  Samuel Devulder [ 31 Jan 2017, 20:09 ]
Sujet du message:  Re: MOD ?
Je n'entends pas de différences. Le clavier est appellé à chaque fin de periode d'attente sans modification des paramètres du player c'est à dire toutes les frames d'environ 20ms (i.e. une centaine de tours de boucle). Ca ne change pas le son par rapport au traitements qui sont fait au changements de frame (changement des instruments, et/ou volumes et/ou fréquences).

Par contre ce que je vais essayer de voir c'est remplacer le SUBD (4cycles) de la boucle du player par un LDD (3cycles) pour voir si ca n'introduit pas trop de distorsions lié à la perte de phase. Si ca marche, alors j'aurais une évolution très sympa à ajouter... Un cycle de gagné ca n'a l'air de rien mais comme c'est répété pour les 4 voix, on a 4 cycles. Et dans 4 cycles on peut faire des trucs... (à suivre)

Mais avant ca, il faut d'abor ajouter le support pour les tremolos et vibrato.
Auteur:  Samuel Devulder [ 01 Fév 2017, 02:08 ]
Sujet du message:  Re: MOD ?
Oh.. j'ai une idée.... en fait pour des questions de marge de sécurité, j'ajoute quelques octets en fin de sample pour éviter qu'on aille lire le suivant. Sur des échantillons de 1ko, ajouter 3 octets c'est rien. Mais sur un sample à 9 échantillons, ajouter 3 octets augmente sa période d'1/3. Le LA440 qu'on doit jouer se joue à 1/3 moins vite cad 293hz et on est plus proche du RE de la même octave... Ca expliquerait bien la disharmonie qu'on a pour les échantillons aigus qui sont justement ceux qui on peu d'octets. Le passage au LDD en lieu et place du SUBD devrait réparer cela (si c'est bien la cause du problème... mais je suis assez confiant.)

Bon sinon je viens de terminer l'ajout du tremolo, du vibrato et du loop pattern. La compatibilité s'amméliore :)

[EDIT] j'ai aussi levé la limite de 32 instruments. A présent on peut en avoir 256 :D Ca permet de traiter la commande 9xx (Sample Offset:Starts playing the sample at the position xx × 256 (instead of position 0)).
Auteur:  gilles [ 01 Fév 2017, 17:40 ]
Sujet du message:  Re: MOD ?
j'avais un truc similaire en projet (pas tres avancé) depuis un moment.
j'avais aussi fait qqs tests avec une autre option (un précalcul mod vers sample (précalculé sur le PC avant compilation) sur plusieurs pages de ram pour faire un peu de CPU et la musique en boucle).
J'essaye d'écouter dès que possible sur matos réél ;) ce WE probablement.
Auteur:  Samuel Devulder [ 04 Fév 2017, 19:44 ]
Sujet du message:  Re: MOD ?
Quelques nouvelles: j'ai trouvé la cause profonde :) le calcul de la longueur d'un instrument ne marchait pas pour ce MOD. En effet la longueur de répétition + l'offset de répétition étaient plus petits que la longueur totale de l'instrument (normalement c'est identique). J'ai corrigé et ca marche bien bien mieux (dans les limites de 5khz).

J'ai aussi ré-écrit la routine de sous-échantillonage pour qu'elle puisse marcher avec des fractions non entières d'échantillons (par exemple regrouper les échantillons par paquets de 4,17) et traiter bien mieux le rebouclage (reste le cas éventuel où div<1).

En outre pour éviter les imprécisions sur les instruments avec seulement 11 à 32 échantillons thomson, on réduit le sur-échantillonage de sorte qu'il y ait beaucoup plus de données pour définir l'instrument. Typiquement pour ces instruments à problèmes, on passe de 4 échantillons amiga pour un échantillon thomson, à un rapport de 1 pour 1. On gagne ainsi 2 bits de précision et pour la fréquence ca change beaucoup de choses au niveau de la justesse.

Similairement les échantillons qui sont plus gros que 4ko sur thomson, sont sous-échantillonnés (par exemple 8 échantillons amiga pour un chantillon thomson) pour être réduit en taille et gagner de la préciseuse RAM. Cela combiné à une compression LZW inroduite de façon transparente dans l'encodage des "patterns" (ce fut mon travail très intéréssant de ces derniers jours. La compression LZW est finalement très simple) et on arrive à faire tenir en RAM des morceaux qui me faisaient baver devant l'amiga des copains quand j'étais petit. Je vous le laisse découvrir..
Fichier(s) joint(s):
xenon2.zip [63.67 Kio]
Téléchargé 654 fois

A présent j'aimerais bien ajouter la supperposition d'échantillons dans le même octet pour pouvoir convertir des mods encore plus gros. Pour indication, celui-là par exemple fait 357ko sur amiga et 27ko sur thomson :cool:
Auteur:  Prehisto [ 05 Fév 2017, 10:04 ]
Sujet du message:  Re: MOD ?
Assez stupéfiant de pouvoir faire jouer des MOD par un Thomson...
Je suppose que le lecteur de MOD n'est pas encore prêt pour lire "Condom corruption" de la démo "State of the Art" ? Il y a pas mal de commandes étendues dans la partition...
Auteur:  Samuel Devulder [ 05 Fév 2017, 10:37 ]
Sujet du message:  Re: MOD ?
Tu veux parler de ceci: https://modarchive.org/index.php?reques ... uery=39162 ?
Le traucteur ne bronche pas, mais le module généré envoie mystérieusement le player dans le décors :(
Je dois regarder ce qu'il se passe...
[EDIT] trouvé: le module thomson fait 67ko :( Il va vraiment falloir que je mette la supperposition des instruments en route. La bonne nouvelle c'est que tous les effets du morceau son supportés. C'est déjà ca :)
[EDIT2] Arghhhhh la supperposition ne sera pas suffisante. Rien que la partie "pattern" est énorme. Malgrès la compression elle va de ~$7600 à ~$c900. Du coup il reste de ~$C900 à $DFFF pour les instruments. C'est rikiki. Je crains que pour ce module, il faille ruser à mort et faire apparaitre une plage contigue de RAM allant de $0000 à $DFFF. Pas impossible à faire sur le papier, mais affreusement complexe (il faut que le mod saute la page 0).

Bon je vais dire que ce mod fait partie des "trop gros" pour le moment, et pas à cause des données pour les instruments, mais à cause de la partie "pattern" qui n'arrive pas à être réduite.
Auteur:  Prehisto [ 05 Fév 2017, 10:43 ]
Sujet du message:  Re: MOD ?
Samuel Devulder a écrit:
Tu veux parler de ceci: https://modarchive.org/index.php?reques ... uery=39162 ?

Oui.
Samuel Devulder a écrit:
Le traucteur ne bronche pas, mais le module généré envoie mystérieusement le player dans le décors :(
Je dois regarder ce qu'il se passe (besoin d'un pile trop grosse?)

Ça ne m'étonne pas : le MOD utilise toute sorte de commandes dans la partition. À un moment, elle est même lue à reculons. De quoi faire les dents de ton player.
Auteur:  Samuel Devulder [ 05 Fév 2017, 10:58 ]
Sujet du message:  Re: MOD ?
A voir le morceau sous open PMT, on voit que les "patterns" sont chargés, certes, mais pas de quoi être affolé. Je me emane ce qui fait que le compresseur a du mal. Peut-être le tempo qui est très élevé entrainant une forte densité de changements sur les voix.

Sinon si il y a un effet pas supporté par le traducteur:
Code:
EDx    Note Delay    —    Delays the note or instrument change in the same pattern cell by x ticks, if x is less than the current speed.

Mais ca ne change pas grand chose, tellement les ticks vont vites.

Il n'y a pas à dire, ce morceau est un beau torture-test.
Auteur:  gilles [ 05 Fév 2017, 11:08 ]
Sujet du message:  Re: MOD ?
il serait peut être intéressant de distinguer 2 choses dans ton outil:
la retraduction du mod dans un format plus compact (et plus ou moins générique dans différents contextes (autres 8 bits, peu de ram pour ajout dans un loader amiga ou accélérer les chargements disque)). => cette partie peut être utile plus largement sur d'autres plateformes.
le player thomson lui même.
Auteur:  Samuel Devulder [ 05 Fév 2017, 11:21 ]
Sujet du message:  Re: MOD ?
Les deux sont intimement liés. Le principe du player est de faire tourner une sorte de chip virtuelle qui lit des instruction spéciales pour jouer de la musique (comme le SID si j'ai bien compris ce qu'ils font avec ce processeur). L'avantage de ce chip est qu'il peut appeller des sous-routines dans son langage permettant ainsi la factorisation d'instructions communes. Une sorte de procédure en fait. Et c'est en utilisant ca que la compression LZW est réalisée nativement et sans sur-cout.

Cette compression est importante, car comme je l'avais expliqué il y a 1 an à propos du player 1 bit, jouer un morceau de musique de revient à envoyer autour d'une dizaine d'octets aux registres audio (virtuels ou réels) à chaque VBL. C'est à dire qu'on consomme près de 1/2 ko de données par seconde. Sans factorisation, dans 16ko on ne ferait tenir que 30 secs de musique (ce qui est déjà mieux que de recopier directement les échantillons depuis la RAM). La notion de pattern dans un MOD est un premier niveau de compression (à la différence d'un format comme le MIDI), mais c'est encore trop gros pour nous. Il fait aller encore plus loin, d'où l'usage d'un LZW qui détecte et compresse tout seul les bouts de patterns identiques.

A noter: c'est là l'une des diffcultés avec ce morceau: les patterns ont peu de choses similaires les uns avec les autres. Ol le voit assez vite en essayant de compresser le MOD avec GZIP qui peine à être efficace.
Auteur:  Samuel Devulder [ 05 Fév 2017, 22:16 ]
Sujet du message:  Re: MOD ?
Je code la gestion de la supperposition des voix. C'est assez simple. La table des volumes étant symétrique (x*y=y*x), il n'est pas besoin d'en avoir deux. Mais je tombe sur un problème tout con mais bien ennuyeux: ca déborde de 4 octets:
Code:
    122                  7414     f_loop  set     *
     78  2     7414 C6   00               LDB     #0          ; 2
     79  2     7416 CB   00               ADDB    #0          ; 2  LSB freq>>
     81  4     7418 D7   15               STB     <*-3        ; 4
     82  5     741A DC   71               LDD     <smp0      ; 5
     83  2     741C C9   00               ADCB    #0          ; 2
     85  2     741E 89   00               ADCA    #0          ; 2
     86  5     7420 1083 0000             CMPD    #0          ; 5
     88  3     7424 25   DA               BCS     ch0L1      ; 3
     89  3     7426 CC   0000             LDD     #0          ; 3
     91  5     7429 DD   71       ch0L0   STD     <smp0      ; 5 => 33

     78  2     742B C6   00               LDB     #0          ; 2
     79  2     742D CB   00               ADDB    #0          ; 2  LSB freq>>
     81  4     742F D7   2C               STB     <*-3        ; 4
     82  5     7431 DC   7A               LDD     <smp1      ; 5
     83  2     7433 C9   00               ADCB    #0          ; 2
     85  2     7435 89   00               ADCA    #0          ; 2
     86  5     7437 1083 0000             CMPD    #0          ; 5
     88  3     743B 25   C5               BCS     ch1L1      ; 3
     89  3     743D CC   0000             LDD     #0          ; 3
     91  5     7440 DD   7A       ch1L0   STD     <smp1      ; 5 => 33

     78  2     7442 C6   00               LDB     #0          ; 2
     79  2     7444 CB   00               ADDB    #0          ; 2  LSB freq>>
     81  4     7446 D7   43               STB     <*-3        ; 4
     82  5     7448 DC   83               LDD     <smp2      ; 5
     83  2     744A C9   00               ADCB    #0          ; 2
     85  2     744C 89   00               ADCA    #0          ; 2
     86  5     744E 1083 0000             CMPD    #0          ; 5
     88  3     7452 25   B0               BCS     ch2L1      ; 3
     89  3     7454 CC   0000             LDD     #0          ; 3
     91  5     7457 DD   83       ch2L0   STD     <smp2      ; 5 => 33

     78  2     7459 C6   00               LDB     #0          ; 2
     79  2     745B CB   00               ADDB    #0          ; 2  LSB freq>>
     81  4     745D D7   5A               STB     <*-3        ; 4
     82  5     745F DC   8C               LDD     <smp3      ; 5
     83  2     7461 C9   00               ADCB    #0          ; 2
     85  2     7463 89   00               ADCA    #0          ; 2
     86  5     7465 1083 0000             CMPD    #0          ; 5
     88  3     7469 25   9B               BCS     ch3L1      ; 3
     89  3     746B CC   0000             LDD     #0          ; 3
     91  5     746E DD   8C       ch3L0   STD     <smp3      ; 5 => 33

     95  5     7470 F6   FFFF             ldb     $FFFF       ; 5
     96                  7471     smp0   set     *-2
     97  2     7473 C4   0F               andb    #$0F        ; 2
     99  2     7475 CA   F0               orb     #$F0        ; 2
    102  4+1   7477 A6   C5               lda     b,u         ; 5 => 14

     95  5     7479 F6   FFFF             ldb     $FFFF       ; 5
     96                  747A     smp1   set     *-2
     97  2     747C C4   0F               andb    #$0F        ; 2
     99  2     747E CA   F0               orb     #$F0        ; 2
    104  4+1   7480 AB   C5               adda    b,u

     95  5     7482 F6   FFFF             ldb     $FFFF       ; 5
     96                  7483     smp2   set     *-2
     97  2     7485 C4   0F               andb    #$0F        ; 2
     99  2     7487 CA   F0               orb     #$F0        ; 2
    104  4+1   7489 AB   C5               adda    b,u 

     95  5     748B F6   FFFF             ldb     $FFFF       ; 5
     96                  748C     smp3   set     *-2
     99  2     7490 CA   F0               orb     #$F0        ; 2
    104  4+1   7492 AB   C5               adda    b,u       ; 5
    132
    133  4+0   7494 A7   A4               sta     ,y          ; 4 sortie son
    134
    135  4+1   7496 30   1F               leax    -1,x        ; 5

(136) Branch Out Of Range
    136  3     7498 26   FE               bne     f_loop      ; 3 ==> 200 c>>
En effet, cette boucle qui gère les compteurs de chacune des voix et fait le mixage doit tenir dans 128 octets pour que le "bne f_loop" final passe (et que du coup la boucle fasse pile 200µs permettant de jouer à 5khz tout pil). Mais là il y a un octet de trop par voix (ce $*!! e CMPD qui mange 1 cycle et 1 octet de trop je trouve) et je ne sais pas où le chasser. Quelqu'un a une idée ? :bah:
Auteur:  Prehisto [ 05 Fév 2017, 22:35 ]
Sujet du message:  Re: MOD ?
Le "CMPD #0" peut être remplacé par un "SUBD #0" avec le même effet et te fait gagner les 4 octets voulus.
Auteur:  Samuel Devulder [ 05 Fév 2017, 22:39 ]
Sujet du message:  Re: MOD ?
Hélas ca ne marche pas, car il ne faut pas modifier la valeur de D à cause du STD qui suit :(
Auteur:  Prehisto [ 05 Fév 2017, 22:43 ]
Sujet du message:  Re: MOD ?
"SUBD #0" ne change rien du tout. À moins que l'opérande de "CMPD #0" soit variable...
Page 4 sur 19 Heures au format UTC + 1 heure
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/