Re: [SNES] Projet A-RPG

[Invité]

Mais n'importe nawak O_o ?? C'est un choix de design (et un bon choix), c'est justement parce-que le 68k a peu besoin du BUS et qui laisse les autres composants en profiter que l'amiga est aussi puissant.

Ah bon ??
Sais tu au moins comment fonctionne l'amiga ??, je pense que non ..
D'ailleurs tu te contredis, du choix du 68K pour ses perfs, on passe à c'est car il laisse des cycles aux autres composants(ce qui est vrai).
Et je persiste, les perfs de l'amiga sont liées a son chipset, pas au 68K,tu peux demander à ninja_SCX ici qui fait partie du groupe scoopex .

Dsl, mais sérieux j'ai pas envie de répondre sur des sujets débattus 1000x déjà .

Tu parles encore de roms alors que tu sais pertinemment que la Md a besoin de rom à 150 ns (soit aussi rapides que sur PCE) a cause de son DMA, même si le CPU peut se contenter de bcp moins .

Je te l'avais dit, sur spritesminds ils te l'ont dit aussi,tu peux te contenter de roms lentes sur Md, à la seule condition de ne pas utiliser le DMA ce qui est fortement improbable même dans les premiers jeux .

Si tu considère le 65816 pourri, tu considères aussi le CPU de la PCE pourri, malgré qu'il tourne à 7,16 mhz, et là on est plus dans la même cours,et je considère le 68k comme lent,et il l'est,c'est un CPU pas du tout adapté a une console en terme d'efficacité, point barre .

Un CPU qui génère un code lourd qui met 3 plombes à faire un saut conditionné,appel/retour de fonctions,interrutpions, accès mémoire, j'appelle pas ça un CPU efficace dans un système limité qui à besoins surtout d'efficacité comme une console de jeu .
Bon je vais arrêter parce que de toutes façons ça ne mène à rien,avec toi le débat a toujours été impossible à part dire que tout ce qui sort de l'univers SEGA c'est de la merde .

[Alucardark]

Autant j'aime vos débats enflammés dans le topic SNES vs Megadrive (même si j'y comprends que la moitié, et encore), car mine de rien on en apprend beaucoup sur les machines et ce qui a pu pousser les constructeurs à les choisir (mais aussi les développeurs à s'adapter selon la machine sur laquelle ils bossaient), autant le fait d'exporter le conflit ici n'apporte rien, mais alors du tout.

Sinon, et pour en revenir au sujet, je trouve que tu assures vraiment Kannagi (surtout avec une machine visiblement chiante à programmer comme la SNES). Du coup pour la suite, est-ce que tu vas utiliser d'autres effets de la SNES?

[Stef]

Ouais je suis d'accord surtout que là Touko part vraiment en délire , mélange tout et n'importe quoi... Y'a rien a répondre la dessus. Revenons au sujet ^^

[Invité]

Ouais je suis d'accord surtout que là Touko part vraiment en délire , mélange tout et n'importe quoi... Y'a rien a répondre la dessus. Revenons au sujet ^^

Mais oui, toi tu détiens la vérité,et sais de quoi tu parles ...
Faut que je mette le lien qui contredit ce que tu soutenais sur les ROMS MD ??
CAD que je te disais qu'il fallait des ROM 150ns à cause du DMA de la MD, alors que tu soutenais que des roms bcp plus lentes étaient utilisées dans les premiers jeux ??

Bien sur pour ceux qui ne lisent pas les discussions sur les forums comme spritesmind ou snesdev,tu peux faire encore illusion en disant que je sais pas de quoi je parle, et que je mélange tout .

Aller cadeau : http://gendev.spritesmind.net/forum/viewtopic.php?f=22&t=1368&start=30

A force de montrer que tu te goures 9O% du temps, ça commence à devenir lourd, surtout que tu changes pas de mentalité .
Que tu ais des préférences sur un CPU,un système, c'est normal (on est tous pareil), mais que tu craches sans arrêt sur tout le reste, fatigue à la longue.

autant le fait d'exporter le conflit ici n'apporte rien, mais alors du tout.

Je veux pas dire mais cela n'arriverait pas si stef n'avait pas la fâcheuse habitude de cracher sur tout autre chose qu'un 68K ou une MD .

Quand tu ramènes à la fréquence mémoire, les branchements ne sont pas "si lent" : 10 cycles soit 2.5 cycle en cycle mémoire, 1 pour lire l'instruction, 1 pour lire l'offset et un demi pour la fin du maj du prefetch, c'est raisonnable (tu peux faire un JMP en 8 cycles en utilisant un registre si t'as vraiment besoin). Sur le 65xx j'imagine que c'est 3 cycles minimum non ? ce qui, ramené à la fréquence mémoire, n'est pas mieux... La différence c'est qu'un branchement 8 ou 16 bits ne sera pas plus lent sur 68000.
Après oui les interruptions sont lentes, ca c'est vrai... mais c'est que le mécanisme d'interruption du 68000 est autrement plus complexe.
Le C64 c'est plutot le reste de son architecture qu'il faut remercier surtout je trouve... Sinon dans ce cas, regarde ce qu'un Amiga peut faire avec un 68000 à 7 Mhz (soit 1.75 Mhz sur le BUS), d'ailleurs c'est grace à la sobriété du 68000 sur l'utilisation du BUS mémoire que l'amiga peut faire tant de chose au final car les autres chips peuvent partager la mémoire avec lui. Dans les mêmes conditions, il aurait fallu mettre un 65816 à 1.75 Mhz et je pense que l'amiga n'aurait probablement pas autant brillé :p

