Sujet Banques de sons pour XV
- 19 réponses
- 8 participants
- 1 153 vues
- 11 followers
Afficher le premier post
C'est pour cela que j'ai acheté un vénérable XV-5080... parti presque aussitôt en cure de jouvence, mais dont la brève fréquentation a tout de suite confirmé la pertinence ce choix.
- 1
- 2
.: Odon Quelconque :.
10757
Drogué·e à l’AFéine
Hors sujet :
Citation de phanou2000 :je commençait à lorgner sur le nouveau Fantom-06. L'édition des patchs Zen-core est si chiante que ça ?
Sur les Fantom et Fantom-0, probablement pas grâce au grand écran tactile et à la surface de contrôle généreuse.
Sur le Jupiter-Xm, c'était une autre histoire.
Mais le son n'est pas en cause.
C'est surtout que, n'étant pas instrumentiste, je n'accroche pas au concept et à l'UI des ZEN-Core : une juxtaposition de modules logiciels génériques déclinés à l'envi dans des machines logiciellement bancales, dans lesquelles on retrouve toujours les mêmes banques de sons de base conjugués à des limitations fonctionnelles totalement artificielles dont le but premier est de segmenter les produits et de vendre du contenu supplémentaire.
Ergo https://www.roland.com/global/support/by_product/rc_n_zyme_model_expansion/support_documents/319ed642-8e1d-4b0b-a6ec-5d730f30cd8d/?fbclid=IwAR3rVxAn-LOx5qUe7cJUDb9OXczE6fDYh8Us9rV8BvkZg8wqmKtFX76xhPQ
Ni donc au modèle commercial : une dépendance forcée au Roland Cloud pour tout le contenu optionnel, lié au compte utilisateur et non cessible.
Pour mon très modeste usage, je suis plus à l'aise avec les machines monolithiques Roland des années 95/2000 - certes plus limitées - mais que je trouve techniquement et logiciellement infiniment plus abouties. SysEx rulez.
C'est pour cela que j'ai acheté un vénérable XV-5080... parti presque aussitôt en cure de jouvence, mais dont la brève fréquentation a tout de suite confirmé la pertinence ce choix.
« What is full of redundancy or formula is predictably boring. What is free of all structure or discipline is randomly boring. In between lies art. » (Wendy Carlos)
siliconsensor
51
Posteur·euse AFfranchi·e
.: Odon Quelconque :.
10757
Drogué·e à l’AFéine
phanou2000
736
Posteur·euse AFfolé·e
Eric Music Strasbourg
4594
Squatteur·euse d’AF
.: Odon Quelconque :.
10757
Drogué·e à l’AFéine
D'après l'en-tête, les fichiers n'ont pas l'air corrompus :
Par contre, il doit s'agir d'un format propriétaire Roland, pour lequel il existe semble-t-il un convertisseur (qui tourne sous WinXP) :
https://forums.rolandclan.com/viewtopic.php?p=143813
Par contre, il doit s'agir d'un format propriétaire Roland, pour lequel il existe semble-t-il un convertisseur (qui tourne sous WinXP) :
https://forums.rolandclan.com/viewtopic.php?p=143813
« What is full of redundancy or formula is predictably boring. What is free of all structure or discipline is randomly boring. In between lies art. » (Wendy Carlos)
siliconsensor
51
Posteur·euse AFfranchi·e
ToonSpirit
822
Posteur·euse AFfolé·e
.: Odon Quelconque :.
10757
Drogué·e à l’AFéine
En tout cas je confirme que l'importation des Patches de la gamme JV/XP sur le XV fonctionne globalement bien, y compris avec les cartes SR-JV80 (pour peu qu'elles soient présentes bien sûr).
C'est moins vrai pour les Performances multi-timbrales par contre, notamment sur les effets, les drumkits et parfois des erreurs de pitch 2 octaves plus haut sur certaines parties.
Mention honorable quand même, considérant les différences d'architecture entre ces deux générations.
D'ailleurs, un transfert SysEx de la Performance en mémoire TEMP + Patches d'un XV est presque 5 fois plus lourd que celui d'un JV : 68111 octets contre 14795 octets.
A la vitesse du MIDI, la différence est très sensible.
Ce qui est excellent avec le XV, c'est que, pour peut qu'on ait une carte mémoire SmartMedia - on peut y mettre 8 fichiers de banques SysEx convertis au format Roland SVD et ensuite avoir un accès direct à leurs Patches via "Card" puis les boutons "A-H" sans qu'il soit nécessaire de les importer en mémoire utilisateur.
Outre les machines Roland elles-mêmes, l'éditeur XV officiel est capable d'importer/exporter des SVD. Je ne sais pas ce qu'il en est pour celui de SoundTower.
Le format SVD a également été décodé par Marco Stella dans ses éditeurs JV/XP qui sont capables de convertir les formats SysEx / SMF / SVD dans tous les sens :
https://www.oocities.org/mstella/
Ce faisant, on peut donc piocher dans les banques de sons "modernes" pour JV, comme celles de Boris Bunnik (aka Conforce), et bénéficier de la polyphonie et du son hi-fi "large bande" du XV :
https://conforce.gumroad.com/
Ne manquerait plus qu'un convertisseur JD -> XV pour exploiter les autres banques commerciales dédiées au moteur Roland 44k, notamment celle - excellente - de SoundSauca :
https://www.soundsauca.com/sounds/superluminal/
Le XV ne dispose pas de la même structure d'effets que les JD, mais on doit pouvoir adapter, comme le démontre le portage manuel des Patches du JD-800 plus haut.
Saga Musix (le créateur des carte multi-banques MRAM se substituant avantageusement aux M-256 et M-512) met à disposition une moulinette C++ qui fait déjà le boulot entre les SysEx des JD historiques et les versions SVD/SVZ des ZEN-Core (JD-08 ou JD-800 Roland Cloud) :
https://github.com/sagamusix/JDTools
Bref, le socle technique pour convertir les formats Roland BIN/SVD modernes en SysEx/SVD existe déjà (en Javascript, en C++, en Python également je crois).
Ce qui permettrait par exemple d'accéder aux banques commerciales JV/XV du Roland Cloud.
https://www.roland.com/fr/products/rc_jv-1080_signature_sound_set_don_solaris/
https://www.roland.com/fr/products/rc_jv-1080_cinematic_cyber_punk_dual_shaman/
https://www.roland.com/fr/products/rc_jv-1080_wide_screen_ambient_j_scott_g/
https://www.roland.com/fr/products/rc_xv-5080_sky_house/
(si ça intéresse vraiment quelqu'un)
Pour le JD vers XV, il faudrait "juste" se taper le boulot de tâcheron constituant à mettre en correspondances des centaines de paramètres, similaires ou par approximation.
C'est moins vrai pour les Performances multi-timbrales par contre, notamment sur les effets, les drumkits et parfois des erreurs de pitch 2 octaves plus haut sur certaines parties.
Mention honorable quand même, considérant les différences d'architecture entre ces deux générations.
D'ailleurs, un transfert SysEx de la Performance en mémoire TEMP + Patches d'un XV est presque 5 fois plus lourd que celui d'un JV : 68111 octets contre 14795 octets.
A la vitesse du MIDI, la différence est très sensible.
Ce qui est excellent avec le XV, c'est que, pour peut qu'on ait une carte mémoire SmartMedia - on peut y mettre 8 fichiers de banques SysEx convertis au format Roland SVD et ensuite avoir un accès direct à leurs Patches via "Card" puis les boutons "A-H" sans qu'il soit nécessaire de les importer en mémoire utilisateur.
Outre les machines Roland elles-mêmes, l'éditeur XV officiel est capable d'importer/exporter des SVD. Je ne sais pas ce qu'il en est pour celui de SoundTower.
Le format SVD a également été décodé par Marco Stella dans ses éditeurs JV/XP qui sont capables de convertir les formats SysEx / SMF / SVD dans tous les sens :
https://www.oocities.org/mstella/
Ce faisant, on peut donc piocher dans les banques de sons "modernes" pour JV, comme celles de Boris Bunnik (aka Conforce), et bénéficier de la polyphonie et du son hi-fi "large bande" du XV :
https://conforce.gumroad.com/
Ne manquerait plus qu'un convertisseur JD -> XV pour exploiter les autres banques commerciales dédiées au moteur Roland 44k, notamment celle - excellente - de SoundSauca :
https://www.soundsauca.com/sounds/superluminal/
Le XV ne dispose pas de la même structure d'effets que les JD, mais on doit pouvoir adapter, comme le démontre le portage manuel des Patches du JD-800 plus haut.
Saga Musix (le créateur des carte multi-banques MRAM se substituant avantageusement aux M-256 et M-512) met à disposition une moulinette C++ qui fait déjà le boulot entre les SysEx des JD historiques et les versions SVD/SVZ des ZEN-Core (JD-08 ou JD-800 Roland Cloud) :
https://github.com/sagamusix/JDTools
Bref, le socle technique pour convertir les formats Roland BIN/SVD modernes en SysEx/SVD existe déjà (en Javascript, en C++, en Python également je crois).
Ce qui permettrait par exemple d'accéder aux banques commerciales JV/XV du Roland Cloud.
https://www.roland.com/fr/products/rc_jv-1080_signature_sound_set_don_solaris/
https://www.roland.com/fr/products/rc_jv-1080_cinematic_cyber_punk_dual_shaman/
https://www.roland.com/fr/products/rc_jv-1080_wide_screen_ambient_j_scott_g/
https://www.roland.com/fr/products/rc_xv-5080_sky_house/
(si ça intéresse vraiment quelqu'un)
Pour le JD vers XV, il faudrait "juste" se taper le boulot de tâcheron constituant à mettre en correspondances des centaines de paramètres, similaires ou par approximation.
« What is full of redundancy or formula is predictably boring. What is free of all structure or discipline is randomly boring. In between lies art. » (Wendy Carlos)
[ Dernière édition du message le 27/11/2022 à 12:49:53 ]
.: Odon Quelconque :.
10757
Drogué·e à l’AFéine
Je viens de recevoir un ZuluSCSI Mini RP2040 acheté chez les allemands de studio-services.de, dans le but de l'utiliser notamment avec un XV-5080, comme dans les vidéos de l’inénarrable Jürgen Moßgraber
https://zuluscsi.com/
Le packaging est soigné et le produit bien construit.
Après quelques tests, c'est assez facile d'utilisation pour importer des Programs sur un ISO au format Akai ou des banques de WAV pour les utiliser comme WG en mode XV. Idem avec les L-CDX, qui m'ont l'air de très bonne qualité. J'ai moins de succès avec un HD0.hda, mais je ne désespère pas de pouvoir enregistrer des SVD avec des drumkits personnalisés par exemple.
La première impression est que ce n'est pas aussi convivial qu'un Gotek ou qu'un boitier USB IODD/Zalman, puisque toute la configuration se fait sur la SD, si nécessaire via un fichier zuluscsi.ini : https://github.com/ZuluSCSI/ZuluSCSI-firmware/blob/main/zuluscsi.ini
Aucune action sur le contenu - comme changer d'image à la volée - n'est possible une fois que le boitier est connecté au sampler/ROMpler. Il faut également parfois rebooter celui-ci lorsqu'on modifie le contenu de la SD pour qu'il soit actualisé.
En effet, chaque ISO sur la carte SD doit être nommé CDx.iso ou HDx.hda, où x correspond à l'ID SCSI du lecteur/HDD virtuel créé (à concurrence de 7 donc, et en pratique moins si on a d'autres périphériques sur la chaine SCSI). On ne peut pas conserver le nom de fichier ISO original, ce qui est un peu gênant pour s'organiser, même si ensuite, sur le XV, on navigue simplement entre les drives pour changer d'image disque, dont le vrai nom et le contenu s'affichent dans l’arborescence.
Edit : pour les modèles de ZuluSCSI dotés de bouton accessibles (ce qui n'est pas le cas du Mini RP2040), il semble qu'on puisse automatiser le changement d'image après chaque "ejection" virtuelle, via un paramétrage ad-hoc dans le fichier zuluscsi.ini, ce qui permet également d'associée un alias et de conserver des noms plus explicites pour les images disques.
Dommage qu'on ne puisse pas (encore ?) contrôler l'engin et le contenu de la SD depuis le port USB, puisqu'il est caché derrière les machines auxquelles ils est connecté.
Mais c'est un projet qui vit :
https://gearspace.com/board/electronic-music-instruments-and-electronic-music-production/1383000-zulu-scsi-scsi2sd-discussion.html
Concernant le XV, justement, chapeau bas pour la relative simplicité du processus une fois qu'on a compris les bases de la navigation, de la sélection et du chargement (Mark/Mark all + Select = Load). La bascule entre mode le S-7xx (imports Akai/L-CDX) et le mode XV est automatique selon le contenu chargé, et je découvre la qualité sonore du XV sur des formes d'ondes mois appauvries que celles casées au chausse-pied en ROM.
La fluidité de la transposition et du filtre m'ont l'air de toute première qualité.
En tout cas, même si ce n'est pas encore parfait, le Zulu est nettement plus convivial que le vieux SCSI2SD v5.0a qui dort dans un tiroir depuis 7 ans et que j'avoue ne pas encore avoir réussi à utiliser, puisqu'il faut copier les images secteur par secteur sur la SD avec les outils ad-hoc. Trucs de geek dont je commence à me lasser.
https://zuluscsi.com/
Le packaging est soigné et le produit bien construit.
Après quelques tests, c'est assez facile d'utilisation pour importer des Programs sur un ISO au format Akai ou des banques de WAV pour les utiliser comme WG en mode XV. Idem avec les L-CDX, qui m'ont l'air de très bonne qualité. J'ai moins de succès avec un HD0.hda, mais je ne désespère pas de pouvoir enregistrer des SVD avec des drumkits personnalisés par exemple.
La première impression est que ce n'est pas aussi convivial qu'un Gotek ou qu'un boitier USB IODD/Zalman, puisque toute la configuration se fait sur la SD, si nécessaire via un fichier zuluscsi.ini : https://github.com/ZuluSCSI/ZuluSCSI-firmware/blob/main/zuluscsi.ini
Aucune action sur le contenu - comme changer d'image à la volée - n'est possible une fois que le boitier est connecté au sampler/ROMpler. Il faut également parfois rebooter celui-ci lorsqu'on modifie le contenu de la SD pour qu'il soit actualisé.
En effet, chaque ISO sur la carte SD doit être nommé CDx.iso ou HDx.hda, où x correspond à l'ID SCSI du lecteur/HDD virtuel créé (à concurrence de 7 donc, et en pratique moins si on a d'autres périphériques sur la chaine SCSI). On ne peut pas conserver le nom de fichier ISO original, ce qui est un peu gênant pour s'organiser, même si ensuite, sur le XV, on navigue simplement entre les drives pour changer d'image disque, dont le vrai nom et le contenu s'affichent dans l’arborescence.
Edit : pour les modèles de ZuluSCSI dotés de bouton accessibles (ce qui n'est pas le cas du Mini RP2040), il semble qu'on puisse automatiser le changement d'image après chaque "ejection" virtuelle, via un paramétrage ad-hoc dans le fichier zuluscsi.ini, ce qui permet également d'associée un alias et de conserver des noms plus explicites pour les images disques.
#ReinsertAfterEject = 1 # Reinsert next CD image after eject, if multiple images configured.
#EjectButton = 0 # Enable eject by button 1 or 2, or set 0 to disable# If IMG0..IMG9 are specified, they are cycled after each CD eject command.
#IMG0 = FirstCD.iso
#IMG1 = SecondCD.bin
Dommage qu'on ne puisse pas (encore ?) contrôler l'engin et le contenu de la SD depuis le port USB, puisqu'il est caché derrière les machines auxquelles ils est connecté.
Mais c'est un projet qui vit :
https://gearspace.com/board/electronic-music-instruments-and-electronic-music-production/1383000-zulu-scsi-scsi2sd-discussion.html
Concernant le XV, justement, chapeau bas pour la relative simplicité du processus une fois qu'on a compris les bases de la navigation, de la sélection et du chargement (Mark/Mark all + Select = Load). La bascule entre mode le S-7xx (imports Akai/L-CDX) et le mode XV est automatique selon le contenu chargé, et je découvre la qualité sonore du XV sur des formes d'ondes mois appauvries que celles casées au chausse-pied en ROM.
La fluidité de la transposition et du filtre m'ont l'air de toute première qualité.
En tout cas, même si ce n'est pas encore parfait, le Zulu est nettement plus convivial que le vieux SCSI2SD v5.0a qui dort dans un tiroir depuis 7 ans et que j'avoue ne pas encore avoir réussi à utiliser, puisqu'il faut copier les images secteur par secteur sur la SD avec les outils ad-hoc. Trucs de geek dont je commence à me lasser.
« What is full of redundancy or formula is predictably boring. What is free of all structure or discipline is randomly boring. In between lies art. » (Wendy Carlos)
[ Dernière édition du message le 31/12/2023 à 15:47:20 ]
- < Liste des sujets
- Charte
- 1
- 2