Logicielsmoto.com

Nous sommes le 15 Sep 2019, 17:14

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 273 messages ]  Aller à la page Précédente  1 ... 13, 14, 15, 16, 17, 18, 19  Suivante
Auteur Message
 Sujet du message: Re: MOD ?
MessagePosté: 17 Sep 2017, 07:48 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 417
Localisation: France
Il y a 3 samples mixés, chacun avec un volume entre 1 et 7. La somme est donc entre 3 et 21, correspondant aux routines core0 à core19, si j'ai bien suivi.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: MOD ?
MessagePosté: 17 Sep 2017, 10:13 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1111
Localisation: Brest
Samuel Devulder a écrit:
[EDIT] Hum tout n'est peut être pas perdu... j'ai une idée pour booster un peu la boucle principale sans trop perdre en RAM.

L'idée est la suivante: on a dejà plusieurs versions pour les instruments en fonction de leur volume. Alors, en constatant que pour un instrument donné il n'y a pas tellement de notes jouées, on pourrait imaginer autant d'instruments que de notes et volumes joués pour cet instrument là. Jouer un morceau revient juste à lire les échantillons un à un de chaque instrument de chaque voix. C'est tout!
Code:
* joue une voix
l1  ldx  #nnnn ; (3) pointeur instru
    ldb  ,x+   ; (6) lecture échantillon
    cmpx #nnnn ; (4) fin instru ?
    beq  l2    ; (3) oui ==> rebouclage (i)
    bra  l3    ;     non ==> sauvegarde (ii)
l2  ldx  #nnnn ; (3) rebouclage
l3  stx  l1+1  ; (5) sauve ptr instru
    andb #bit  ; (2) choix bitstream
    ldb  b,u   ; (5) valeur buzzer pour bit choisi
    stb  ,y    ; (4) sortie buzzer
* total = 35µs
La boucle devient très courte. On peut même la faire tomber à 32µs en constatant que l'astuce beq/bra en (i) et (ii) utilisée pour avoir un timing constant n'est que rarement utilisée: 1 fois par instru, cad 1 fois tous les 1000 échantillons, et on pourrait se contenter d'un seul bne, faisant gagner 3 cycles cpu.

Avec 32µs/voix, l'ensemble des 4 voix + deca + bne coute 133µs au lieu de 200µs. Ces 133µs donnent une routine sortant les 4 voix à 7,6khz. C'est pas mal.. mais j'aimerais pouvoir encore faire plus rapide.

Un truc qui prends des cycles c'est le cmpx pour savoir si on a atteint le dernier échantillon de l'instru. J'ai bien imaginé de le virer au profit d'un test sur le bit N(eg) à l'issu du ldb, mais c'est idiot car sur l'octet chargé on a 7 échantillons, et si l'un a atteint sa fin, ca n'est pas le cas des 6 autres. Il faut être plus malin...

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 17 Sep 2017, 10:49, édité 2 fois.

Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: MOD ?
MessagePosté: 17 Sep 2017, 10:21 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1111
Localisation: Brest
Citation:
plus malin...

En fait on pourrait dire que le bit 7 de l'échantillon sert à avertir que c'est un échantillon de milieu d'instru ou un échantillon de fin pour l'un des 6 instruments auquel cas on fait le CMPX pour savoir si c'est notre instrument ou pas. L'idée c'est que souvent, très souvent on ne fait pas de CMPX, et quelque fois, quand l'un des instruments de l'octet a atteint sa fin, on fait le CMPX exact mais plus lent. Rarement plus lent, et fréquemment plus rapide, donc on gagne en moyenne!
Code:
* joue une voix
l1  ldx  #nnnn ; (3) pointeur instru
    ldb  ,x+   ; (6) lecture échantillon
    bpl  l3      (3)
    cmpx #nnnn ; (4) fin instru ?
    bne  l3    ; (3) non ==> sauvegarde (ii)
    ldx  #nnnn ; (3) rebouclage
l3  stx  <l1+1 ; (5) sauve ptr instru
    andb #bit  ; (2) choix bitstream
    ldb  b,u   ; (5) valeur buzzer pour bit choisi
    stb  ,y    ; (4) sortie buzzer
