Re: GUERRE ST-AMIGA, FIGHT !!!

[dlfrsilver]

Je ne vois pas comment, le son du ST grésille beaucoup trop y compris en terme de samples pour que ça soit utilisé dans de la musique commerciale. 

Que le ST ait été utilisé pour piloter du synthé sur ce morceau je veux bien, mais les samples, pitié, pas ça et pas à moi (ni aux autres).

Si si. le ST a été utiliser pour la voix. ça s'entend très bien d'ailleurs...

Tristesse :/ Vive la musique commerciale à pas cher.....

[rocky007]

@Stapha92

Au sujet de votre discussion concernant Paula et les DAC. Le fait que Paula prend 0% du processeur pour jouer une musique ne plaide t il pas tout simplement en sa faveur pour dire que c'est plus qu'une DAC ? Si j'ai bien compris une DAC ne peut pas faire ça ?

le DAC se contente juste de convertir un signal digital en analogique, point barre.  
du reste si je comprends bien, si Paula prend 0% du CPU, c'est uniquement grâce à l'agnus et non Paula.

[babsimov]

@Stapha92

Au sujet de votre discussion concernant Paula et les DAC. Le fait que Paula prend 0% du processeur pour jouer une musique ne plaide t il pas tout simplement en sa faveur pour dire que c'est plus qu'une DAC ? Si j'ai bien compris une DAC ne peut pas faire ça ?

Autre question, la Gravis Ultrasound faisait donc comme Paula, 0% du processeur pour jouer une musique. Ce qui était une exception sur PC à l'époque, si je comprends bien.

Mais, de nos jours, les composants sonores intégrés aux cartes mères des PC font ils comme Paula/Gravis Ultrasound, c'est à dire 0 % du processeur pour jouer une musique (je suppose évidemment que oui), mais n'étant pas technicien je préfères une confirmation (désolé si la question parait idiote).

Bien sur : Paula c'est bien plus que les 4 DAC qu'elle contient...
Non : un DAC c'est juste la transformation d'un signal numérique en signal analogique. La gestion des tonalités est faite par Paula mais en dehors des DAC. Y a qu'à voir le STE : la partie sample ne s'appuie pas que sur 2 DAC, pas du tout (il faut lire les samples, les stocker, gérer une horloge, etc...) et pourtant il ne peut pas faire tout ce que fait Paula.

Merci, c'est bien ce que j'avais déduis.

Par contre, qu'en est il pour les PC actuels ? Y a t il aussi 0 % du processeur pour le son ?

@Stapha92

Au sujet de votre discussion concernant Paula et les DAC. Le fait que Paula prend 0% du processeur pour jouer une musique ne plaide t il pas tout simplement en sa faveur pour dire que c'est plus qu'une DAC ? Si j'ai bien compris une DAC ne peut pas faire ça ?

le DAC se contente juste de convertir un signal digital en analogique, point barre.   
du reste si je comprends bien, si Paula prend 0% du CPU, c'est uniquement grâce à l'agnus et non Paula.

Peut être ais je mal compris, mais Agnus envoi l'information à Paula et après il ne s'occupe de plus rien.

Si Stapha92 pouvait détailler le cheminement d'un sample dans l'Amiga, de la mémoire jusqu'à l'enceinte, je pense que ce serait une lecture intéressante. Le connaissant, il saura rendre cela aussi didactique que possible pour un néophite.

