Commentaires sur le test : Test du JD-08 de Roland

Allez la petite dernière et je ne vous embête plus

On entend encore mieux le JD-08 sur celui-ci car le morceau est plus calme/planant et sans batterie (avec la "fameuse" disto à la fin sur les PADS).

N'hésitez pas à me dire à l'occasion ce que vous en avez pensé

A bientôt,
GilJ.

Sur la première vidéo, si j'ai bien compris tu séquences un layer chimes du JD-08 avec un canal du keystep, et avec un autre canal tu joues avec un layer pad du même preset ??
Deux canaux pour deux layers du même preset, c'est possible ou je me suis fait embrouiller ?

Merci pour vos sympathiques retours

Oui c'est bien ça : avec le Track3 du KSP je joue en live un son de "strings" et le Track4 séquence le 2ème son du JD-08 (son type "carillon/cloche").
Autrement ce n'est pas "2 canaux pour 2 layers du même preset" mais plutôt 2 canaux pour 2 presets différents. En effet, le JD-08 étant bi-timbral, tu peux jouer avec 2 sons différents (tips pour accéder rapidement aux 2 "parts" : tu appuies sur "NOTE + TONE A" (pour accéder à "Part1") et "NOTE + TONE B" (pour accéder à "Part2").

x

Hors sujet :

Sinon pour le J6, je peux comprendre que tu aies voulu t'en séparer, car assez rapidement on peut avoir l'impression d'avoir fait le tour. Le S-1 à côté est beaucoup plus polyvalent et permet de mieux sculpter le son

Du coup je me demande si c'est possible de faire pareil avec le JD-800 model expansion du Jupiter Xm...

For those interested, finally there is a librarian for the JD-08 out now... I took the time to develop a Windows application which can organize .SVD files (list/find/rename/move/sort patches), and, most importantly, import/export patches and transfer them between .SVD files via copy/paste.

The librarian has been updated to version 2.1 - it can now import patches from banks for the Roland Cloud JD-800 VST plug-in.

// Here is the description by Johannes Schultz:

// This file format is officially terrible.
// It contains two copies of most parameters - the original set of JD-800 parameters with slight modifications
// (such as using signed chars with -50...+50 range instead of 0...100 - fine by me), exclusively used for display in the UI
// - and ADDITIONALLY a set of precomputed parameters, which I assume are the ZenCore equivalents of the original parameters.
// You cannot just create a BIN file containing the display values that can be trivially converted from SysEx format.
// If you do that, all you hear is silence. No, you have to precompute every single ZenCore parameter, and many of them
// don't map linearly. Even better, for some envelopes, every time segment uses a different mapping!
// As a result of this design choice, you could actually create a file with a parameter display that is completely different
// from the sound that is actually generated until you start to wiggle some sliders, at which point the specific precomputed
// value for that slider will be updated.

// All bytes that actually differ between patches have been identified. The only remaining unknown variables are static,
// but not setting them to their expected values will break various features of a patch.
// Unknown variable names contain an offset relative to the first byte in PatchVST::CommonPrecomputed, and the expected byte value in hex.
// For structs that are repeated for all four tones, the offset is always for the first tone.