Non, pas les samples ! D'ailleurs je crois que pour les samples ça n'a jamais été le cas sur leurs machines (si un possesseur d'AR peut confirmer... j'ai vendu la mienne)
Si pas les samples...
Ca voudrait dire quand cas de crash, tu dois remettre dans le pool les samples
Mais faudrait il les télécharger dans le même ordre / répertoire qu'ils étaient ?
Ça me semble pas évident de faire ce type de backup...
Imagine je crée une vingtaine de sample, je les utilise dans un projet que je nomme 'AAA'.
J'utilise 30 autres samples d'un peu partout de la mémoire interne.
Je finis mon projet.
Je le backup en sysex.
Si la DT disons elle est cassé. J'en reprend une, il aurait fallu que je backup chacun des 20 samples que j'avais créé et du reste de la mémoire interne ?
Disons que si on a déjà tous ses samples sur son PC et qu'on note bien toutes leurs utilisations au moment de faire les backup, ça peut marcher, mais oui c'est vraiment trop fastidieux.
Pas encore vraiment testé, mais le manuel mentionne une hash table pour identifier les samples, ce qui fait que si on déplace un sample, qu'on le renomme voire (pas testé) qu'on l'afface puis qu'on le recharge dans le +Drive, il reste référencé dans le Sound.
Cela voudrait dire que quand on charge un Sound, le numéro du slot n'est pas important, il suffit de charger le sample dont le hash correspond dans un slot vide et d'assigner le numéro du slot dans le pattern (les Sounds sont copiés dans le pattern à l'import).
J'en saurais plus si j'ai le temps ce weekend, mais la hash table et le sysex dump ne serviraient pas à grand chose si tout est lié au numéro du slot en RAM.