* min = 27µs, max = 34µs
Ca nous donne la plupart du temps le traitement des 4 boucles à 4*27+2+3=113µs, soit un playback à 8,8khz. C'est mieux!

Mais à présent ce qui prends du temps c'est le couple ldx/stx en l1/l3. Si on pouvait avoir plusieurs "x" ca serait pas mal. On a 4 regs d'addresse donc ca serait jouable, mais le "b,u" permettant de trouver la valeur du buzzer en fonction du bit ne pourrait plus être utllisé, pas plus que le ",y" sortant le buzzer... groumph :L

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 17 Sep 2017, 10:51, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: MOD ?
MessagePosté: 17 Sep 2017, 10:44 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1111
Localisation: Brest
Allez, voyons ce qu'on peut faire pour jouer une voix jouant l'instrument pointé par le registre "y" (mais x,s, ou u iraient aussi)
Code:
* joue une voix
l1  ldb  ,y+   ; (6) lecture échantillon
    bpl  l3      (3) échantillon normal ?
    cmpy #nnnn ; (5) fin instru ?
    bne  l3    ; (3) non ==> choix stream
    ldy  #nnnn ; (4) rebouclage
l3  andb #bit  ; (2) choix bitstream
    stb  <l4+2 ; (4) mise à jour ptr bit->buz
l4  ldb  tab   ; (5) valeur buzzer pour bit choisi (addresse auto-modifiée)
    stb  $e7c1 ; (5) sortie buzzer
* min = 21µs, max = 37µs

Hum 21µs et c'est carrément bon ca, ca pousse l'ensemble de la boucle pour les 4 voix + bouclage à 11khz :cool: Alors oui c'est pas une boucle en temps constant car la fin d'instru ne prend pas le même timing si on est sur x,y,u ou s. Mais on va considérer que cela n'arrive pas suffisamment souvent pour perturber la perception (c'est juste des cycles volés de-ci, de-là comme si on avait eu une interruption.)

Rah... ca mérite un essai (Je m'inquiète en particulier du nombre d'instruments que font les couples volumes/notes combinés. Il faut que tout tienne en ram, à raison de 7 instruments par octets.)

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: MOD ?
MessagePosté: 17 Sep 2017, 11:42 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 417
Localisation: France
Je dirais qu'on peut se débarasser complètement du réglage de volume ou de n'avoir que quelques réglages possibles (genre seulement 4 volumes différents). Pas en convertissant des MODs existants, probablement, mais en embauchant un musicien qui sait travailler avec ce genre de contraintes.

Pour ça on peut demander de l'aide sur le site des petites annonces de la demoscene: http://wanted.scene.org .
Ou même contacter les gens qui ont déjà déposé des annonces pour proposer leur aide, par exemple: http://wanted.scene.org/post/8/music-fo ... ices-1-bit


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: MOD ?
MessagePosté: 17 Sep 2017, 20:34 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1111
Localisation: Brest
Oui mais en attendant on a les mods existants... et pour ceux-là il y a un problème. Les commandes types "glissando" ou "arpèges" modifient la fréquence sans ré-initialiser le pointeur "sample". C'est quelque chose qu'on ne peut pas faire avec la toute dernière version du player. Changer la frequence revient à changer d'instrument et donc repartir du début des échantillons. C'est nul, archi nul comme approche finalement si on ne peut pas faire d'arpèges :non: Mince, et moi qui pensais avoir le truc ultime. Zut et re-zut :evil: :mad:

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: MOD ?
MessagePosté: 18 Sep 2017, 21:03 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1111
Localisation: Brest
Hum j'ai une idée pour les arpèges.

En fait le soucis est de passer d'un instrument jouant une note N1 à celui du même instrument à une note N2 sans perdre "l'endroit" où l'on se situe dans la suite d'échantillons. A la note N1 correspond un sample de longueur L1, et à la note N2 correspond un sample de longueur L2. Nous sommes à une position x du 1er instrument, et nous passons à la position y de l'instrument 2, de sorte que x et y soient relativement à la même position dans les échantillons. Mis en equation on veut que: x/L1 = y/L2, soit y = (L2*x)/L1.

