Samplitude incompatible Focusrite
-
indy976
Samplitude incompatible Focusrite
Bonjour, j'ai télécharger la version demo de samplitude pro x suite afin de l'essayer avant de l'acheter 80 go sauf qu elle est pleinement incompatible avec ma scarlett 18i6 tout comme engine 2. En fait tous les produits Magix ne fonctionne pas sur mon ordi. j'ai des craquements qui ne sont pas du au materiel puisque je bosse sur sonar X2 ou reaper sans aucuns soucis de ressources. i7, 8 go de ram Win 7 x64 et ssd. Sur samplitude avec la derniere mise a jour j'ai des craquements et si j'utilise engine 2 de Magix sur sonar je retrouve ces meme craquements qui n'apparaises pas sur d'autre plugins. j'ai essayé aussi sur une VRM box de focusrite et j'ai le même résultat. je ne peux pas en revanche utiliser engine 2 en standalone car il m'indique qu'il ne peut acceder au buffers audio de la scarlett. peut etre est ce la cause. j'ai essayé engine 2 free sur Mac et la je n'ai aucun probleme. tout roule. je souhaiterais vraiement regler ce probleme car Samplitude remplit toutes les conditions de mon utilisation. merci pour vos éclaircissements.
Re: Samplitude incompatible Focusrite.
ca doit être l'orthographe... ca doit être pour çà que ca ne fonctionne pas.
(ou bien plus probablement un souci de fréquence d'échantillonnage)
(ou bien plus probablement un souci de fréquence d'échantillonnage)
-
indy976
Re: Samplitude incompatible Focusrite.
Que je sois en 44.1 ou 88.2 cela ne fonctionne pas. Sonar et reaper ne me posent pas de problème, en revanche Samplitude, Engine 2 en standalone ou en hôte sur Sonar ou reaper provoquent des craquements. c'est un truc de dingue.
Re: Samplitude incompatible Focusrite.
n'y a t'il pas un driver avec qq chose à régler ? certaines applications se calent sur la fréquence de l'interface (et aussi la résolution, 16 ou 24 bits généralement) mais d'autres "imposent" une fréquence d'échantillonnage...
il faudrait vérifier que tout le monde est bien en 44,1khz/16 bit (ou mieux en 44,1khz/24 bit...)
il faudrait vérifier que tout le monde est bien en 44,1khz/16 bit (ou mieux en 44,1khz/24 bit...)
Re: Samplitude incompatible Focusrite.
Il y a aussi le réglage des buffer (auxquels je n'ai jamais rien compris, d'ailleurs)
Régis Fraisse
Re: Samplitude incompatible Focusrite.
le son, comme la vidéo, nécessite une gestion précise du facteur temps. Cad que lorsqu'on sample un son et qu'il arrive dans l'ordinateur, par exemple, sous la forme (c'est une image) => 12345
il ne s'agit pas qu'il arrive sous la forme 13425 ou tout autre combinaison. Or, les interfaces informatiques (usb & ethernet en premier, le firewire un peu moins) ne sont pas faites pour çà et se foutent bien de savoir dans quel ordre elles vont recevoir les paquets, car elles les remettent dans le bon ordre un fois réceptionnés. Sauf si que si je recois le sample 1, je ne peux pas le diffuser/traiter directement... car je ne sais pas l'ordre tant que je n'ai pas tout reçu. Je dois donc le garder en "mémoire" le temps de recevoir la séquence entière. c'est une mémoire tampon, un buffer.
De la même façon, si ma séquence arrive sous la forme 1345.. il manque le 2. Je ne peux pas redemander à l'interface son de me renvoyer ce sample: elle est déjà bien plus loin dans le temps... je dois donc le recalculer par interpolation (je mesure 1 et 3, puis j'en déduis 2). Ca prends du temps. Pendant ce temps, je dois conserver 1345 en mémoire. Re-buffer.
Il y a d'autres exemples d'utilisations du buffer, mais en voilà deux. Evidemment, il s'agit d'opérations qui se passent très vite... mais cela signifie donc que je vais traiter/diffuser/transmettre le son avec un certain retard (le temps qu'il passe dans le buffer), cela donne donc une latence (temps entre l'émission et la réception, entre l'émission et le traitement, entre la lecture et la diffusion, etc...).
Si mon ordi est rapide, de qualité, de mêmes que ces composants, ou si je dispose de processeurs dédiés au traitement du signal (DSP, Digital Signal Processor), je peux réduire cette latence à un niveau tellement bas que le cerveau ne la détectera pas...
par contre, si mon ordi est grand public, et mon interface aussi, il faut leur laisser le temps de travailler.... donc on augmente les buffers, cela donne plus de marge à l'ordinateur pour fonctionner. Par contre, cela signifie qu'il y aura un retard audible (déphasage au début, puis retard à proprement parler) entre l'émission et la réception, entre l'émission et le traitement, entre la lecture et la diffusion, etc...
Voilà, ca fait 300 écus savoyards, c'est à dire environ un reblochon et demi mais cuit à point avec oignon, lards et galette de patates. Entre savoyards (enfin, ma famille vient de savoie...moi, je suis un citoyen du monde - mode jmelapète ON), on devrait trouver un terrain d'entente avec un petit blanc fruité d'ici ou de là.
il ne s'agit pas qu'il arrive sous la forme 13425 ou tout autre combinaison. Or, les interfaces informatiques (usb & ethernet en premier, le firewire un peu moins) ne sont pas faites pour çà et se foutent bien de savoir dans quel ordre elles vont recevoir les paquets, car elles les remettent dans le bon ordre un fois réceptionnés. Sauf si que si je recois le sample 1, je ne peux pas le diffuser/traiter directement... car je ne sais pas l'ordre tant que je n'ai pas tout reçu. Je dois donc le garder en "mémoire" le temps de recevoir la séquence entière. c'est une mémoire tampon, un buffer.
De la même façon, si ma séquence arrive sous la forme 1345.. il manque le 2. Je ne peux pas redemander à l'interface son de me renvoyer ce sample: elle est déjà bien plus loin dans le temps... je dois donc le recalculer par interpolation (je mesure 1 et 3, puis j'en déduis 2). Ca prends du temps. Pendant ce temps, je dois conserver 1345 en mémoire. Re-buffer.
Il y a d'autres exemples d'utilisations du buffer, mais en voilà deux. Evidemment, il s'agit d'opérations qui se passent très vite... mais cela signifie donc que je vais traiter/diffuser/transmettre le son avec un certain retard (le temps qu'il passe dans le buffer), cela donne donc une latence (temps entre l'émission et la réception, entre l'émission et le traitement, entre la lecture et la diffusion, etc...).
Si mon ordi est rapide, de qualité, de mêmes que ces composants, ou si je dispose de processeurs dédiés au traitement du signal (DSP, Digital Signal Processor), je peux réduire cette latence à un niveau tellement bas que le cerveau ne la détectera pas...
par contre, si mon ordi est grand public, et mon interface aussi, il faut leur laisser le temps de travailler.... donc on augmente les buffers, cela donne plus de marge à l'ordinateur pour fonctionner. Par contre, cela signifie qu'il y aura un retard audible (déphasage au début, puis retard à proprement parler) entre l'émission et la réception, entre l'émission et le traitement, entre la lecture et la diffusion, etc...
Voilà, ca fait 300 écus savoyards, c'est à dire environ un reblochon et demi mais cuit à point avec oignon, lards et galette de patates. Entre savoyards (enfin, ma famille vient de savoie...moi, je suis un citoyen du monde - mode jmelapète ON), on devrait trouver un terrain d'entente avec un petit blanc fruité d'ici ou de là.
Re: Samplitude incompatible Focusrite.
Merci pour ces infos que j'ignorais.
Dans Samplitude, il y a la taille des buffers, et leur nombre : pourquoi 4 petit et pas 2 gros, par exemple ?
Le blanc au réveil, je préfère qu'il soit sec.
Dans Samplitude, il y a la taille des buffers, et leur nombre : pourquoi 4 petit et pas 2 gros, par exemple ?
Le blanc au réveil, je préfère qu'il soit sec.
Régis Fraisse
Re: Samplitude incompatible Focusrite.
ah, je dois confesser que je ne connais pas Samplitude (oui, je lis aussi des topics dans des softs que je ne connais pas... hihihi)... donc, je ne saurais te dire.
dans PT, c'est donné en nombres de samples...
dans PT, c'est donné en nombres de samples...