Discussion :

[bb84000]

Bonjour,

Jipété, au niveau des bin_dist, tu pars de 0 et tu vas jusqu'au 17eme par pas de 64. Je crois que tu l'as déjà fait
bb84000

[Jipété]

Bonjour,

et merci à toi pour cette précision, que je vais étudier attentivement dès que j'aurais fini les retouches de mon writer, basé sur le petit projet qu'on a vu ce jours-ci (et pour lequel l'auteur m'a remercié de ma mise à jour 5 ans plus tard, lol lien).

Pour le writer, je vais bricoler un changement automatique des fréquences, ça sera utile je pense.


Et pour le reader du header d'un .wav, j'envisage des infobulles au survol des listbox.


À suivre !

[Jipété]

Bonjour Bernard,

je ne suis pas sûr d'avoir bien compris :

au niveau des bin_dist, tu pars de 0 et tu vas jusqu'au 17eme par pas de 64. Je crois que tu l'as déjà fait

Oui, je l'ai déjà fait et ça concernait un programme d'affichage des barres.

Mais pour correctement régler un programme, qu'est-ce que je lui donne à manger ?
Un fichier Wav qui reprend les 17 pas avec des fréquences s'échelonnant régulièrement de 20 à 20000 Hz, c'est-à-dire 20000 / 16 = 1250, alors je pars de 20 et j'ajoute 1250 16 fois et fait à la main, ça donne 20, 1270, 2520, 3770...20020,
ou bien je conserve les 17 valeurs (j'en ai rajouté une au début, à 30 Hz) de l'array "FREQUENCIES" du prog, qui s'arrête à 16000 Hz ?

Je ne me suis pas encore préoccupé d'enregistrer les positions des barres, je verrai ça plus tard. Déjà, j'ai juste besoin d'une confirmation que je suis dans la bonne direction : à l'oreille (c'est pas bien de vieillir...), le premier essai me permet de n'entendre que les fréquences 1, 2 et 3 (à 5000 Hz, entre l'âge et les petits hp's cacaboudin de l'écran, faut pas s'attendre à des miracles) en commençant à 0, et le second essai chante plus élégamment les fréquences 1 à 9 (4000 Hz, la suivante à 6000 je peux oublier) mais l'échelonnement n'est pas du tout le même.

Que faire ? Où se cache la Vérité ?

Au plaisir de vous lire...
(absent en début d'aprème),

[bb84000]

Bonjour,

Mais pour correctement régler un programme, qu'est-ce que je lui donne à manger ?

Un bruit blanc. Toutes tes barres doivent avoir la même hauteur.

Tu peux en télécharger LA.

Pour un générateur, jette un œil ICI c'est sans garantie..

bb84000

[Jipété]

Bonsoir,

et grand merci pour ton lien, qui m'a fait découvrir quelqu'un de passionnant (un de plus !).
Son site est plein de trésors, ça va prendre des mois pour en faire le tour, dis donc !

En attendant, j'ai commencé avec le bruit blanc à la distribution gaussienne et ça donne ça, d'abord avec le logiciel Audacious sur lequel je n'ai aucune possibilité de réglage (à part télécharger les sources et les analyser), et ensuite avec mon outil en cours d'étude et de construction :

(note : le fichier a été ouvert d'abord avec Audacity pour voir à quoi il ressemblait et j'y ai trouvé plein de traits rouges, signe de saturation, du coup j'ai baissé le niveau de 0.1 dB et plus de saturation, d'où l'enregistrement d'un autre fichier-jp, )

On constate que peu ou prou les sorties se ressemblent beaucoup, et chez moi, les bin_dist vont de 0 à 1024 avec cette progression que j'ai inventée, j'en ai déjà parlé, je la redonne :
valeur = (index*2)² avec index = [0..16]

À titre de comparaison, j'ai remis les 17 valeurs d'origine et ça donne ça :

Ensuite j'ai téléchargé l'autre fichier, celui à la distribution uniforme et voilà le résultat :

Je ne vois pas de différences flagrantes, on n'est pas rendus, quoi...

Quant au générateur de bruit à base de BASS (ton second lien), elle est curieuse cette discussion, ce monologue devrais-je dire, enfin, je verrai ça...

Merci à toi de ne pas lâcher l'affaire, on y est presque, faut juste se cramponner encore un peu,

[Jipété]

Un bruit blanc. Toutes tes barres doivent avoir la même hauteur.

J'ai regardé les deux projets de ton second lien : ils fonctionnent, après les avoir adaptés à Linux. Un zip avec les codes des deux forms avec mes corrections : noise.zip

Et donc le projet pinknoise permettant de régler le niveau, voilà 3 images :


Le projet noisetest n'a pas ce réglage et doit avoir des différences avec le précédent car les barres ne sont pas les mêmes : va falloir creuser cette question.


Et il y a donc deux afficheurs de barres puisque j'utilise maintenant deux versions (mais je ne sais plus lequel est l'original et lequel est à mon initiative -- pas grave)

Alors ce qui est curieux, c'est que les niveaux générés par ces deux petits progs faits de bric et de broc ont l'air de générer un niveau plus stable que les fichiers de fin d'après-midi, à creuser aussi mais comme je ne sais pas comment les premiers fichiers ont été générés, ben...

[Jipété]

Bonjour,

en attendant de pouvoir progresser, je vais faire avancer des points de détails peut-être pas si anodins que ça, comme par exemple le fait d'avoir l'afficheur des barres plein de barres et avec le processeur qui monte dans les tours quand je demande au timer un intervalle de 1000 mSec pour l'affichage, alors que tout est calme quand c'est réglé sur 40 et qu'il bosse donc 25 fois plus.

On dirait que le timer fonctionne à l'envers ou je ne sais trop quoi...

Par ailleurs, si je fais jouer une fréquence pure de 440 Hz avec la formule magique

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
onde(t) := A.sin((2*Pi*F*t)+p)
avec 
A : amplitude (= volume) de l''onde
F : la fréquence en Hz
p : la phase (compris entre 0 et Pi), induit un décalage vers la droite

soit en ce qui me concerne,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  Volume := 32000; Frequence := 440; Phase := 0; 
  For t := 0 To 127 do
    data[t] := round( Volume*32 * sin((6.283185 * Frequence * t) + Phase) );

j'obtiens ce résultat avec mes deux petits viewers :


Je m'attendais à une seule barre ou 2 ou au pire 3 mais autant que ça, ça me semble bien farfelu...
D'autant plus que là, vous voyez des images fixes alors qu'irl les barres bagottent de 2-3-4 traits environ.
Très curieux.
Une idée de ce comportement ?

Quant au volume, il parait qu'il doit se tenir entre -32768 et +32767 et là on est à 1024000 pour bien entendre quelque chose...

[bb84000]

Bonjour,

Il serait peut-être nécessaire de réinitialiser le buffer à zéro avant de refaire un échantillonnage pour éviter tout résidu antérieur si l'échantillonnage n'est pas complet Et/ou vérifier le nombre de bits reçus pour ne pas interpréter des échantillons qui n'existent pas.

Si tout ceci est OK, alors il y a un souci au niveau du générateur (ou du traitement de son code par le compilateur). La encore, comme on a une boucle, il faut être certain que le raccordement entre deux périodes ou groupes de périodes se fait bien au zéro et sans délai. Si on a le moindre décalage, (dans le temps ou dans l'amplitude) on n'a plus un vrai signal sinusoïdal, donc le spectre n'est plus une raie verticale.

Tout ça si j'ai bien compris.

bb84000

[Jipété]

Coucou,

... pour ne pas interpréter des échantillons qui n'existent pas.

... on n'a plus un vrai signal sinusoïdal, donc le spectre n'est plus une raie verticale.

Remarques très intéressantes, je ne sais pas encore par quel bout les prendre, mais je vais me pencher dessus.
(je sens qu'il va encore y avoir plus de codes de contrôle que de vrai code fonctionnel, )

[Jipété]

Bonjour,

j'ai examiné de près un fichier stéréo de 2 secondes à une fréquence de 440 Hz et un SampleRate à 44100, et en zoomant très fort avec Audacity, voilà un montage de la première demi-période suivie de la dernière demi-période, c'est juste pour montrer ce qu'on va regarder en détail ensuite :


Les détails que je zoome à mort, c'est le tout début (où j'ai enlevé le dernier point de la première partie), le milieu et la toute fin de l'image précédente, en éliminant les vides pour que ça rentre dans le navigateur pour affichage :


De gauche à droite l'échelle en bleu ciel puis le début et la fin de la première demi-période puis une bande verte de séparation puis le début et la fin de la dernière demi-période, et force est de constater un décalage entre les valeurs des canaux gauche et droite.
Et ce qu'on peut noter, c'est que le canal gauche est plus fort que le canal droit en montée et que c'est l'inverse en descente, on a donc des canaux asymétriques, ce qui m'en bouche un coin car ils sont construits à partir de la même formule !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
function MakeSine(handle: HSTREAM; buffer: Pointer; length: DWORD; user: Pointer): DWORD; cdecl;
var
  buf: ^word;
  i, len_moins_un: Integer;
begin
  buf := buffer;
  len_moins_un := (length div 2) - 1;
  for i := 0 to len_moins_un do begin
    sinepos := sinepos + (tone / SAMPLERATE);
  //buf^ := Trunc(Sin(sinepos * PI) * Amplitude); // pourquoi un trunc ?
    buf^ := Round(Sin(sinepos * PI) * Amplitude); // un round c'est moins violent, non ?
    inc(buf);
  end;
  Result := length;
end;

Pour Windows, remplacer cdecl par stdcall.

Par ailleurs, j'ai pu également constater des différences de hauteur dans les sommets des périodes, ce qui me chagrine car c'est probablement tout ça qui serait à l'origine des instabilités dans l'analyseur de spectre, non ?

Si oui, la question qui tue c'est : comment y remédier ?
Peut-être en utilisant des float au lieu des integer, mais j'avoue que je ne sais pas trop comment m'y prendre : j'ai bien tenté de faire ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
//SineStream  := BASS_StreamCreate(SAMPLERATE, 2, 0, @MakeSine, nil);
  SineStream  := BASS_StreamCreate(SAMPLERATE, 2, BASS_SAMPLE_FLOAT, @MakeSine, nil);

mais ça me donne un son minable, comme s'il y en avait deux en même temps,

Je me doute bien qu'il va falloir aller trifouiller dans MakeSine mais je patauge un peu...
S'il y a des idées qui fusent, elles sont welcome.

[Guesset]

Bonjour,

Sur les zooms partiels montrés on peut soit en conclure une différence de niveau soit une différence de phase (un demi T_ech par exemple) ?

Salutations

[Jipété]

Merci de participer, mais je n'ai pas compris ce que tu voulais montrer avec tes points rouges rajoutés.

on peut soit en conclure une différence de niveau soit une différence de phase (un demi T_ech par exemple) ?

Une différence qui viendrait d'où ?

Comme son nom l'indique, voilà qui fait le boulot :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
function MakeSine(handle: HSTREAM; buffer: Pointer; length: DWORD; user: Pointer): DWORD; {$IFDEF MSWINDOWS}stdcall;{$ELSE}cdecl;{$ENDIF}
var
  buf: ^word;
  i, len_moins_un: Integer;
begin
  buf := buffer;
  len_moins_un := (length div 2) - 1;
  for i := 0 to len_moins_un do begin
    sinepos := sinepos + (tone / SAMPLERATE);
  //buf^ := Trunc(Sin(sinepos * PI) * Amplitude);
    buf^ := Round(Sin(sinepos * PI) * Amplitude); 
    inc(buf);
  end;
  Result := length;
end;

Ensuite, c'est BASS qui fait sa cuisine (sur laquelle je n'ai aucun pouvoir), je lui demande 2 canaux, il s'en débrouille, tout comme pour l'amplitude (le niveau sonore), réglé par un Trackbar et qui ne bouge pas pendant l'enregistrement.

Mais c'est peut-être moi qui me suis mal exprimé ?

Nouvelle image :


à gauche avec + ou - le niveau de zoom de mon post précédent,
à droite les mêmes 8 premiers points mais zoomés à mort dans Audacity et pas dans un traitement d'images, ce sont donc les données présentées graphiquement par Audacity et rien d'autre.
Et s'il y avait ou devait y avoir des choses entre les points, on devrait les voir, non ?
Quand je sélectionne tout et que je demande à Audacity "Début et durée de la sélection" en "échantillons", il me répond gentiment 102, ce qui correspond à ce que j'ai compté sur mes doigts.

Par contre, en regardant les images sur lesquelles je travaillais pour préparer ma réponse, je me suis rendu compte de petites différences, qui me chagrinent :
Voici la première période complète de toujours le même fichier :


Si je coupe la partie droite, que je la colle comme nouveau calque, que j'applique un effet de miroir horizontal à ce nouveau calque puis un miroir vertical et qu'ensuite je le déplace sur la partie gauche de l'image puis qu'enfin je le décale légèrement de quelques pixels vers la droite et vers le bas, on peut comparer les contenus du début et de la fin de la même période et là on se dit qu'il y a un souci, enfin, moi je me dis ça.


Les deux carrés au bout à gauche montrent les décalages, ils sont infimes par rapport aux décalages des points représentant les valeurs.

Voili voilà...

EDIT :
Allez, pour le fun, j'ai repris le calque de la seconde demi-période et l'ai remis à l'endroit par un coup de miroir horizontal puis l'ai déplacé tip-top sur le première demi-période + coloration en rouge et voici ce que ça donne :


Normalement, ça devrait être superposé au poil près, et ce n'est pas le cas...

[bb84000]

Bonjour,

je pense que la précision temporelle des différents traitements, avec ou sans BASS n'est pas suffisante pour obtenir des résultats parfaits, d'autant que par principe, la numérisation ne peut pas représenter exactement le signal d'origine. Là tu échantillonnes un signal qui n'est pas une vraie sinusoïde, mais une suite de pics dont l'enveloppe est une quasi sinusoïde.

bb84000

[Jipété]

Yep !

je pense que la précision temporelle des différents traitements, avec ou sans BASS n'est pas suffisante pour obtenir des résultats parfaits, d'autant que par principe, la numérisation ne peut pas représenter exactement le signal d'origine. Là tu échantillonnes un signal qui n'est pas une vraie sinusoïde, mais une suite de pics dont l'enveloppe est une quasi sinusoïde.

D'accord, mais je m'attendais à avoir les deux canaux strictement identiques puisqu'ils sont issus d'une seule source, même si pas parfaite.
Ou alors c'est Audacity qui a du mal avec ses deux panneaux qui, si ça se trouve, ont des hauteurs différentes selon la hauteur globale de l'affichage, et au premier coup d'œil, ça ne se voit pas.

On en reparlera, pour le moment, je suis en train de voir comment travailler avec des float plutôt que des integer, et c'est pas simple...

[Guesset]

Bonjour Jipété,

Merci de participer, mais je n'ai pas compris ce que tu voulais montrer avec tes points rouges rajoutés.

Les points rouges sont seulement ceux de la courbe inférieure (autre canal ?) décalés d'une demi période d'échantillonnage. Le changement de couleur vise juste à les distinguer. Cela tend à laisser penser à un déphasage plutôt qu'à un problème d'amplitude.

Une différence qui viendrait d'où ?

Comme son nom l'indique, voilà qui fait le boulot :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
function MakeSine(handle: HSTREAM; buffer: Pointer; length: DWORD; user: Pointer): DWORD; {$IFDEF MSWINDOWS}stdcall;{$ELSE}cdecl;{$ENDIF}
var
  buf: ^word;
  i, len_moins_un: Integer;
begin
  buf := buffer;
  len_moins_un := (length div 2) - 1;
  for i := 0 to len_moins_un do begin
    sinepos := sinepos + (tone / SAMPLERATE);
  //buf^ := Trunc(Sin(sinepos * PI) * Amplitude);
    buf^ := Round(Sin(sinepos * PI) * Amplitude); 
    inc(buf);
  end;
  Result := length;
end;

Comment on s'assure que sinepos (variable globale unique ?) est un bon référent de phase pour les deux courbes ? Ce ne sera le cas que si (length div 2)*tone/SampleRate = 2*k*PI.
Sauf, ce qui est très possible, si je n'ai pas réellement compris le problème .

Dans les trucs que je ne comprends pas :

• A quoi sert de retourner l'argument Length qui n'est pas modifié ?
• Le handle : HStream nest pas utilisé, idem user.
• Pourquoi déclarer buf comme un pointeur sur word (entier non signé) pour y mettre des valeurs signées ?
• Il faut supposer que Amplitude < 255.5 ?

Salutations

[Jipété]

Dans les trucs que je ne comprends pas :

• A quoi sert de retourner l'argument Length qui n'est pas modifié ?
• Le handle : HStream n'est pas utilisé
• Pourquoi déclarer le buf comme un pointeur sur word (entier non signé) pour y mettre des valeurs signées ?
• Il faut supposer que Amplitude < 255.5 ?

Salutations

Tout cela est un brouillard infernal que personne ne comprend ni ne maîtrise et qui ne s'éclaircit qu'à grands d'essais et d'échecs.
Je n'ai pas trouvé mieux à ce jour, et si quelqu'un pouvait nous expliquer, j'en serais bien heureux...

C'est tout pour aujourd'hui.

[Guesset]

Bonjour,

En voyant ce sujet, j'avais téléchargé le code mais après l'avoir regardé je l'ai soigneusement effacé en me disant que le travail de reprise dépassait très largement ma motivation.

Je souhaite chance et persévérance à ceux qui s'y collent.

Salutations

[bb84000]

Bonjour Jipété,

Étant donné que BASS travaille avec un flux de données numériques, les erreurs qu'il peut introduire sont au niveau du calculs. Il est bien indiqué que pour réduire ces erreurs, il est conseillé d'utiliser des "Float" dans toute la chaîne pour travailler sur 32 bits, même si les données sont en 16 bits, pour éviter les erreurs de saturation (clipping) lors du traitement.
Mais même dans ce cas il reste des possibilités d'erreur parce le calcul n'est pas instantané.
Idem pour Audacity.

C'est la même chose pour le générateur. le calcul n'est pas instantané.

De toutes façons, Windows et Linux ne sont pas des OS temps réel, pas plus que Delphi ou FPC. Pour limiter au maximum les erreurs temporelles dans le cas présent, il faut aller voir du côté des options d'optimisation du compilateur et essayer celle où les erreurs sont minimum.

Si ça t'intéresse, j'ai trouvé (mais non essayé) CA.


bb84000

[Jipété]

Bonjour Bernard,

il est conseillé d'utiliser des "Float" dans toute la chaîne pour travailler sur 32 bits,

C'est ce que je m'évertue à essayer de mettre en place, j'y suis presque mais c'est très compliqué, sans informations précises. Je continue à écumer internet...

Donc, les options d'optimisation, ça sera quand j'aurai un système "float" fonctionnel.

Si ça t'intéresse, j'ai trouvé (mais non essayé) CA.

À une époque lointaine, ça m'aurait intéressé, mais maintenant, je ne suis pas sûr du tout que ça tourne sous Linux,

Allez, je retourne à ma quête.
Bonne journée,

[Jipété]

Bonjour,

Désolé pour le silence radio,, je patauge...
Voilà des nouvelles, et elles ne sont pas brillantes ; je vais essayer de résumer car j'ai besoin d'un peu d'aide pour surnager.

J'ai trouvé dans l'aide de Bass la chose suivante (les 4 premières instructions viennent de BASS_SampleCreate, les 2 dernières de BASS_SampleGetChannel):

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
  // create the sample             // 28160 = 440 x 64
  int sample = BASS_SampleCreate(256, 28160, 1, 1, BASS_SAMPLE_LOOP | BASS_SAMPLE_OVER_POS );
  // the data buffer (256 byte = 128 Int16)
  short[] data = new short[128];
  // create the sine wave
  for (int a=0; a<128; a++)
    data[a] = (short)(32767.0 * Math.Sin((double)a * 6.283185 / 64));
  // set the sample's data
  BASS_SampleSetData(sample, data);
  // get a sample channel
  int channel = BASS_SampleGetChannel(sample, 0);
  // play it
  BASS_ChannelPlay(channel, false);

que j'ai traduite en Pascal/Lazarus ainsi (sur une form j'ai un btnTest) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
procedure TForm1.btnTestClick(Sender: TObject);
const
  SAMPLERATE = 44100;
var
  sample: HSAMPLE;
  data: array[0..127] of short;
  a: integer;
  chan: HCHANNEL;
begin
  //            longueur en bytes          numch numpb  résolution 16bits si ni 8BITS ni FLOAT
  sample := BASS_SampleCreate(256, SAMPLERATE, 1, 1, BASS_SAMPLE_LOOP or BASS_SAMPLE_OVER_POS);
  for a := 0 to 127 do 
    data[a] := Round( 32767.0 * Sin( a * 6.283185 / 64) );
  chan := BASS_SampleGetChannel(sample, 0);
  BASS_ChannelPlay(chan, false);
end;

et ça fonctionne.
Première constatation, soufflée par le compilo, la boucle for ne sert à rien donc je la vire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
begin
  //            longueur en bytes          numch numpb  résolution 16bits si ni 8BITS ni FLOAT
  sample := BASS_SampleCreate(256, SAMPLERATE, 1, 1, BASS_SAMPLE_LOOP or BASS_SAMPLE_OVER_POS);
  chan := BASS_SampleGetChannel(sample, 0);
  BASS_ChannelPlay(chan, false);
end;

et ça fonctionne toujours.

Mais comme ce n'est pas confortable de fermer le prog et le réouvrir, très vite je fais en sorte que mon bouton serve à démarrer/arrêter/démarrer/etc. et ça devient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
begin
  if btnTest.Caption = '4test' then begin
    //            longueur en bytes          numch numpb  résolution 16bits si ni 8BITS ni FLOAT
    sample := BASS_SampleCreate(256, SAMPLERATE, 1, 1, BASS_SAMPLE_LOOP or BASS_SAMPLE_OVER_POS);
    chan := BASS_SampleGetChannel(sample, 0);
    BASS_ChannelPlay(chan, false);
    btnTest.Caption := 'stop';
  end else begin
    BASS_ChannelStop(chan); // n'arrête pas le son !?
    BASS_SampleFree(chan); // n'arrête toujours pas le son !!!???
    BASS_Free; // nécessaire, donc, et le restart aussi, du coup
    Sleep(10);
    // restart BASS with the default device
    if NOT BASS_Init(-1, SAMPLERATE, 0, nil, nil) then 
    begin
      MessageBox(0,'Could not initialize BASS','0',MB_ICONERROR);
      exit;
    end;
    btnTest.Caption := '4test';
  end;
end;

Ça fonctionne, donc dans les posts suivants j'omettrai la partie end else begin ... end; histoire d'aller à l'essentiel, comme par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
begin
  if btnTest.Caption = '4test' then begin
  //              longueur en bytes          numch numpb  résolution 16bits si ni 8BITS ni FLOAT
  //sample := BASS_SampleCreate(256, SAMPLERATE, 1, 1, BASS_SAMPLE_LOOP or BASS_SAMPLE_OVER_POS);
    // dessus la fréq varie au start-stop-start, d'où dessous qui est mieux, mais pourquoi ??????????
    // EDIT : j'ai recompilé après tous ces essais et maintenant le comportement c'est l'inverse : son bon dessus mauvais dessous
    // Lazarus aura ma peau et ma santé mentale, je sens... /EDIT
    sample := BASS_SampleCreate(256, SAMPLERATE, 1, 1, BASS_SAMPLE_LOOP);
  // et pour éviter de trop alourdir, ces 3 lignes suivantes seront désormais zappées des posts
    chan := BASS_SampleGetChannel(sample, 0);
    BASS_ChannelPlay(chan, false);
    btnTest.Caption := 'stop';

Et je continue mes tests en jouant avec les flags, comme par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
begin
  if btnTest.Caption = '4test' then begin
    //            longueur en bytes          numch numpb  résolution 16bits si ni 8BITS ni FLOAT
//  sample := BASS_SampleCreate(256, SAMPLERATE, 1, 1, BASS_SAMPLE_8BITS);// --> juste 1 top
    sample := BASS_SampleCreate(256, SAMPLERATE, 1, 1, BASS_SAMPLE_8BITS or BASS_SAMPLE_LOOP);// -->
    // il y a une première fréquence bizarre puis un stop/start en fait entendre une plus propre

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
begin
  if btnTest.Caption = '4test' then begin
    //            longueur en bytes          numch numpb  résolution 16bits si ni 8BITS ni FLOAT
//  sample := BASS_SampleCreate(256, SAMPLERATE, 1, 1, BASS_SAMPLE_FLOAT);// --> silence
    sample := BASS_SampleCreate(256, SAMPLERATE, 1, 1, BASS_SAMPLE_FLOAT or BASS_SAMPLE_LOOP);// --> silence

et là je ne sais plus quoi faire.
Comment dire à ces quelques lignes que je veux entendre un son Float, dont la valeur va osciller entre 0 et 1, contrairement au 8BITS (-128..127) ou au 16BITS (-32768..32767) ?

il est conseillé d'utiliser des "Float" dans toute la chaîne pour travailler sur 32 bits

J'ai donc essayé de suivre ton conseil (d'autant plus que je suis d'accord avec toi), mais je ne vois pas trop comment les choses s'articulent, dans la mesure où les data en integer sont directement entendues mais pas celles en float.
Qu'est-ce que je rate (indépendamment des petites remarques où je parle des fréquences qui varient) ?
Merci du coup de main,