Oui c'est une bonne vieille règle de 3, avec x, L1 et L2 des entiers 16bits. C'est là qu'il faut être ingénieux, car faire une multiplication 16bits x 16bits -> 32bits suivi d'une division 32bits / 16bits --> 16 bits va consommer un max de cycles.

On remarque qu'on a pas forcément besoin d'une forte précision dans la position y. A la limite si elle est précise à 1% c'est déjà largement bon. Cela veut dire que si on peut pré-calculer k=L2/L1 à 1% près on aura un calcul simplifié car il ne faudra plus que multiplier x par k. Je propose de représenter k par un nombre de la forme k'/128. C'est pas mal, car k variant typiquement entre 0.5 et 2 (on fait rarement un arpège à plus de 1 octave d'écart par rapport à la note courante, ert le format mod l'interdit), k' varie entre 64 et 256 par pas de 0.78%. On a toujours notre précision de 1%*. En plus il peut être stocké sur un octet, et une multiplication 16 bits x 8 bits c'est assez rapide tout compte fait.

Dans cette approche, la commande de changement d'instru sans changement de position relative contiendrait 1 octet supplémentaire encodant le facteur de proportionalité k'. C'est un peu plus gourmand en RAM, mais c'est ce qu'il faut si on veut un truc pas trop lent.

Bon je ne sais pas si je suis clair clair, mais disons qu'il y aurait moyen de supporter correctement les arpèges avec le principe d'un instrument par notes différentes. C'est une bonne chose :good:

Reste à voir combien il faudrait d'instruments pour un morceau typique...

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: MOD ?
MessagePosté: 18 Sep 2017, 21:29 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1111
Localisation: Brest
Samuel Devulder a écrit:
Reste à voir combien il faudrait d'instruments pour un morceau typique...

J'ai fait une estimation rapide sur "behind the wheel" des dépèche-mode. Il y aurait quelque chose comme 102 instruments-notes, soit un total d'environ 400 000 échantillons. A raison de (pour simplifier) 8 échantillons par octets cela occupe 50Ko en ram. Bon on en a au max 48.... C'est chaud.

Voyons avec un autre morceau. Par exemple la musique du titre de shadow of the beast: 117 instruments, on est sensiblement pareil, mais .. oulà... 2 000 000 échantillions, et ca, même à raison de 8 échantillons par octets, c'est trop gros pour la ram dispo.