Voilà, donc stef aime bien dénigrer, mais ne supporte pas que toi tu n'aimes pas ce qu'il aime, et que tu sortes une critique quelconque, donc comme on ne peut pas avoir de débat utile avec lui, ça part en vrille .
Mais bon je commence à bien le connaitre, il fait la même chose sur le forum de snesdev .

[Stef]

Les autres savent lire Touko, je pense que depuis le temps ils savent qui de nous 2 raconte n'importe quoi ;-) Et vraiment si tu veux en discuter, continue sur le topic MD vs SNES :-)

[Invité]

Vous vous fightez partout
Même sur NesDev lol

@Alucardark
Ben merci :)
Je pense utiliser le mode 7 (avec le HDMA) pour avoir un rendu comme dans SOM ou mario kart , pour la map world , pour ma prochaine démo je travaille dessus.
Mais il est vrai que j'utilise pas mal de chose de la SNES maintenant , le seul truc que je n'ai jamais utilisé sur SNES c'est je crois sa possibilité de faire des mask.
C'est l'effet qu'on voit par exemple sur super metroid avec la lampe (du coup donkey kong country l'utilise aussi).

[Alucardark]

Ben merci :)
Je pense utiliser le mode 7 (avec le HDMA) pour avoir un rendu comme dans SOM ou mario kart , pour la map world , pour ma prochaine démo je travaille dessus.
Mais il est vrai que j'utilise pas mal de chose de la SNES maintenant , le seul truc que je n'ai jamais utilisé sur SNES c'est je crois sa possibilité de faire des mask.
C'est l'effet qu'on voit par exemple sur super metroid avec la lampe (du coup donkey kong country l'utilise aussi).

J'avais testé le HDMA sur Super Mario World avec Lunar Magic (c'était une espèce de plugin) et ça rendait vraiment bien (enfin c'était plutôt 2/3 effets de distorsions dans les niveaux de l'eau et de la lave, rien à voir avec ce que tu fais ^^! ). En tout cas j'ai hâte de voir la manière dont tu vas utiliser le mode 7 ou encore l'effet de masque (surtout pour ce dernier qui a l'air compliqué à mettre en place? ).

[Invité]

L'effet de masque j'avais juste prévue de l'utiliser occasionnellement , de ce que je vois sur la doc SNES elle me semble pas si compliqué a utiliser a voir ^^

La HDMA je ne suis pas fan de son utilisation ,je le trouve compliqué a utilisé.

[Invité]

Allez une mise a jour :)

Le mode 7 dispo enfin
D'ailleurs je trouve dommage que la SNES n'est pas assez puissante pour exploiter ce mode , c'est assez ironique je trouve x)
Inutile de vous dire que j'en ai chier grave pour faire la perspective ?



Cela marche sur une vrai SNES , j'ai voulu quand même tester parce que dans le passé j'ai eu des bugs avec l'interruption IRQ :
https://2img.net/r/hpimg15/pics/93398220160412152418.jpg
Au final cela marche tres bien ^^

Et une vidéo de démonstration (vers la fin le mode 7) :
https://www.youtube.com/watch?v=ik8gEbf3Et4&feature=youtu.be

Il faut appuyer sur start/select pour aller au  mode 7.

Link : http://www.mediafire.com/download/wxkh7ue4fv4xsdp/The+World+of+Demon.zip
NesBox : http://pixelretro.hebergratuit.net/NesBox/snes.html