Peut être que de ton côté tu pourrais faire la même chose, si tu le sais, pour le STE (le ST n'ayant pouvant pas faire de sample en natif) ? A moins que Stapha92 puisse aussi faire la comparaison entre Paula et le STE pour ce cheminement.

Merci à chacun de vous si vous trouvez un peu de temps pour ce point là.

[rocky007]

Si ton byte fait 129 avec un volume de 50 %, mesure ta sortie et tu auras bien l'équivalent de 64,5. Fait une conversion sofware et tu auras 64. Donc la même chose qu'avec un byte de 128. En fait tu as perdu 1 bit de résolution (tu n'as que 128 résultats possibles après la division par 2 en sofware. 128 valeurs = 7 bits). Pire : utilise un volume de 25% et là c'est 64 résultats différents que tu obtiendras : 6 bits...je n'avais pas pensé

c'est vrai.  129 = 2,5119 V, donc 25% dessus, cela donne 0,6298 V, soit 7 bits au lieu de 6.
( 0,625 V si c'était en digital, même si la différence de 0,0048 V est quand même minime, mais je te l'accorde, ça manque de précision )

ok alors pourquoi tous les tutos ou forum qui parle d'attaquer le GEM avec le GFA utilisent d'autres fonctions que celles que tu as utilisées ? Il y a une différence entre afficher une fenêtre GEM et utiliser le GEM pour afficher une fenêtre...
Je ne dis pas que tu as tort, mais je trouve ça étrange. Je voudrais bien comprendre.

je suppose qu'ils ont implanté des fonctions pour rapide pour des usages simples de fenêtres et éviter toutes les déclarations, test de réso etc.. nécessaires.  Du reste, la fenêtre ouverte par OPENW peut être gérée par les autres commandes WIND.  Ils ont proposé à l'utilisateur les deux options : soit avoir un controle précis et complet sur la fenêtre via la librairie WIND, soit simplifier la tâche du codeur avec OPENW.

ça ne prouve rien. Pas besoin de trafiquer la vidéo. Tu crois qu'il n'y a qu'un seul réglage dans STEEM ?
N'importe qui peut essayer ici. J'attend que quelqu'un le fasse

ben pour passer de 25 sec à 81 comme toi, je vois pas trop le réglage que j'aurais pu faire.  il y a une option "mauvaise foi" à cocher dans Steem ?

Oui c'est ça. Sauf que tu as prouvé que tu n'utilisais pas un mig pour des applications (voire des jeux) sinon tu aurais su qu'on ne met pas la disquette wb pour lancer une appli comme le gfa...

Je note que pleins d'applications sur ST obligent à ce que le GEM soit dans la réso dont elles ont besoin
 alors qu'il n'y en a que 2. Sur le mig la résolution d'une appli est totalement indépendante de celle du workbench, que ce soit une appli qui ouvre son écran ou qui utilise celui du workbench comme écran public...

bien sûr on peut optimiser bcp de choses sur amiga, je le sais.  Mais est-ce le cas que Monsieur père de famille qui a acheté son amiga et qui veut taper son texte ?  même de nos jours, qui sait vraiment exploiter  windows correctement et optimiser le boot ?    par grand monde je pense ..

pour la reso ST, c'est pourtant simple : tu as ta disquette GFA, tu la démarre et tu tombes sur le bureau directement à la bonne résolution, tu cliques et c'est parti.

Ai-je dit le contraire ? Ben non puisque c'est un défaut de votre OS . ça n'a pas été corrigé au bout de 4 ans en "installant" une application ? Tant d'années avant de pouvoir démarrer un programme GEM automatiquement...

il y a surement des logiciels à glisser dans l'auto qui permettent de le faire, perso j'en ai jamais utilisé.  c'est bcp de fumée encore de ta part , je ne vois pas le problème d'attendre 1 seconde pour être dans le bureau.
( contrairement à l'amiga ! ).

Et comment tu déplaçais un fichier pendant les 4 premières années ? Et comment tu renommais un répertoire ? Super la puissance et la convivialité..

ah oui c'est vrai que l'amiga et son CLI pour compenser les manquements du WB, c'est très convivial

.
Bizarre qu'un utilisateur Amiga, soit disant un utilisateur de console à disquettes d'après vous l'ait vu et que les utilisateurs ST, soi disant utilisateurs d'ordinateur sérieux ne l'aient pas vu...

je ne vois pas le rapport : tu as essayé Quantum paint ( ou autre ) et moi pas, bravo.  on est obligé d'essayer tous les softs du ST quand on est un utilisateur sérieux ?

Oui il converti un signal. Mais est-il sensible au fluctuations qu'il peut y avoir sur le signal ? OUI !

ben voilà, il converti.  le fait qu'il soit moins performant et plus rudimentaire ne change rien, il a bien converti, c'est donc bien un DAC.  un DAC n'implique pas forcément un précision absolue.
c'est comme si tu disais que l'alimentation de ton amiga n'est pas un vraie alimentation, parce qu'elle n'est de précision.

Il l'alimente mais pas en continu : Paula stocke ses samples 2 par 2 (les 16 bits en entrées c'est pour un seul canal à la foix). Pas besoin qu'on l'alimente en continu. Parce que, justement, Paula c'est pas un DAC à 90%

ah bon ? il y a un buffer dans Paula qui stocke un sample entier ? 

Tu ne m'as pas compris. Je parlais dans l'hypothèse ou on utiliserait un reseau de résistance dans Paula (hypothèse que tu as formulée). Dans ce cas uniquement, Paula serait sensible aux fluctuations du signal qui serait envoyé par Agnus. Mais ce n'est pas le cas car elle possède des VRAIS DAC.
Et ils utilisent une alimentation qui est régulée rien que pour eux...

c'est toi qui ne m'a pas compris : je parlais de remplacer Paula par un réseau de résistance.  Agnus pourrait envoyer les bits nécessaires et sortir un son par le R2R.  Agnus devrait bien évidement être adapté pour envoyer les bons paquets.   et cette exemple n'a été donné que pour te dire le port // n'avait pas plus d'intérêt que Agnus dans un système avec R2R.

Pas besoin de fluctuation de 0,3V (ai-je seulement donné ce nombre comme exemple ?...) : rien que 0,1V donne 3% de distortion, ce qui est énorme...

oui , tu as cité des différences entre 3,3V et 3,6V.   et même 0,1V, je doute que cela autant et cela n'est uniquement en fonction de l'alimentation.  c'est pourquoi, un PC qui avec alim bas de gamme donnera peut être un son différent d'un PC avec une alim de meilleure qualité

.
Il fournit les bits sur le bus ? Non : il fourni le signal qui sera utilisé directement (après conversion) pour la sortie. Ou bien j'ai mal vu ton schéma et j'ai raté l'alimentation de ton "DAC" ? Ah ben non...

ben si justement, il fournit les bits sur le bus du R2R

Tu sais qu'il y a beaucoup d'utilisateurs ST qui trouvent que le GEM rame ? Toi même tu as rappelé que des tas de patch avaient été écrit pour améliorer la situation. Et tu pense qu'un GEM peut aller aussi vite que le GFA. Pourtant le GFA a, au contraire, la réputation d'être rapide

les patchs ne sont pas là pour corriger la vitesse mais les limitations ( nombre de fenêtres, etc..).
et oui, sur ma video on voit clairement que les PRINT sous GEM sous aussi rapide qu'en direct

Ah bon ? Tu expliques que le blanc c'est 000000000000000000000001 en 24 bits et c'est moi qui a fait le malin ?

tu continues ?  incroyable... je t'explique à nouveau : 1 bit converti en 24 = ridicule.

Le plus drole : tout ça pour nous démontrer qu'en bureautique le 24 bits ne sert à rien. Ben voyons...

non pour démontrer qu'avoir 24 bits pour travailler en tramé monochrome n'apportait rien... du reste, on t'entend plus sur la question des trames, ça y est la pièce est tombé, tu as enfin compris qu'un pro édite ses trames lui même ?

Tu peux changer l'adresse écran sur le GFA non ? Donc tu peux faire l'effet en 50 i/s. ça prendra 2 fois plus de mémoire c'est tout.

oui mais là il n'y a plus aucun intérêt, ça devient un slide show

Dommage que tu ne l'ai plus.
Ok je vois. Les frames sont décalées de la même valeurs ? J'aurai cru que le parcours des frames du bas se ferait à l'inverse de celles du haut, pour que ça tourne dans le meme sens malgré l'inversion.

c'est ce que je pensais aussi au départ, mais il s'avère que  non, j'ai dû ajouter des raccourcis clavier pour déterminer le bon décalage entre la frame du haut et celle bas.

j'ai retrouvé le source.  tu m'excuseras d'avoir fait cela très salement ( pas de malloc ).   il y a 16 frames, et il faut un décalage de 10 entre les deux pour que cela soit correcte

Code:

mem%=320000
BLOAD "c:\tube\tx0_on.pi1",mem%-34
VOID XBIOS(6,L:mem%-32)
FOR i=0 TO 16
  BLOAD "c:\tube\tx"+STR$(i)+"_on.pi1",mem%
  BMOVE mem%+34+16000,mem%,16000
  mem%=mem%+16000
NEXT i
t%=576000
scr%=XBIOS(2)
DO
  FOR i=320000 TO 576000 STEP 16000
    BMOVE i,XBIOS(2)+16000,16000
    BMOVE t%+15840,scr%+0,160
    BMOVE t%+15680,scr%+160,160
    BMOVE t%+15520,scr%+320,160
    BMOVE t%+15360,scr%+480,160
    BMOVE t%+15200,scr%+640,160
    BMOVE t%+15040,scr%+800,160
    BMOVE t%+14880,scr%+960,160
    BMOVE t%+14720,scr%+1120,160
    BMOVE t%+14560,scr%+1280,160
    BMOVE t%+14400,scr%+1440,160
    BMOVE t%+14240,scr%+1600,160
    BMOVE t%+14080,scr%+1760,160
    BMOVE t%+13920,scr%+1920,160
    BMOVE t%+13760,scr%+2080,160
    BMOVE t%+13600,scr%+2240,160
    BMOVE t%+13440,scr%+2400,160
    BMOVE t%+13280,scr%+2560,160
    BMOVE t%+13120,scr%+2720,160
    BMOVE t%+12960,scr%+2880,160
    BMOVE t%+12800,scr%+3040,160
    BMOVE t%+12640,scr%+3200,160
    BMOVE t%+12480,scr%+3360,160
    BMOVE t%+12320,scr%+3520,160
    BMOVE t%+12160,scr%+3680,160
    BMOVE t%+12000,scr%+3840,160
    BMOVE t%+11840,scr%+4000,160
    BMOVE t%+11680,scr%+4160,160
    BMOVE t%+11520,scr%+4320,160
    BMOVE t%+11360,scr%+4480,160
    BMOVE t%+11200,scr%+4640,160
    BMOVE t%+11040,scr%+4800,160
    BMOVE t%+10880,scr%+4960,160
    BMOVE t%+10720,scr%+5120,160
    BMOVE t%+10560,scr%+5280,160
    BMOVE t%+10400,scr%+5440,160
    BMOVE t%+10240,scr%+5600,160
    BMOVE t%+10080,scr%+5760,160
    BMOVE t%+9920,scr%+5920,160
    BMOVE t%+9760,scr%+6080,160
    BMOVE t%+9600,scr%+6240,160
    BMOVE t%+9440,scr%+6400,160
    BMOVE t%+9280,scr%+6560,160
    BMOVE t%+9120,scr%+6720,160
    BMOVE t%+8960,scr%+6880,160
    BMOVE t%+8800,scr%+7040,160
    BMOVE t%+8640,scr%+7200,160
    BMOVE t%+8480,scr%+7360,160
    BMOVE t%+8320,scr%+7520,160
    BMOVE t%+8160,scr%+7680,160
    BMOVE t%+8000,scr%+7840,160
    BMOVE t%+7840,scr%+8000,160
    BMOVE t%+7680,scr%+8160,160
    BMOVE t%+7520,scr%+8320,160
    BMOVE t%+7360,scr%+8480,160
    BMOVE t%+7200,scr%+8640,160
    BMOVE t%+7040,scr%+8800,160
    BMOVE t%+6880,scr%+8960,160
    BMOVE t%+6720,scr%+9120,160
    BMOVE t%+6560,scr%+9280,160
    BMOVE t%+6400,scr%+9440,160
    BMOVE t%+6240,scr%+9600,160
    BMOVE t%+6080,scr%+9760,160
    BMOVE t%+5920,scr%+9920,160
    BMOVE t%+5760,scr%+10080,160
    BMOVE t%+5600,scr%+10240,160
    BMOVE t%+5440,scr%+10400,160
    BMOVE t%+5280,scr%+10560,160
    BMOVE t%+5120,scr%+10720,160
    BMOVE t%+4960,scr%+10880,160
    BMOVE t%+4800,scr%+11040,160
    BMOVE t%+4640,scr%+11200,160
    BMOVE t%+4480,scr%+11360,160
    BMOVE t%+4320,scr%+11520,160
    BMOVE t%+4160,scr%+11680,160
    BMOVE t%+4000,scr%+11840,160
    BMOVE t%+3840,scr%+12000,160
    BMOVE t%+3680,scr%+12160,160
    BMOVE t%+3520,scr%+12320,160
    BMOVE t%+3360,scr%+12480,160
    BMOVE t%+3200,scr%+12640,160
    BMOVE t%+3040,scr%+12800,160
    BMOVE t%+2880,scr%+12960,160
    BMOVE t%+2720,scr%+13120,160
    BMOVE t%+2560,scr%+13280,160
    BMOVE t%+2400,scr%+13440,160
    BMOVE t%+2240,scr%+13600,160
    BMOVE t%+2080,scr%+13760,160
    BMOVE t%+1920,scr%+13920,160
    BMOVE t%+1760,scr%+14080,160
    BMOVE t%+1600,scr%+14240,160
    BMOVE t%+1440,scr%+14400,160
    BMOVE t%+1280,scr%+14560,160
    BMOVE t%+1120,scr%+14720,160
    BMOVE t%+960,scr%+14880,160
    BMOVE t%+800,scr%+15040,160
    BMOVE t%+640,scr%+15200,160
    BMOVE t%+480,scr%+15360,160
    BMOVE t%+320,scr%+15520,160
    BMOVE t%+160,scr%+15680,160
    BMOVE t%+0,scr%+15840,160
    t%=t%-16000
    IF t%<320000
      t%=576000
    ENDIF
    IF INKEY$="+"
      t%=t%+16000
    ENDIF
    IF INKEY$="-"
      t%=t%-16000
    ENDIF
    VSYNC
  NEXT i
LOOP


[Invité]

@Stapha92

Au sujet de votre discussion concernant Paula et les DAC. Le fait que Paula prend 0% du processeur pour jouer une musique ne plaide t il pas tout simplement en sa faveur pour dire que c'est plus qu'une DAC ? Si j'ai bien compris une DAC ne peut pas faire ça ?

le DAC se contente juste de convertir un signal digital en analogique, point barre.  
du reste si je comprends bien, si Paula prend 0% du CPU, c'est uniquement grâce à l'agnus et non Paula.

Bah non justement, je comprends pk tu dis que paula c'est juste un DAC finalement ..
Agnus gère juste les différents DMA, mais tout le travail sur le son est fait par paula, les DAC arrivent en fin de chaine comme toutes les puces (synthé comprises) .

ah bon ? il y a un buffer dans Paula qui stocke un sample entier ?   

Bah oui, chaque DMA lit un word(le DMA est sur 16 bits), donc 2 octets à chaque foi et /voix, donc tu as bien un buffer de 2 samples pour chaque voix .
Et oui chaque octet est défini comme un sample mon cher rocky  

[rocky007]

Peut être ais je mal compris, mais Agnus envoi l'information à Paula et après il ne s'occupe de plus rien.

mais justement, c'est grâce à cela que paula n'utilise pas le CPU pour jouer un sample.  bien sûr, il sait aussi faire la modulation de façon autonome.

pour le STe je peux pas t'en dire plus précisément, désolé.

[rocky007]

Bah non justement, je comprends pk tu dis que paula c'est juste un DAC finalement ..
Agnus gère juste les différents DMA, mais tout le travail sur le son est fait par paula, les DAC arrivent en fin de chaine comme toutes les puces (synthé comprises) .

je suis d'accord pour le traitement du son ( modulation ), mais le fait qu'il n'utilise pas de CPU pour jouer un sample c'est avant tout grâce à l'agnus.

Bah oui, chaque DMA lit un word(le DMA est sur 16 bits), donc 2 octets à chaque foi et /voix, donc tu as bien un buffer de 2 samples pour chaque voix .
Et oui chaque octet est défini comme un sample mon cher rocky  

donc un buffer de 8 octets ..on est loin d'un sample complet  !
tu joues sur les mots, qd on parle de sample dans le langage courant, c'est pas une minuscule fraction de celui ci ( même si en théorie, cela reste valable ).  sample = un instrument par exemple

[Invité]

Peut être ais je mal compris, mais Agnus envoi l'information à Paula et après il ne s'occupe de plus rien.

Non c'est exactement ça, agnus est le contrôleur DMA du système,comme tout les systèmes tu as un contrôleur DMA unique, sinon ça serrait le bordel si tout les composants s'amusaient à faire du DMA comme ça sans aucune gestion.
Agnus gère les priorités des requêtes DMA de chaque composants, pour éviter par exemple qu'une puce prenne la priorité sur l'affichage .

donc un buffer de 8 octets ..on est loin d'un sample complet  !

stapha n'a pas parlé de sample complet, mais d'un buffer de 2 samples .
En réfléchissant 5 mins, tu peux te rendre facilement compte que buffériser un sample  complet est impossible, vu la taille, et en plus vu qu'elle est variable .

mais le fait qu'il n'utilise pas de CPU pour jouer un sample c'est avant tout grâce à l'agnus.

Non puisque agnus (au niveau de paula) est juste le contrôleur DMA, elle est là pour donner son accord ou pas aux requêtes DMA de paula en gros .

[rocky007]

En réfléchissant 5 mins, tu peux te rendre facilement compte que buffériser un sample  complet est impossible, vu la taille, et en plus vu qu'elle est variable .

pas besoin de 5 min , par exemple le soundchip du IIGS a bien une mémoire de 64ko interne

Non puisque agnus (au niveau de paula) est juste le contrôleur DMA, elle est là pour donner son accord ou pas aux requêtes DMA de paula en gros .

 oui c'est juste

[Invité]

En réfléchissant 5 mins, tu peux te rendre facilement compte que buffériser un sample  complet est impossible, vu la taille, et en plus vu qu'elle est variable .

pas besoin de 5 min , par exemple le soundchip du IIGS a bien une mémoire de 64ko interne

Oui elle dispose d'une sound RAM, comme la snes, c'est surement parce que la puce est incapable d'accéder à la RAM système pour aller chercher les samples,contrairement à l'amiga ou au STE .

Donc ca limite la qualité des musiques,comme sur snes .

tu joues sur les mots, qd on parle de sample dans le langage courant, c'est pas une minuscule fraction de celui ci ( même si en théorie, cela reste valable ).  sample = un instrument par exemple

Non je t'assure que c'est appelé comme ça,et d'ailleurs si tu regardes bien sur amiga 1 octets représente bien un sample numérique, d'une onde analogique,et tout les samples mis à la suite vont reconstituer ton onde finale(numérique).
L'abus de langage est bien d'appeler cette onde un sample .

[rocky007]

mais cette RAM peut être utilisée comme buffer dans un streaming par exemple...

bref on part encore n'importe où car ce n'était pas la question.  vu qu'il n'y a que 2 bytes de buffer sur Paula par voies, celai prouve que la fréquence à laquelle Paula doit recevoir ses informations est continue.

[Invité]

mais cette RAM peut être utilisée comme buffer dans un streaming par exemple...

Tu parles pour le 2GS ??
Je suppose que oui, faut voir les mécanismes mis en place dans le système, mais il me semble que dans le 2GS il faut le faire au CPU, y'a pas de DMA pour ça,ni de processeur dédié au son .

vu qu'il n'y a que 2 bytes de buffer sur Paula par voies, celai prouve que la fréquence à laquelle Paula doit recevoir ses informations est continue.

Ah oui forcement, mais c'est le principe de toutes les puces PCM, ou de simples DAC, il faut que le stream soit continu sinon tu as de la distorsion ou ça dégrade le sample(ou les 2) .
C'est pour ça que paula dispose de 2 octets/voix en buffer, et l'archie d'un FIFO(2 octets /voix aussi),la Md par contre n'en a aucun.
Et c'est là qu'entre en jeu la qualité du système d'arriver à maintenir ce flot quelque soit la fréquence .
Donc 2 machines capables de jouer des samples, ne sont pas logée à la même enseigne qd à la qualité de restitution .
C'est pour ça que la qualité PCM de l'archie ne vaut pas celle de l'amiga malgré les 8 voix(qui n'en sont pas vraiment)+log,sauf en 1 voix vs 1 voix là je pense que l'archie est devant.

[stapha92]

Oui c'est ça. Sauf que tu as prouvé que tu n'utilisais pas un mig pour des applications (voire des jeux) sinon tu aurais su qu'on ne met pas la disquette wb pour lancer une appli comme le gfa...

Je note que pleins d'applications sur ST obligent à ce que le GEM soit dans la réso dont elles ont besoin
 alors qu'il n'y en a que 2. Sur le mig la résolution d'une appli est totalement indépendante de celle du workbench, que ce soit une appli qui ouvre son écran ou qui utilise celui du workbench comme écran public...

bien sûr on peut optimiser bcp de choses sur amiga, je le sais.  Mais est-ce le cas que Monsieur père de famille qui a acheté son amiga et qui veut taper son texte ?  même de nos jours, qui sait vraiment exploiter  windows correctement et optimiser le boot ?    par grand monde je pense ..

pour la reso ST, c'est pourtant simple : tu as ta disquette GFA, tu la démarre et tu tombes sur le bureau directement à la bonne résolution, tu cliques et c'est parti.

Y a rien à optimiser ! Tu vas ou la ? Tu veux lancer un TT, un logiciel de dessin, le GFA ? Ben tu mets la disquette et tu allumes. C'est tout...

Aucune personne qui a vraiment utilisé un mig s'amuserait à lancer le WB, à attendre et enfin lancer son logiciel...

Pour la reso c'est normal de devoir recommencer le lancement d'une appli après avoir change la résolution de son bureau ?
Ok si tu sauves la résolution sur la disquette (et que tu reboote à chaque fois que tu changes d'appli...) ça t'arrivera plus rarement. Sur le mig ça n'arrive jamais sans que tu ais besoin de faire quoi que soit : c'est quoi le plus simple ?

C'est marrant comme les manip bizarroides imposées par le GEM sont normales pour des apotres de la convivialité...

il y a surement des logiciels à glisser dans l'auto qui permettent de le faire, perso j'en ai jamais utilisé.  c'est bcp de fumée encore de ta part , je ne vois pas le problème d'attendre 1 seconde pour être dans le bureau.
( contrairement à l'amiga ! ). 

On n'a qu'à dire que le boot auto ne sert à rien tant que tu y es. Et on dira qu'Atari est débile d'avoir ajouté ça pour les programmes du gem au bout de 4-5 ans...

ah oui c'est vrai que l'amiga et son CLI pour compenser les manquements du WB, c'est très convivial 

Et alors ? Je croyais que le couple TOS/GEM était la perfection en convivialité !!!!
Vous nous sortez l'exemple du directory toutes les 5 pages dans ce topic. par contre quand je te parle des manques du GEM, là tu dévies vers le mig...

Au moins avec le mig tu peux utiliser le cli pour afficher ton directory. Sur le ST pour renommer un répertoire ou déplacer un fichier tu n'as pas d'alternative sans patch...

C'est quoi le mieux ? Un plan B en ligne de commande ou pas de plan B du tout ?...

Et je ne parle pas des autres éléments de convivialité (nom longs non limités aux majuscules+chiffres, icones personnalisés,...).

Un exemple : lance ta disquette GFA et double clique sur un exemple. Ton GFA se lance et charge l'exemple. Y a pas plus simple ! Comment tu fais sur le ST ? Ah oui je sais : tu charges un 1247eme patch...

e ne vois pas le rapport : tu as essayé Quantum paint ( ou autre ) et moi pas, bravo.  on est obligé d'essayer tous les softs du ST quand on est un utilisateur sérieux ?

J'ai juste vu les réglages de couleurs dans une pub de Degas (je crois).
Mais je n'ai pas dit toi, j'ai dit : les utilisateurs du ST. Toi et d'autres nous ont expliqué pleins de fois que les utilisateurs ST utilisaient leur machine principalement pour des trucs sérieux.

ben voilà, il converti.  le fait qu'il soit moins performant et plus rudimentaire ne change rien, il a bien converti, c'est donc bien un DAC.  un DAC n'implique pas forcément un précision absolue.
c'est comme si tu disais que l'alimentation de ton amiga n'est pas un vraie alimentation, parce qu'elle n'est de précision.

C'est pas le fait qu'il manque de précision. C'est le fait qu'il soit sensible aux fluctuations du signal numérique. Ce qui est un oxymore dans le monde du numérique...

ah bon ? il y a un buffer dans Paula qui stocke un sample entier ?  

Marre toi : j'utilise le terme sample dans son vrai sens. Pas de ma faute si tu fais le même abus de langage que beaucoup sans le savoir.
Dans tous les manuels de développeur, le terme est employé correctement. C'est vrai que sur un STF, t'as pas du voir le terme souvent...

c'est toi qui ne m'a pas compris : je parlais de remplacer Paula par un réseau de résistance.  Agnus pourrait envoyer les bits nécessaires et sortir un son par le R2R.  Agnus devrait bien évidement être adapté pour envoyer les bons paquets.   et cette exemple n'a été donné que pour te dire le port // n'avait pas plus d'intérêt que Agnus dans un système avec R2R.

Oui c'est ça. Un agnus qui serait modifié et ne serait plus un agnus pourrait faire ce qu'un agnus non modifié ne pourrait pas faire. Super...

Il fournit les bits sur le bus ? Non : il fourni le signal qui sera utilisé directement (après conversion) pour la sortie. Ou bien j'ai mal vu ton schéma et j'ai raté l'alimentation de ton "DAC" ? Ah ben non...

ben si justement, il fournit les bits sur le bus du R2R

Avec un vrai DAC, qu'une sortie fournisse 3 v ou 3,5 v ou 4v ça ne change rien : on aura exactement le même signal en sortie. Parce qu'un vrai DAC s'occupe de l'état du signal. C'est le principe de base du numérique.
Avec ton R2R ce n'est pas le cas : on se fout de l'état. On répercute le signal directement en l'attenuant plus ou moins. Si tu peux pas comprendre qu'il s'agit d'un traitement uniquement analogique je peux rien pour toi (et comme par hasard l'analogique est lui sensible aux fluctuations)

les patchs ne sont pas là pour corriger la vitesse mais les limitations ( nombre de fenêtres, etc..).
et oui, sur ma video on voit clairement que les PRINT sous GEM sous aussi rapide qu'en direct 

Ah bon ? C'est pas pour la vitesse ? Et turboST ça veut dire quoi ?
Tu dis exactement le contraire de ce que tu viens de dire y a quelques pages...

Et turboST n'est pas le seul :
http://st-news.com/issues/st-news-volume-8-issue-1/reviews/warp-9-nvdi-turbo-st/

Tu as vu le titre ? "Screen Accelerators"...

Et tu as vu les benchmarks ? Certaines opération sont accélérées de plus de 1000% par rapport au GEM d'origine ! ça montre bien ce que je dis depuis le début : le GEM est lent...

tu continues ?  incroyable... je t'explique à nouveau : 1 bit converti en 24 = ridicule.

La bouillie de pixel dans l'exemple de Zarnal = ridicule...

non pour démontrer qu'avoir 24 bits pour travailler en tramé monochrome n'apportait rien... du reste, on t'entend plus sur la question des trames, ça y est la pièce est tombé, tu as enfin compris qu'un pro édite ses trames lui même ?

J'admet rien du tout : le tramage dépend de l'imprimante.
Je te rappelle que vous avez toujours affirmé que le ST était le champion pour faire de la PAO de façon personnelle. Vous n'arretez pas de citer Le rédacteur qui est hyper buggé et Calamus dont on a appris que même 2 Mo étaient insuffisants pour le faire fonctionner ! Donc personne ici n'a pu l'utiliser sur son ST de l'époque !

Alors maintenant tu essaies de t'en sortir en parlant du travail des pros. très bien alors je vais t'apprendre quelque chose : les pros étaient sur Mac...

Tu peux changer l'adresse écran sur le GFA non ? Donc tu peux faire l'effet en 50 i/s. ça prendra 2 fois plus de mémoire c'est tout.

oui mais là il n'y a plus aucun intérêt, ça devient un slide show

Tu stockes toutes tes images pleines à des adresses multiples de 256 (obligatoire à cause de la façon dont fonctionne le shifter). Et tu les places successivement dans le registre d'adresse écran.
4 octets à ecrire par vbl : en quoi ça devient un slide show ?

Dommage que tu ne l'ai plus.
Ok je vois. Les frames sont décalées de la même valeurs ? J'aurai cru que le parcours des frames du bas se ferait à l'inverse de celles du haut, pour que ça tourne dans le meme sens malgré l'inversion.

c'est ce que je pensais aussi au départ, mais il s'avère que  non, j'ai dû ajouter des raccourcis clavier pour déterminer le bon décalage entre la frame du haut et celle bas.

j'ai retrouvé le source.  tu m'excuseras d'avoir fait cela très salement ( pas de malloc ).   il y a 16 frames, et il faut un décalage de 10 entre les deux pour que cela soit correcte

[size=13]CODE:
[/size]

Code:

mem%=320000
BLOAD "c:\tube\tx0_on.pi1",mem%-34
VOID XBIOS(6,L:mem%-32)
FOR i=0 TO 16
  BLOAD "c:\tube\tx"+STR$(i)+"_on.pi1",mem%
  BMOVE mem%+34+16000,mem%,16000
  mem%=mem%+16000
NEXT i
t%=576000
scr%=XBIOS(2)
DO
  FOR i=320000 TO 576000 STEP 16000
    BMOVE i,XBIOS(2)+16000,16000
    BMOVE t%+15840,scr%+0,160
    BMOVE t%+15680,scr%+160,160
    BMOVE t%+15520,scr%+320,160
    BMOVE t%+15360,scr%+480,160
    BMOVE t%+15200,scr%+640,160
    BMOVE t%+15040,scr%+800,160
    BMOVE t%+14880,scr%+960,160
    BMOVE t%+14720,scr%+1120,160
    BMOVE t%+14560,scr%+1280,160
    BMOVE t%+14400,scr%+1440,160
    BMOVE t%+14240,scr%+1600,160
    BMOVE t%+14080,scr%+1760,160
    BMOVE t%+13920,scr%+1920,160
    BMOVE t%+13760,scr%+2080,160
    BMOVE t%+13600,scr%+2240,160
    BMOVE t%+13440,scr%+2400,160
    BMOVE t%+13280,scr%+2560,160
    BMOVE t%+13120,scr%+2720,160
    BMOVE t%+12960,scr%+2880,160
    BMOVE t%+12800,scr%+3040,160
    BMOVE t%+12640,scr%+3200,160
    BMOVE t%+12480,scr%+3360,160
    BMOVE t%+12320,scr%+3520,160
    BMOVE t%+12160,scr%+3680,160
    BMOVE t%+12000,scr%+3840,160
    BMOVE t%+11840,scr%+4000,160
    BMOVE t%+11680,scr%+4160,160
    BMOVE t%+11520,scr%+4320,160
    BMOVE t%+11360,scr%+4480,160
    BMOVE t%+11200,scr%+4640,160
    BMOVE t%+11040,scr%+4800,160
    BMOVE t%+10880,scr%+4960,160
    BMOVE t%+10720,scr%+5120,160
    BMOVE t%+10560,scr%+5280,160
    BMOVE t%+10400,scr%+5440,160
    BMOVE t%+10240,scr%+5600,160
    BMOVE t%+10080,scr%+5760,160
    BMOVE t%+9920,scr%+5920,160
    BMOVE t%+9760,scr%+6080,160
    BMOVE t%+9600,scr%+6240,160
    BMOVE t%+9440,scr%+6400,160
    BMOVE t%+9280,scr%+6560,160
    BMOVE t%+9120,scr%+6720,160
    BMOVE t%+8960,scr%+6880,160
    BMOVE t%+8800,scr%+7040,160
    BMOVE t%+8640,scr%+7200,160
    BMOVE t%+8480,scr%+7360,160
    BMOVE t%+8320,scr%+7520,160
    BMOVE t%+8160,scr%+7680,160
    BMOVE t%+8000,scr%+7840,160
    BMOVE t%+7840,scr%+8000,160
    BMOVE t%+7680,scr%+8160,160
    BMOVE t%+7520,scr%+8320,160
    BMOVE t%+7360,scr%+8480,160
    BMOVE t%+7200,scr%+8640,160
    BMOVE t%+7040,scr%+8800,160
    BMOVE t%+6880,scr%+8960,160
    BMOVE t%+6720,scr%+9120,160
    BMOVE t%+6560,scr%+9280,160
    BMOVE t%+6400,scr%+9440,160
    BMOVE t%+6240,scr%+9600,160
    BMOVE t%+6080,scr%+9760,160
    BMOVE t%+5920,scr%+9920,160
    BMOVE t%+5760,scr%+10080,160
    BMOVE t%+5600,scr%+10240,160
    BMOVE t%+5440,scr%+10400,160
    BMOVE t%+5280,scr%+10560,160
    BMOVE t%+5120,scr%+10720,160
    BMOVE t%+4960,scr%+10880,160
    BMOVE t%+4800,scr%+11040,160
    BMOVE t%+4640,scr%+11200,160
    BMOVE t%+4480,scr%+11360,160
    BMOVE t%+4320,scr%+11520,160
    BMOVE t%+4160,scr%+11680,160
    BMOVE t%+4000,scr%+11840,160
    BMOVE t%+3840,scr%+12000,160
    BMOVE t%+3680,scr%+12160,160
    BMOVE t%+3520,scr%+12320,160
    BMOVE t%+3360,scr%+12480,160
    BMOVE t%+3200,scr%+12640,160
    BMOVE t%+3040,scr%+12800,160
    BMOVE t%+2880,scr%+12960,160
    BMOVE t%+2720,scr%+13120,160
    BMOVE t%+2560,scr%+13280,160
    BMOVE t%+2400,scr%+13440,160
    BMOVE t%+2240,scr%+13600,160
    BMOVE t%+2080,scr%+13760,160
    BMOVE t%+1920,scr%+13920,160
    BMOVE t%+1760,scr%+14080,160
    BMOVE t%+1600,scr%+14240,160
    BMOVE t%+1440,scr%+14400,160
    BMOVE t%+1280,scr%+14560,160
    BMOVE t%+1120,scr%+14720,160
    BMOVE t%+960,scr%+14880,160
    BMOVE t%+800,scr%+15040,160
    BMOVE t%+640,scr%+15200,160
    BMOVE t%+480,scr%+15360,160
    BMOVE t%+320,scr%+15520,160
    BMOVE t%+160,scr%+15680,160
    BMOVE t%+0,scr%+15840,160
    t%=t%-16000
    IF t%<320000
      t%=576000
    ENDIF
    IF INKEY$="+"
      t%=t%+16000
    ENDIF
    IF INKEY$="-"
      t%=t%-16000
    ENDIF
    VSYNC
  NEXT i
LOOP

Ben si c'est exactement ça ! Ton FOR I (utilisé pour la moitié haute) va dans un sens (+16000 à chaque itération) et ton compteur t% (utilisé pour la moitié basse) va dans l'autre sens (-16000 à chaque fois).

Donc c'est bien ce que je pensais.

Si je peux me permettre, une astuce simple :
Plutot que de soustraire 16000 à ton t% et de tester s'il passe sous la valeur minimale à chaque fois, il vaut mieux éviter le test en mettant la ligne :

Code:

t% = 896000 - I

juste après le FOR : plus besoin du test (qui est chronophage dans tous les langages) et plus besoin d'initialiser t%

C'est une astuce classique à utiliser quand 2 variables vont dans 2 directions opposées. Je cite juste au cas ou. Ce n'est pas une critiques du tout !!

En tout cas merci pour ces précisions.

[rocky007]

Ok si tu sauves la résolution sur la disquette (et que tu reboote à chaque fois que tu changes d'appli...) ça t'arrivera plus rarement. Sur le mig ça n'arrive jamais sans que tu ais besoin de faire quoi que soit : c'est quoi le plus simple ?

c'est vraiment un faux débat : toutes les applis fonctionnent en moyenne ou en haute.  tu ne changes donc jamas de réso...sauf quand tu joues ( et encore, le jeu, rappessera lui-même en basse )

On n'a qu'à dire que le boot auto ne sert à rien tant que tu y es. Et on dira qu'Atari est débile d'avoir ajouté ça pour les programmes du gem au bout de 4-5 ans...

je pense surtout que cela a été prévu comme cela pour économiser un peu de mémoire
il n'y a rien de différence avec TOUS les ordinateurs d'aujourd'hui : tu dois charger ta GUI pour l'utiliser

Et alors ? Je croyais que le couple TOS/GEM était la perfection en convivialité !!!!

ah ok, je pensais que tu prétendais le contraire...autant pour moi.  oui je pense comme toi que c'est la perfection en convivialité

Au moins avec le mig tu peux utiliser le cli pour afficher ton directory. Sur le ST pour renommer un répertoire ou déplacer un fichier tu n'as pas d'alternative sans patch...

C'est quoi le mieux ? Un plan B en ligne de commande ou pas de plan B du tout ?...

ben si tu as le droit de charger ta ligne de commande, pourquoi tu n'aurais pas le droit de charger un accessoire dans le ST qui résoud tous les problèmes ?

J'ai juste vu les réglages de couleurs dans une pub de Degas (je crois).
Mais je n'ai pas dit toi, j'ai dit : les utilisateurs du ST. Toi et d'autres nous ont expliqué pleins de fois que les utilisateurs ST utilisaient leur machine principalement pour des trucs sérieux.

et le fait qu'ils n'utilisent pas Quantum Paint n'en font pas pour autant des utilisateurs sérieux ?
c'est réducteur

C'est pas le fait qu'il manque de précision. C'est le fait qu'il soit sensible aux fluctuations du signal numérique. Ce qui est un oxymore dans le monde du numérique...

oui mais cela n'en change pas sa fonction de DAC.

Oui c'est ça. Un agnus qui serait modifié et ne serait plus un agnus pourrait faire ce qu'un agnus non modifié ne pourrait pas faire. Super...

c'était juste pour la démonstration théorique

 Si tu peux pas comprendre qu'il s'agit d'un traitement uniquement analogique je peux rien pour toi (et comme par hasard l'analogique est lui sensible aux fluctuations)

si tu ne peux pas comprendre qu'il te converti 8 bits en en signal analogique, je peux rien pour toi non plus
c'est marrant que tout le monde appelle cela DAC R2R... mais toi, le grand stapha, décide que non, ce n'est pas un DAC.  tu plus tes variations n'existent que dans le cas d'une alimentation mauvaise.  sur une alim de précision, tu n'auras pas ces variations sur les bits.  CQFD

Ah bon ? C'est pas pour la vitesse ? Et turboST ça veut dire quoi ?
Tu dis exactement le contraire de ce que tu viens de dire y a quelques pages...

ah ce je sache Turbo ST n'est pas un patch Atari
et le fait que sur amiga prouve simplement que personne n'a eut la bonne idée de le faire et que le blitter a pu compenser

je te rappelle : la fenêtre GEM sur Atari tournait aussi vite que ta fenêtre Amiga qui lui a pourtant un blitter
mais au vu de tes nombreuses affirmations fausses sur le GEM, j'ai l'impression que tu ne l'as jamais utilisé, te contentant de dire " des gens disent que..."

La bouillie de pixel dans l'exemple de Zarnal = ridicule...

c'est idem encore pire sur amiga, je l'ai montré ainsi que Zarnal quand tu travailles une image tramée

J'admet rien du tout : le tramage dépend de l'imprimante.

relis les citations que j'ai indiqué au lieu de dire des bêtises

Je te rappelle que vous avez toujours affirmé que le ST était le champion pour faire de la PAO de façon personnelle. Vous n'arretez pas de citer Le rédacteur qui est hyper buggé et Calamus dont on a appris que même 2 Mo étaient insuffisants pour le faire fonctionner ! Donc personne ici n'a pu l'utiliser sur son ST de l'époque !

faux, j'utilisais régulièrement Calamus avec mon 1040 et sans HD !

Alors maintenant tu essaies de t'en sortir en parlant du travail des pros. très bien alors je vais t'apprendre quelque chose : les pros étaient sur Mac...

c'est bizarre, il y avait bcp de studio pros dans ma région qui travaillaient tous sur ST.  bizarre non ?

Tu stockes toutes tes images pleines à des adresses multiples de 256 (obligatoire à cause de la façon dont fonctionne le shifter). Et tu les places successivement dans le registre d'adresse écran.
4 octets à ecrire par vbl : en quoi ça devient un slide show ?

parce que tu te bornes à simplement afficher 16 images une après l'autre.  c'est un slide show

Ben si c'est exactement ça ! Ton FOR I (utilisé pour la moitié haute) va dans un sens (+16000 à chaque itération) et ton compteur t% (utilisé pour la moitié basse) va dans l'autre sens (-16000 à chaque fois).

Donc c'est bien ce que je pensais.

non, tu ne m'as pas lu : dans le programme, il part en effet de la dernière image vers la première, mais j'ai ajouté un réglage via pour modifier le décalage.  si tu le lances tel quel le programme, le mirror ne sera pas raccord, tu dois décaler de 10 frames

Si je peux me permettre, une astuce simple :
Plutot que de soustraire 16000 à ton t% et de tester s'il passe sous la valeur minimale à chaque fois, il vaut mieux éviter le test en mettant la ligne :

Code:

t% = 896000 - I

juste après le FOR : plus besoin du test (qui est chronophage dans tous les langages) et plus besoin d'initialiser t%

c'est très gentil de ta part, sauf qu'ici cela ne marchera pas puisque l'adresse doit être modifiée par les touches + et - pour trouver le bon décalage.

[Invité]

un DAC n'est pas couteux.   les 6 voies de la MD c'est de la FM, pas du PCM.
tu va me dire, alors pq pas 6 voies PCM ?  ben c'est une question de choix : les jeux devant être stocké sur des cartouche, je pense pas que retenir une solution de musique à base de module couteux en mémoire soit la meilleure solution pour la MD !  ils ont fait le juste choix.

Oui c'est 6 voix FM, mais ensuite il faut transformer le son(qui reste numérique )en analogique, et les 6 voix passent par un seul DAC au lieux de 6 (1 par voix) comme la PCE par exemple .
La puce switche chacune des voix alternativement dans ce seul DAC ce qui amène de la latence lors de l'utilisation de la voix PCM .

[Meditating Guru]

Si j'ai ramené la MT32 la dedans, comme tu dis, c'est au départ par curiosité. Je ne la connaissais pas cette carte. Mais, je me souvenais qu'à l'époque dans les tests les commentaires étaient élogieux disant que c'était "merveilleux" (en substance).

Donc, avec Youtube j'ai eu l'occasion de comparer. Et bien, ce fut une véritable déception, c'est une carte qui sort certes un son limpide, mais c'est tout. 

Donc peut-être tous les testeurs se sont trompés, ou peut-être tu as écouté le mod de trop sur ton Amiga.

Le fond de ma réflexion (et je pense que tu l'as très bien compris), c'est de dire que pour une carte à ce prix là, il est, de mon point de vue, inadmissible que les musiques qu'elle sort n'arrivent pas à égaler et surtout surpasser la version Amiga dans la majorité des cas ! Alors, comme tu l'as dis c'est Roland... c'est surement pour ça que c'est cher. Mais une marque peut aussi vendre un truc moyen rien que par son nom (voir Apple). Et, pour moi c'est ce qu'ils ont fait avec la MT32.

Roland et Yamaha sont connus pour leur qualité, Apple un peu moins. Tiens, Yamaha, les producteurs du YM-2149.

Tu l'as dit toi même, à l'époque le son samplé de l'Amiga (et aussi sur le STE, voir ST) ça t'allait. Donc critiquer le son de l'Amiga avec du recul comme "obsolète" alors qu'il y avait pas mieux à l'époque... bof.

Disons que ça faisait illusion à son époque.

Et même les samples moyens du ST furent utilisés dans un HIT:

On dirait qu'il voulaient un son bien pourri qui fasse voix de robot. Ils ont du essayer sur mig et se rendre compte que le son était trop bon pour le rendu qu'ils voulaient !

Je ne vois pas comment, le son du ST grésille beaucoup trop y compris en terme de samples pour que ça soit utilisé dans de la musique commerciale. 

Que le ST ait été utilisé pour piloter du synthé sur ce morceau je veux bien, mais les samples, pitié, pas ça et pas à moi (ni aux autres).

Si si. le ST a été utiliser pour la voix. ça s'entend très bien d'ailleurs...

EDIT : Et ça n'a rien d'extraordinaire : y a bien des morceaux qui sont sorti avec une poubelle en guise de grosse caisse. Comme quoi l'exemple de guru n'est pas le seul d'une musique commerciale avec un son de poubelle...

Tristesse :/ Vive la musique commerciale à pas cher.....

Oh les petits jaloux!
C'était un grand succès de la techno. A croire que le public aimait le son du ST même en sample...
En fait, le ST a été utilisé comme un instrument (en plus de peut-être piloter le reste), pas pour sa haute fidélité, mais pour le timbre robotique particulier.
Tiens je me demande si on entend l'Amiga dans un hit comparable ou mieux, vu qu'il était si bien que ça?

[babsimov]

Peut être ais je mal compris, mais Agnus envoi l'information à Paula et après il ne s'occupe de plus rien.

mais justement, c'est grâce à cela que paula n'utilise pas le CPU pour jouer un sample.  bien sûr, il sait aussi faire la modulation de façon autonome.

pour le STe je peux pas t'en dire plus précisément, désolé.

C'est possible, mais si le fait que Paula n'utilise pas de processeur est du à Agnus, comment ce fait il que la Gravis Ultrasound sur PC n'utilise pas le processeur, alors qu'une soundblaster16 sur la même machine utilisera du processeur ? Il n'y a pas Agnus sur PC, cela laisse supposer qu'il y a bien quelque chose dans la Gravis Ultrasound qui fait la différence ? Comme il a été dit la Gravis Ultrasound, c'est Paula en mieux, donc par extrapolation il y aurait aussi quelques chose dans Paula qui ferait qu'il n'y pas de processeur utilisé ?

Peut être ais je mal compris, mais Agnus envoi l'information à Paula et après il ne s'occupe de plus rien.

Non c'est exactement ça, agnus est le contrôleur DMA du système,comme tout les systèmes tu as un contrôleur DMA unique, sinon ça serrait le bordel si tout les composants s'amusaient à faire du DMA comme ça sans aucune gestion.
Agnus gère les priorités des requêtes DMA de chaque composants, pour éviter par exemple qu'une puce prenne la priorité sur l'affichage .

Je veux bien, mais alors quid du cas de la Gravis Ultrasdound dont je viens de parler au dessus ?

Si j'ai ramené la MT32 la dedans, comme tu dis, c'est au départ par curiosité. Je ne la connaissais pas cette carte. Mais, je me souvenais qu'à l'époque dans les tests les commentaires étaient élogieux disant que c'était "merveilleux" (en substance).

Donc, avec Youtube j'ai eu l'occasion de comparer. Et bien, ce fut une véritable déception, c'est une carte qui sort certes un son limpide, mais c'est tout. 

Donc peut-être tous les testeurs se sont trompés, ou peut-être tu as écouté le mod de trop sur ton Amiga. 

Ou peut être qu'ils comparaient par rapport à une soundblaster et là on peut être d'accord, la MT32 c'est mieux. 

Le fond de ma réflexion (et je pense que tu l'as très bien compris), c'est de dire que pour une carte à ce prix là, il est, de mon point de vue, inadmissible que les musiques qu'elle sort n'arrivent pas à égaler et surtout surpasser la version Amiga dans la majorité des cas ! Alors, comme tu l'as dis c'est Roland... c'est surement pour ça que c'est cher. Mais une marque peut aussi vendre un truc moyen rien que par son nom (voir Apple). Et, pour moi c'est ce qu'ils ont fait avec la MT32.

Roland et Yamaha sont connus pour leur qualité, Apple un peu moins. Tiens, Yamaha, les producteurs du YM-2149.  

C'est comme tout, chez toutes les marques, il y a le haut de gamme et l'entrée de gamme. Le YM2149 était clairement du bas de gamme, surtout à l'époque du ST. 

La MT32 était destinée aux musiciens amateurs, donc pareil de l'entrée de gamme, très cher et finalement pas si terrible que ça. 
https://en.wikipedia.org/wiki/Roland_MT-32

Tu l'as dit toi même, à l'époque le son samplé de l'Amiga (et aussi sur le STE, voir ST) ça t'allait. Donc critiquer le son de l'Amiga avec du recul comme "obsolète" alors qu'il y avait pas mieux à l'époque... bof.

Disons que ça faisait illusion à son époque.  

Disons que tu donnes dans la mauvaise foi depuis un certain temps 

[rocky007]

C'est possible, mais si le fait que Paula n'utilise pas de processeur est du à Agnus, comment ce fait il que la Gravis Ultrasound sur PC n'utilise pas le processeur, alors qu'une soundblaster16 sur la même machine utilisera du processeur ? Il n'y a pas Agnus sur PC, cela laisse supposer qu'il y a bien quelque chose dans la Gravis Ultrasound qui fait la différence ? Comme il a été dit la Gravis Ultrasound, c'est Paula en mieux, donc par extrapolation il y aurait aussi quelques chose dans Paula qui ferait qu'il n'y pas de processeur utilisé ?

je serais vraiment étonné que la soundblaster 16 aurait besoin intensivement du CPU
, du moins plus que la Gravis.  As-tu un lien ?

[dlfrsilver]

Sur PC, les cartes sons utilisent des pilotes, d'une bonne taille d'ailleurs, et forcément, ces derniers sont moulinés par le CPU principal, donc il y a forcément usage du CPU du PC.

[Invité]

Je veux bien, mais alors quid du cas de la Gravis Ultrasdound dont je viens de parler au dessus ?

Je pense que ça dépend de son utilisation, si tu utilises le synthétiseur interne basé sur les wavetables le CPU est peu utilisé .
Les variations de fréquences des sons sont faite par un processeurs interne à la carte qui fait une interpolation du son .
Donc dans les faits, même si tu utilise le CPU, ce sera juste pour envoyer les samples à la carte(qui dispose de min 256 ko de RAM), le traitement audio va être fait par la GUS .
Mais bon vu la taille de la carte tu te doutes bien qu'un système limitant l'utilisation du CPU existe,et en 92 les CPU PC étaient suffisamment puissant pour que le % d'utilisation soit négligeable .

[Zarnal]

Oh les petits jaloux!
C'était un grand succès de la techno. A croire que le public aimait le son du ST même en sample...
En fait, le ST a été utilisé comme un instrument (en plus de peut-être piloter le reste), pas pour sa haute fidélité, mais pour le timbre robotique particulier.
Tiens je me demande si on entend l'Amiga dans un hit comparable ou mieux, vu qu'il était si bien que ça?

Hello guru, il suffit de demander :

https://www.youtube.com/watch?v=N1YLnlkzsBk

Mauvaise foi pleinement assumée.

Et si tu veux vraiment un timbre robotique mémorable :

[Urbinou]

Oh les petits jaloux! Mr. Green
C'était un grand succès de la techno. A croire que le public aimait le son du ST même en sample...

Mouais, à côté de Babylon 5 c'est un peu du pipi de chat hein

[Zarnal]

Sans oublier :



A défaut de l'entendre de trop, on le voit en action dans un vieux programme populaire sur une grande chaine nationale...

Le jeu sur A500 : https://www.youtube.com/watch?v=HzQ6ST2bUlQ

Ne pas oublier qu'il s'agit d'un jeu TV à la base.

[rocky007]

Hello guru, il suffit de demander :

https://www.youtube.com/watch?v=N1YLnlkzsBk

sauf que c'est pas le vrai Moby... dommage pour toi

[Invité]

Enfin y'a pas mal de DJ d'aujourd'hui qui ont fait leurs armes sur amiga .

c'est la classe:
http://www.tinyvoice.com/creator/dj-amiga/     
Au moins ça sent pas la vinasse comme sur ST 

[Zarnal]

Hello guru, il suffit de demander :

https://www.youtube.com/watch?v=N1YLnlkzsBk

sauf que c'est pas le vrai Moby... dommage pour toi

Ok, sortons l'artillerie alors :

10. L’Amiga peut faire du disco

En tant qu’ordinateur personnel, l’Amiga était capable de réaliser toutes sortes de tâches autres que de lancer des jeux. Par exemple, on peut y composer des albums à succès mondial. Le premier album de Calvin Harris sorti en 2007, nommé « I Created Disco » et qui intégrait son tube « Acceptable In The 80s » fut entièrement réalisé dans son home studio à l’aide de son vieil Amiga 1200 vieux de 15 ans.

[Invité]

Tu as muttonheads aussi:



Sinon on peut voir que le tracker amiga n'est pas mort:
http://pt1210.kikencorp.com/

octamed:

[babsimov]

C'est possible, mais si le fait que Paula n'utilise pas de processeur est du à Agnus, comment ce fait il que la Gravis Ultrasound sur PC n'utilise pas le processeur, alors qu'une soundblaster16 sur la même machine utilisera du processeur ? Il n'y a pas Agnus sur PC, cela laisse supposer qu'il y a bien quelque chose dans la Gravis Ultrasound qui fait la différence ? Comme il a été dit la Gravis Ultrasound, c'est Paula en mieux, donc par extrapolation il y aurait aussi quelques chose dans Paula qui ferait qu'il n'y pas de processeur utilisé ?

je serais vraiment étonné que la soundblaster 16 aurait besoin intensivement du CPU
, du moins plus que la Gravis.  As-tu un lien ?

C'est Cryodav qui l'a dit ici :
https://www.gamopat-forum.com/t90780p840-guerre-st-amiga-fight#2504939

La citation :

cryodav76
la premiere carte pc  qui  dépassai l'amiga etait la gravis ultrasound batti comme ...paula elle coûtai le prix d'un amiga, j'en ai eu une en 1996 en solde a 590fr et ce qui  changeait par rapport a un sb16 c'est 0% d'occupation cpu mais ça les ataristes ne peuvent pas comprendre  
une demo 28 voies(la musique existe en mod et c'est 100% d'utilisation cpu sur un dx4 100 win95 sb16 ,zero sur la gravis)
https://modarchive.org/index.php?request=view_by_moduleid&query=35344

Les démomakers PC semblaient privéligier cette carte justement parce c'était 0% de processeur utilisé, comme sur Amiga.

Oh les petits jaloux! Mr. Green
C'était un grand succès de la techno. A croire que le public aimait le son du ST même en sample...

Mouais, à côté de Babylon 5 c'est un peu du pipi de chat hein 

Très bonne série, à voir ou revoir 

[Invité]

ya Aphrodite aussi qui remixait tout ce qu'il pouvait avec sa paire de 1200







ah l'amen break.. la raison de l'achat de mon amiga...

sinon s'extasier sur une voix robotique de 2 secondes grand maximum qui aurait pu aussi bien sortir d'un cpc ...ouais ok

le theme original déchire par contre

[ryosaeba]

il y a aussi :

http://www.roanne-vibes.com/groupe/paula-powered/

[Invité]

Comme quoi !!  y'a plein de super exemples .