Bon on a peut-être pas de bol avec ce morceau, allez un 3e: ChuckRock... 272 instruments (je crains le pire), et un total de 1 000 000 échantillons. Encore trop gros :( :(

Bon on a un problème de taille. Ok l'approche 1 note = 1 instrument permet d'aller vite, et donc d'avoir une meilleur qualité pour les morceaux, mais on perd beaucoup de place en mémoire tout compte fait.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: MOD ?
MessagePosté: 19 Sep 2017, 06:20 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 417
Localisation: France
Peut-être qu'il faut essayer avec des MODs qui font plus "chiptune" et qui ont tendance à utiliser des samples assez courts.

Par exemple: https://modarchive.org/index.php?reques ... uery=66426


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: MOD ?
MessagePosté: 19 Sep 2017, 18:32 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1111
Localisation: Brest
Oui mais j'aime bien les vieux mods qui m'épataient dans le temps comme celui-ci (plein de 90's inside): http://artscene.textfiles.com/music/mod ... apower.mod

En revenant sur la version initiale, je me rends compte que question fréquence on dépasse assez peu le 256. Si bien qu'on pourrait dire qu'un instrument joue à sa fréquence max revient à avoir un compteur incrémenté de 256/256==1 octet à la fois. Les autres notes sont plus basses, et donc incrémentées de x/256 avec x<256. Par exemple avec x=128 on joue à l'octave immédiatement en dessous. Du coup j'ai eu l'idée de ne plus utiliser un compteur sur 16bits, mais uniquement sur 8 bits. On obtient le squelette de code suivant:
Code:
        org     $nn00
        setdp   $nn
      
TAB     RMB     64     ; table pour valeurs E7C1
      RMB 1
* toujours dans le même segment "DP"
loop    pshs    x,y,u,cc
        sts     <sav_S   
        orcc    #$50

        sta     <loop-1   ; tourne D fois
        tfr     b,a

        ldx     #ptr
p_X     set     *-2
        ldy     #ptr
p_Y     set     *-2
        lds     #ptr
p_S     set     *-2
        ldu     #ptr
p_U     set     *-2
       
voix_Y  LDB     #0      ; 2
        ADDB    #ff     ; 2
        STB     <xx     ; 4
        BCS     ZZZ     ; 3
        LDB     ,Y      ; 4
        BRA     *+4     ; 3
ZZZ     LDB     ,Y+     ; 6
        BPL     XXX     ; 3
        CMPY    #nnnn   ; fin instrument?
        BCS     XXX     ; non => suite
        LDY     #ssss   ; rebouclage
XXX     ANDB    #bit_instru ; 2
        STB     <YYY+1  ; 4
YYY     LDB     <TAB    ; 4
        STB     $E7C1   ; 5 => 35µs la plupart du temps

* idem voix_X         ; 35µs
* idem voix_S         ; 35µs
* idem voix_U         ; 35µs
       
        deca         ; 2
        bne     voix_Y  ; 5 boucle
      
        dec     <loop-1
        bne     voix_Y
* total voix + bouclage == ???

       
        stx     <p_X
        sty     <p_Y
        stu     <p_U
        sts     <p_S
       
        lds     #0
sav_S   set     *-2
        puls    x,y,u,cc,pc


Qu'est ce qui change ?
  • Et bien déjà on ne passe pas son temps à écrire et lire en mémoire les pointeurs instrument. Ces pointeurs restent dans des registres tout le temps de la boucle.
  • L'incrément sur le pointeur d'instrument n'est plus fait par un "ADCB #0;ABX" mais est directement réalisé dans le LDB qui va charger l'échantillon ( :bien: ). Comme on incrément au plus de 1 et uniquement de temps en temps, c'est pas mal. Les deux chemins sur cette partie ne se font pas en temps identiques. L'un des chemins (ldb ,reg + bra) prend 7 cycle, et l'autre (ldb ,reg+) en prends 6. C'est très voisin, et en moyenne on prend (6+7)/2=6.5 cycles ici
  • Du coup le code est plus petit, tellement petit qu'on peut s'arranger pour qu'il cohabite avec la TAB qui donne la valeur de E7C1 à appliquer (buzzer à 0 partout sauf pour les valeurs 1<<i, i=0..6). On utilise donc l'accès direct la plupart du temps, et en particulier pour simuler l'ancien "ldb b,u" juste avant l'écriture en $E7C1.
  • On garde le registre A intact tout du long, ce qui fait que le bouclage D fois peut être découpé en 2 boucles ipmbriquées, l'une où l'on itère "A" fois rapidement, et l'autre ou l'on itère "B" (stocké dans loop-1) fois, un peu plus lentement, mais c'est pas grave car ca n'arrive pas souvent.
Au final avec cette architecture du code, la boucle jouant les instruments se fait la plupart du temps en 35*4+2+3 = 145µs. C'est à dire qu'on passe d'un rendu à 5khz à carrément 6.9khz!!! La qualité devrait être meilleure. :cool:

Bon j'ai pas encore testé, car il faut que je pousse l'analyse un peu plus loin pour les instruments non bouclants. En effet, ceux là ralentissent l'execution. Je m'explique: arrivé en fin d'instrument le test "BPL XXX" est faux et on fait le CMPreg #fin qui suit. Ok. Comme on est à la fin del l'instru on execute alors le "LDreg #fin" aussi ce qui ne change pas la valeur du reg. Donc contrairement aux échantillons de milieu d'instruments, ici on se tape 5+4 cycles de plus que les 35. Une fois de temps en temps c'est pas gênant, mais comme c'est un instrument "sans bouclage" et que le registre ne change pas de valeur (on reste coincé sur le dernier échantillon), au tour suivant on se re-tape encore une fois ces 9 cycles. Donc pour ces instruments, la gestion de la voix passe de 35µs à 44µs (+26%). C'est signifcativement plus lent: ca va jouer super faux!

Pour s'en sortir, il faudrait ne pas rester stationner en fin d'instrument mais repartir au début tout en éteignant la voix. Eteindre la voix c'est facile, il suffit d'annuler la valeur du ANDB qui suit, comme ca on ne sortira plus que 0 sur cette voix. Cette modif donnerait quelque chose comme:
Code:
        BPL     XXX     ; 3
        CMPY    #nnnn   ; fin instrument?
        BCS     XXX     ; non => suite
        LDY     #debut ; rebouclage
        CLR     <XXX+1  ; ou "nop;nop" si l'instrument est reobuclant
XXX     ANDB    #bit_instru ; 2

Ca rallonge un peu le code, mais ca devrait faire le truc: empêcher de rester coincer longtemps en fin d'instrumentsur les CMPreg/LDreg. Il faut que je vois si ca nous fait sortir de la zone DirectPage ou pas ou si la boucle dépasse 128 octets auquel cas on ne pourra pas faire des beq simples après le décompte "D", mais il faudra utiliser des long-branch, nettement plus longs.

... reste à mettre cette belle théorie en pratique. J'espère qu'un son à 7khz sera nettement mieux qu'à 5khz. :voyons:

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: MOD ?
MessagePosté: 19 Sep 2017, 18:41 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 417
Localisation: France
Pour couper un instrument, il y a d'autres solutions. La plus maline me semble être de mettre la fréquence à 0. Du coup, on met le pointeur au début de l'instrument, mais il n'est jamais incrémenté et du coup on atteint jamais la fin. Et ça ne coûte pas plus de temps machine que de préparer le début d'une note.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: MOD ?
MessagePosté: 19 Sep 2017, 18:48 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1111
Localisation: Brest
Oui ca revient à faire "CLR <voix_Y+1" au lieu de "clr <XXX+1". C'est kif-kif.

Héhé, il me tarde d'essayer, car je suis tombé sur un algo de construction de PWM très très simple et qui marche plutot mieux que les trucs sophisitiqués. En gros: on compare le signal à une série de dents-de-scie. Si le signal est plus peti que la valeur courant de la dent de scie, on sort un 0, sinon un 1. Ca encore facilement et très précisément un PWM. Aveccet encodage on a moins le bruit d'aspirateur du test précédent.


Fichiers joints:
Commentaire: Toujours 5khz, mais un meilleur PWM je trouve
tst.zip [59.97 Kio]
Téléchargé 79 fois

_________________
Good morning, that's a nice Tnetennba
Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: MOD ?
MessagePosté: 21 Sep 2017, 11:10 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1111
Localisation: Brest
Bon, j'ai analysé le code à la recherche de pourquoi c'était mieux et il s'avère que ca marche.... à cause d'un bug :eek:

Une fois le bug corrigé (sons bien trop faibles à cause du filtre passe-bas mal étalonné) , et bien le son est à nouveau tout pourri. Le pire c'est que je n'arrive plus à retomber sur un son approximativement meilleur. Je suis coincé sur un son tout pourri.

De ce que j'ai l'impression, c'est que nos 5-7khz sont des fréquences finalement bien trop basses pour faire un pwm correct. Il y a sans arret des distorsions. Ce que je ne comprends pas en revanche, c'est pourquoi sur ZX le son est si détaillé, et nettement moins bruité. Ils ne sont pas tellement au dessus de nos 7khz avec leurs 9khz.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: MOD ?
MessagePosté: 22 Sep 2017, 10:58 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1111
Localisation: Brest
Je me pose une question: je sais que le bit 3 de $E7C1 sur les TO pilote le buzzer. Mais que pilotent les bits 0 à 2 ? (c'est pour savoir si je peux écrire n'importe quoi sur ces bits sans perturber la machine)

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: MOD ?
MessagePosté: 22 Sep 2017, 11:19 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
b0 et b1 servent à la gestion du clavier sur les TO8/TO8D.

_________________
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  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 273 messages ]  Aller à la page Précédente  1 ... 13, 14, 15, 16, 17, 18, 19  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 3 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