[Invité]

Génial !!

Fais moi penser a rejoindre mon "Studio" pour mon prochain projet rétro ... Des Jedis comme toi qui maitrisent leur sujet ça court pas les rues ... Surtout quand ils proposent du concret.

Bon du coup, tu nous pond un véritable jeu ou juste une succession de démos techniques ??

Tres bon boulot dans tous les cas, surtout pour un jeune de ton âge qui s'est penché sur une technologie d'un quart de siècle ...

[Invité]

Merci

'Jedis comme moi' , non quand même pas, il suffit juste d'avoir de la patience,de la volonté et un peu de passion , il est vrai que au début c'est moins fun que le travail prémâché mais au long terme ça paye bien
Ben j'y travaille sur mon jeu le Mode 7 je compte le mettre pour la map monde, je suis un peu ambitieux sur mes projets donc ça traînes
De plus je suis très pointilleux niveau code alors si le code est pas bon j'avance pas tant qu'il ne me plaît pas xD

Pour ton Studio , Il faudra voir tu me met quand a l’assembleur ?
Après y a sûrement moyen de mélanger Bex et asm , l'avantage de l'asm c'est que tu n'est plus limité a la MD du coup ^^
De plus la MD est la seule que j'ai pas encore touché

Tres bon boulot dans tous les cas, surtout pour un jeune de ton âge qui s'est penché sur une technologie d'un quart de siècle ...

Imagine la génération suivante x)
Plus le temps passe plus il se fera rare :/
La plupart des prog assembleurs sont des personnes qui ont commencé sur des vielles machines , moi j'ai commencé avec Windows 98 (et j'avais 10 ans) et la programmation jamais touché jusqu’à mes 19-20 ans !

[Invité]

L'assembleur c'est prévu pour le prochain projet ... Mais un truc minimaliste quoi !! ;-)

[vingazole]

Le mode 7 dispo enfin

Excellent !

[Invité]

Bon quelque news , vu que la partie 'moteur graphique' est quasiment au point j'ai pas des masses avancé dessus
J'ai bossé sur le SPC700 pour ma part après de longue étude et de questionnement, je suis allé enfaîte sur un truc simple conversion de midi sur SNES.

Voila le résultat :
https://www.dropbox.com/s/m4kawui96mk6o8p/testsn.wav?dl=0
(la musique  vient d'une SNES évidemment) et marche sur une vrai SNES.
Alors je n'utilise qu'un canal actuellement.
Je pense que avec 8 canaux utilisé et les bons samples on peut espérer avoir le bon truc

Une musique fait maximun 12ko (8 canaux) , et le sample utilisé ne fait que 54ko x).
Je réfléchis si je ne peux pas réduire un peux la taille de la partition , mais bon la prog du SPC700 est vraiment chiante.

Quand mon driver sera fini je partager mes outils :
-un convertisseur wav/brr(format des sample SNES).
-un convertisseur midi/partition (pour mon driver sonore).

Pour le son j'ai du quand même moduler un peu pour qu'il a cet effet de 'piano'.

[Stef]

J'admire le fait que tu ais réussi à faire ton propre driver SPC700 si j'ai bien compris :)
Mais sinon c'est moi où il y a un soucis dans les notes ? On dirait que c'est légèrement détuné.. un truc qui arrive assez souvent sur SNES comme s'il y avait une difficulté pour reproduire certaines notes mais je ne vois pas pourquoi.

[Invité]

Oui j'ai bien refait mon propre driver , principalement pour avoir des musiques compressé comparé a l'autre driver sonore de la SNES avec je que j'ai actuellement  je peut dire que si j'ai 40 musique en moyenne qui font 10ko ça me fait donc 400ko , c'est correct je trouve.
Même si y'a sûrement moyen de compresser ça :)
Deja sur Secret of Mana il y'a pas mal de canal qui joue la même partition (mais avec un instrut différent).
bien sur je suis dans la partie haute (max en ko) ça fera j'espere un peu moins (300ko pour le tout serait top)

Parce que les sons sur SNES (enfin les jeux) ne sont pas vraiment des samples 'pur' dans le sens ou il prenne juste un sample assez simple (d'une centaine octet max) qu'il module , cette modulation du son a ces limites.

Je pense que c'est ce casser la tête de vouloir avoir de vrai sample (dans le sens un sample de 0.250ms ou 0.100ms) , ça prend bcp en mémoire , mais c'est ce que font apparemment la scène homebrew , bien sur la on peut avoir la qualité suffisant d'un vrai instrument , mais ce n'est pas la solution que j'utiliserai :)

[Invité]

Oui je m'auto répond , enfaîte si tu parle de la fréquence des notes , j'ai fait les frequence un peu en random.

Mais je compte implémenter donc les bonnes fréquences mais même avec ça , ça ne sera pas précis , il y'a 14 bits pour les 32 000 HZ donc si on considère C0 = $10 ça fait 31,296HZ alors que ça devrait être 32,7 Hz.

[TotOOntHeMooN]

Je ne connais pas la SNES, mais ça ressemble quand même à un multiple de 32768 ta fréquence désirée.
Si tu es seulement en 14bit, car veut dire que tu as un pas de 2Hz.

[Invité]

C'est cela , j'ai je que j'ai remarqué ^^
Donc je pense que il mettent les octave de cette façon :
$10 ,$20,$40,$80,$100 ect

[Invité]

Bon ça s'améliore avec le bon pitch , la mélodie a plus de 'forme' bon j'ai pris un autre midi :
https://www.dropbox.com/s/cprq451tyh9yjru/testsn2.wav?dl=0
Le Sample fait 9ko (sinusoide).

Il faudrait vraiment faire un petit éditeur pour pouvoir choisir l'effet voulu sur le son , parce que y'aller en hexa+audacity c'est assez chiant XD

[TotOOntHeMooN]

Cool. J'écoute ça à midi !

[Stef]

Bon ça s'améliore avec le bon pitch , la mélodie a plus de 'forme' bon j'ai pris un autre midi :
https://www.dropbox.com/s/cprq451tyh9yjru/testsn2.wav?dl=0
Le Sample fait 9ko (sinusoide).

Il faudrait vraiment faire un petit éditeur pour pouvoir choisir l'effet voulu sur le son , parce que y'aller en hexa+audacity c'est assez chiant XD

Merci pour tes réponses. Alors oui le problème du sample c'est la place en effet, je sais que les 64 ko de mémoire alloué en tout et pour tout sont assez limitant. Mais là oui je parlais surtout de la fréquence des notes. Sur SNES je remarque assez souvent des notes qui sonnent faux, comme si la fréquence était un peu en dessous ou au dessus. Encore si tout était détuné de la même manière mais ce n'est pas le cas, c'est juste certaines notes qui sonnent faux. Et là ton dernier exemple est un cas concret je trouve ! La plupart des notes sont à côté :-/ Je ne comprends pas O_o ?? tu as repris les fréquences de l'original ?

Sinon pour ton driver, tu dis compresser le son. En fait c'est ton format de musique qui est assez optimisé si j'ai bien compris ? Et tu alloues un minimum pour les samples pour réduire encore ? Je réfléchis à implémenter un nouveau driver sur MD plus interessant en terme de taille de musique car le XGM (dérivé du VGM) reste assez lourd vu que c'est un simple log de commande (entre 10 et 100 ko par musique, c'est quand même beaucoup)...

[Invité]

Sur celui la : https://www.dropbox.com/s/cprq451tyh9yjru/testsn2.wav?dl=0
Non je ne pense pas m’être trompé sur le pitch les fréquences sont les bonnes ^^
Sur le premier oui , je ne savait pas ce que c'était C0 , C1 ect ^^
Je pense que les notes sonne un peu faux vu que comme j'ai un manque de précision de +-5% de fréquence comparé a la norme :
https://fr.wikipedia.org/wiki/Note_de_musique#Fr.C3.A9quence
Après mon son est assez simple ce qui ne permet  pas de cacher cette erreur de précision je pense.

Sinon pour ton driver, tu dis compresser le son. En fait c'est ton format de musique qui est assez optimisé si j'ai bien compris ? Et tu alloues un minimum pour les samples pour réduire encore ?

Exact.
Pour ma part un track comporte un event de ce type la :
delta time (debut de note) , pitch , volume , delta time(fin de notes)
Le delta times fait 1 ou 2 octet. (je regarde le bit de poids fort pour savoir si c'est sur 1 ou 2 octet)
Le pitch sur un octet comme ceci : XY
X : Octave
Y : Notes
Volume sur un octet aussi.

Plus l’entête du track (chez moi de 10 octet info sur l'utilisation du sample , et les différent effet dessus).
1 track = 1 canal.
Ensuite j'ai un fichier d'info général pour la musique (volume général , nombre de canal utilisé , temps de la musique ect).

Bonne chance pour ton driver , dit toi que le z80 est plus mangeable que le SPC700 (qui est vraiment horrible comme syntaxe).
un track fait 1ko en moyenne (donc 8ko), pour ma part ce n'est pas souhaitable que chaque canaux soit très utilisé (ça risque de poser soucis pour les sons du jeux) , le mieux est d'utiliser principalement 5 canaux et 3 autres pour des partitions de fond.
Donc ça sera peut être dans les faits un peu moins que 8ko par musique(enfin j'espere).

[vingazole]

Je pense que les notes sonne un peu faux vu que comme j'ai un manque de précision de +-5% de fréquence comparé a la norme

C'est énorme +-5%, sur un LA 440 ça te fait une fourchette de 418 Hz (un poil au-dessus du LAb qui est à 415,30 Hz) à 462 Hz (plus proche du LA# à 466,16 Hz que du LA "naturel") !  

[Invité]

Salut Vingazole ça fait un bail
Ben oui c'est énorme mais je peux pas faire grand chose vu que 32.7 HZ de C0 ben je peux pas le faire.
Je peux normalement faire un 31.4 HZ x)
Sauf si j'ai mal calculer les conversions pitch/HZ de la SNES je vérifierai au cas ou.

[vingazole]

En admettant que tu choisisses de prendre comme base un C0 à 31,4 Hz (ce qui n'est finalement pas gênant - sauf pour les gens qui ont l'oreille absolue), ce qui est important c'est que tu aies bien des demi-tons constants avec un rapport de fréquence de 2^(1/12) (environ 1,0594631) entre une note et la note située un demi ton au-dessus (ça ferait 31,4 ; 33,27; 35,25; etc...).

Maintenant je ne sais pas si c'est possible à réaliser ou pas !

[Invité]

C'est je que je fait normalement  
De tte façon peut importe les valeurs sachant que les octaves seront les multiples de 2 donc faudra prendre une valeur de C0 et faire les décalage faire la gauche pour avoir les octaves de fréquence plus haut .

[vincent2105]

C'est toujours avec intérêt que je suis tes avancées Kannagi, merci de nous en faire profiter.
Bonne continuation

[Stef]

Exact.
Pour ma part un track comporte un event de ce type la :
delta time (debut de note) , pitch , volume , delta time(fin de notes)
Le delta times fait 1 ou 2 octet. (je regarde le bit de poids fort pour savoir si c'est sur 1 ou 2 octet)
Le pitch sur un octet comme ceci : XY
X : Octave
Y : Notes
Volume sur un octet aussi.

Plus l’entête du track (chez moi de 10 octet info sur l'utilisation du sample , et les différent effet dessus).
1 track = 1 canal.
Ensuite j'ai un fichier d'info général pour la musique (volume général , nombre de canal utilisé , temps de la musique ect).

Bonne chance pour ton driver , dit toi que le z80 est plus mangeable que le SPC700 (qui est vraiment horrible comme syntaxe).
un track fait 1ko en moyenne (donc 8ko), pour ma part ce n'est pas souhaitable que chaque canaux soit très utilisé (ça risque de poser soucis pour les sons du jeux) , le mieux est d'utiliser principalement 5 canaux et 3 autres pour des partitions de fond.
Donc ça sera peut être dans les faits un peu moins que 8ko par musique(enfin j'espere).

Ok je vois bien l'idée, ainsi effectivement tu as plus un format type MIDI ou tracker qui est efficace en terme d'espace (beaucoup plus que du VGM). J'aimerai développer un XGM v2 plus efficace à ce niveau car au final je me rend compte que même en XGM (qui est un VGM optimisé) je bouffe encore pas mal de place dans la ROM, et on peut facilement arriver à 1 voire 2 Mo de pris avec 20-30 musiques assez riches (en terme de composition et sample). C'est pas idéal...
Mon idée serait de toujours partir d'un VGM (car c'est un format générique très simple à ressortir et indépendant des trackers) mais de le compresser bien plus en tentant d'analyser les commandes pour tenter de séparer la définition des instruments et la composition en elle-même. Ainsi je pourrais en quelques sorte faire du "reverse engineering" pour retrouver la composition originale de toutes les musiques MD qui ont été dumpés au format VGM (c'est à dire à peu près toutes :p). Mais en réalité y'a des chances que ça ne soit pas vraiment réalisable...

Aussi je ne comprends pas pourquoi tu divises les canaux ainsi, 5 canaux principaux et 3 autres pour des partitions de fond ? A mon sens tu as juste la problématique de la musique et des bruitages. En gros tu alloues 6 canaux à la musique + 2 pour les bruitages, ou tu fais en dynamique : tout les canaux peuvent être utilisé pour la musique (soit 8) mais avec un gestion de priorité par canal, ainsi ceux qui ont une priorité plus basse peuvent être temporairement utilisé pour les bruitages sans que cela impacte trop la musique.

Sinon comme le disais vingazole +/-5% d'erreur dans la note c'est absolument énorme ! Je comprends mieux pourquoi on l'entend aussi nettement ! Mais j'ai l'impression qu'il y a quand même un soucis dans la manière dont la SNES produit le son car c'est quelque chose d'assez fréquent sur SNES... je pense que ça dépend de l’échantillonnage initiale de ton sample. Il faut trouver une espèce d'équilibre pour avoir une précision suffisante selon la gamme de notes que tu vas jouer et aussi bien sur l'espace que tu alloues à ton sample. Par exemple si tu as calé ton sample de base à 440 Hz avec un échantillonnage à 16 Khz mais si tu joues beaucoup plus bas (entre 50Hz et 200Hz) peut être que le réglage du pitch ne te permet pas d'être précis, idem si tu joues trop haut mais encore une fois ça m'étonne quand même. Théoriquement le SPC700 devrait te permettre de régler le pitch au moins au niveau du demi ton *parfaitement* à partir d'une fréquence de base... si ce n'est pas le cas alors à mon sens c'est la catastrophe :-/
A noter que c'est un problème que j'entends aussi sur Amiga, donc ça doit être définitivement lié à la gestion du pitch qui n'est pas assez précise.

Sur le YM2612 le réglage de la fréquence est représentée très "naturellement" :
14 bits dont 3 bits pour l'octave (soit 8 possible ce qui est standard) + 11 bits pour le réglage de la note.
Ensuite pour sortir du C0-B7 ou pour régler plus finement une note tu as un multiplicateur (x0.5, x1, x2, x3... x15) ainsi qu'un paramètre de detune (pour faire un léger détune positif ou négatif). Du coup tu es assez libre et peut théoriquement reproduire à peu près n'importe quelle note sans soucis. J'ai l'impression que sur SPC700 c'est ce n'est pas aussi facile... faudrait que je lise un peu plus les docs pour comprendre.

[Invité]

Merci vincent2105 , c'est tjs cool de savoir que ce projet est tjs suivi :)

Pour stef:
Oui je reste sur du format très proche du MIDI , d’ailleurs je change pas le nom j'apelle ça le MIDI SNES
Pour ma part si je devait partir sur un driver MD je partirait sur un truc similaire une modification d'un format midi ajusté a la console

Pour les samples je te rappel que la SNES c'est du BRR (donc un PCM 4bits) donc deja ça réduit qu'on le veuille ou non la précision du son

Je comprend mieux comme la MD gère le son du coup , sur la SNES comme je l'ai dit il y'a pas une très grande précision du pitch donc y'a pas forcément de moyen de contourner ça , après je part sur comme le dit vingazole sur un C0 tronqué du coup :)

[Stef]

Que le sample soit encodé en BRR n'est pas tant le problème ici. Le BRR "compresse" le sample et il y a de la perte par rapport à l'original mais il représente encore plus ou moins l'onde original :) et surtout il conserve sa hauteur initiale (fort heureusement) !
Je pense que le soucis, c'est vraiment cet histoire de pitch. Je viens d'aller lire la doc est en effet, on comprend assez rapidement le soucis qui peut se poser :

Code:

Pitch is a 14-bit value.
The pitch can be calculated with this formula:
Let desired DSP pitch be P.

Pitch->Hz
HZ = (32000 * P) / 2^12
HZ = P * 7.8125

Hz->Pitch:
 P = 2^12 * (HZ / 32000)
P = HZ / 7.8125

The highest pitch will reproduce the sound at approx. 2 octaves higher (~128KHz sample rate). The lowest pitch is basically not limited (but you will lose accuracy at lower pitches).

A few pitch->interval relations...

    400h     800h   1000h     2000h   3FFFh
-----|--------|-------|---------|-------|-----
   -2oct   -1oct   original   +1oct   +2oct
                         sound
                     (best quality!)

Donc effectivement si tu pitches un sample loin de sa fréquence d'origine tu perds rapidement de la précision...
Du coup dans ton cas, tu devrais partir d'une fréquence qui est à la médiane de ta compo (et au pire avoir plusieurs notes en mémoire) plutot que de partir de la fréquence minimum (C0) pour limiter les pertes.