Est-ce que c'est bô ?

[Francois]

Qu'en pensez-vous ? Je termine le VST3 du KRONOS, puis je passe à l'OASYS. Le gros travail sera sur le NAUTILUS en raison de l'absence de KARMA, donc tout à refaire à ce niveau-là.


PLANCHE_EDITORS.png

[MAO]

ça m'a l'air très clair et ergonomique... deux questions, François: 1) toutes les commandes bénificieront-elles d'un midi learn? 2) pourra-t-on customiser son Kronos Kontrol (en intégrant ses collections de progs/combis, y compris les "officielles" enregistrées auprès de Korg)? Mes deux questions sont moins innocentes qu'il n'y paraît: le Kronos VST3 pourra-t-il être "notre" Kronos transportable dans un ordi et pilotable depuis n'importe quel clavier maître?

[Francois]

Très bonne question MAO, qui appelle une réponse détaillée.

1) Toutes les commandes bénéficieront-elles d'un MIDI learn ?

Oui, toutes ! Le MIDI learn est une fonction native de Ctrlr : dans le panneau en cours d'exécution (autonome ou en VST3), on met un contrôle en mode apprentissage et on envoie un message MIDI depuis son contrôleur. Ce message est alors assigné au contrôle. Cela s'applique à tous les contrôles de Kronos Kontrol (boutons de banques, encodeurs, sliders KARMA, pad X-Y, boutons de l'éditeur) : ce sont des modulateurs Ctrlr standard, et mes scripts Lua se déclenchent exactement comme si tu avais cliqué. Les assignations apprises sont sauvegardées avec le panneau et persistent donc dans le VST3 distribué. Deux précisions : (a) le learn relie le MIDI entrant au panneau, la sortie du panneau vers le Kronos (SysEx) est inchangée ; (b) n'importe quel clavier maître peut donc piloter tout le panneau : changer de banque, tourner les encodeurs, ouvrir l'éditeur, envoyer des objets...

2) Peut-on customiser avec ses propres collections de progs/combis, y compris les "officielles" enregistrées auprès de Korg ?

Oui. Le bouton PCG (qui ne figure pas sur le graphique envoyé car en cours d'installation) ouvre n'importe quel fichier .PCG. Tes banques personnelles sauvegardées depuis le Kronos, tes collections, et les soundwares officiels Korg type KRS (distribués sous forme de fichiers banque .PCG). Tous lisibles par le panneau. Il liste alors les programmes/combis de ce fichier, et SEND transfère l'objet sélectionné vers le tampon d'édition du Kronos pour l'écoute et l'édition. Le panneau peut aussi lire une banque directement depuis le Kronos (Bank Read, SysEx 0x4D). Kronos Kontrol est conçu comme une bibliothèque universelle, et pas seulement fonctionnelle avec le PRELOAD d'usine.

3) Le Kronos VST3 pourra-t-il être "notre" Kronos transportable dans un ordi, pilotable depuis n'importe quel clavier maître ?

La réponse honnête est non, avec une nuance. Le VST3 est une télécommande et un éditeur, pas un synthétiseur : il ne contient aucun moteur Kronos et ne produit aucun son audio. Il n'existe pas de source sonore Kronos dans un ordinateur. Korg n'a jamais sorti de plugin instrument Kronos (même les applis iKronos/iKONTROL de Korg sont des éditeurs/librarians). Ce que le VST3 peut être pleinement c'est ta télécommande Kronos portable, sur un ordinateur portable, dans n'importe quel DAW ou en autonome, pour parcourir tes collections personnelles et officielles, auditionner et éditer sur le Kronos physique, avec n'importe quel clavier maître pilotant le panneau via le MIDI learn. Mais « le Kronos lui-même, sons compris, dans l'ordinateur », cela n'existe pas, et ce panneau ne changera pas cela.

C'est bon ?

[fzero]

Très clairement, les points 1 et 2 sont absolument topissime, je me vois déjà jouer avec mon Konos via Camelot pro et l'interface du pc . Absolument géant dans mon cas, où l'ergonomie pour accèder au Kronos est un peu compliquée au quotidien .

C'est comment l'apprentissage pour le midilearn Francois ? tu bouges un controleur qui envoie un CC et tu l'attribues à une fonction sur le VST ?

[MAO]

ça, cest de la réponse claire, précise et très poussée... merci François... perso, je rêve du jour où Korg intégrera le Red Karma à sa Korg Collection (le pas a été franchi avec les Triton et Trton Extreme, alors pourquoi pas le Karma en version soft?!)... Bien sûr un Kronos soft serait un nirvana... mais déjà, ta version, dans un home studio bâti (comme le mien) autour du Kronos, c'est un plus incommensurable!

[Francois]

Voici le panneau final. Je travaille sur celui de EDITOR. toutes les fonctions sont OK. Juste la partie GUI que je suis en train de terminer.

KRONOS_KONTROL_maquette.png

J'ai mis une bande jaune qui affiche les messages d'exécution, SysEx, erreur Lua... Les écrans bleus affichent les paramètres, mais si cliqués offrent un menu popup qui permet de choisir directement l'objet (programme, style KARMA, GE utilisé...). Les encodeurs de gauche représentent les 8 potards et 8 curseurs qui permettent de piloter les paramètres des moteurs. Ils sont dynamiques et changent selon le type de programme et de moteur utilisé par ce programme. Les boutons sous EDITOR permettent la sélection des banques, leur sauvegarde une fois l'édition terminée. IMPORT et WRITE sont les commandes pour envoyer un patch dans le Kronos en mémoire tampon, jouer le son, puis écrire la modification de la mémoire tampon.

Bref... je pense que mes semaines (littéralement) de cogitation pour définir le GUI, l'aspect user-friendliness et le contrôle complet du Kronos ont fini par payer.

Je suis en version 0.98. Proche de la fin !

[Francois]

C'est comment l'apprentissage pour le midilearn Francois ? tu bouges un controleur qui envoie un CC et tu l'attribues à une fonction sur le VST ?

Si tu poses cette question, d'autres se la posent sans doute aussi. Voici donc ma réponse détaillée, qji permettra aussi de comprendre comment va fonctionner mon VST et CTRLR.

La fonction « MIDI Learn » dans un VST créé avec Ctrlr ne marche pas comme sur un synthé logiciel classique. Ctrlr n’a pas de bouton MIDI Learn universel intégré : c’est surtout ton DAW qui fournit l’apprentissage MIDI. Tu peux quand même assigner des contrôleurs MIDI à tes paramètres Ctrlr, mais ça se joue à deux niveaux : le panel Ctrlr et l’hôte utilisé.

1. Ce que fait Ctrlr

Ctrlr sert à créer des panels : des interfaces de contrôle pour un synthé matériel ou des paramètres MIDI. Tu peux charger ces panels comme un plugin VST/AU dans un DAW. Une fois chargé en VST, chaque contrôle du panel, c'est-à-dire bouton, fader, knob, apparaît dans le DAW comme un paramètre VST automatisable. C’est ce mécanisme qui rend le MIDI Learn possible, mais de façon indirecte.

2. Le MIDI Learn vient du DAW, pas de Ctrlr

Si l'hôte utilisé permet le MIDI Learn, dans ce cas, le paramètre est identifié au sein du plug-in par un « index VST » et associé au numéro de contrôleur MIDI (MIDI CC) de ton choix.

Concrètement :

• Ctrlr n’a pas de MIDI Learn interne dans sa version VST.
• Ton DAW voit les paramètres de Ctrlr comme des paramètres VST normaux, avec un index VST.
• La fonction « MIDI Learn » de ton DAW — Cubase, Ableton Live, Logic, Reaper, etc. — peut alors lier un contrôleur MIDI physique (CC#) à un paramètre Ctrlr précis.
• Ça marche bien pour quelques paramètres en temps réel, mais c’est peu pratique pour un panel avec des centaines de contrôles, comme un patch complet de TX7.

3. Alternative : assigner les CC directement dans le panel Ctrlr

Si tu crées toi-même le panel, donc ce que je suis en train de faire, tu peux préconfigurer des numéros de CC MIDI sur les modulators (les contrôles) directement dans l’éditeur Ctrlr. Certains panels téléchargeables intègrent déjà ces assignations :

« All buttons associated to a Midi CC controller number so you can adjust them from a hardware controller » (Tous les boutons sont associés à un numéro de contrôleur MIDI CC, ce qui vous permet de les régler depuis un contrôleur matériel.) dixit le mode d'emploi.

Dans ce cas, ce n’est pas du « MIDI Learn » dynamique, mais une assignation fixe définie à l’avance. C’est souvent plus fiable pour des panels complexes, parce que chaque contrôle sait déjà quel CC écouter.

4. En résumé pratique

Donc, pour utiliser le MIDI Learn avec un VST Ctrlr : charge le panel dans ton DAW, utilise la fonction « MIDI Learn » de ton DAW sur le paramètre Ctrlr voulu, puis bouge le contrôleur physique. Si on veut que l'utilisateur du panneau puisse obtenir un contrôle plus complet sans passer par l’apprentissage du DAW, il faut alors pré-assigner des CC dans le panneau Ctrlr dès sa conception...

... ce que je réalise avec Kronos Kontrol (qui sera suivi, si vous avez bien suivi, des VST Oasys Omni et Nautilus Navigator ).

J'espère avoir été clair et pas pédant. C'est mon côté prof qui ressort

[kris.sko]

Oui, c'est largement bô.
La sérigraphie paraît harmonieuse, tant en matière de disposition que choix des couleurs. Celle de l'OASYS est très réussie et me rappelle certaines teintes que j'utilisais dans mes ihm.
L'IHM revêt ici toute son importance.
Ah ! pit1n de cours d'ihm...

Question un peu décalée mais non dénuée d'intérêt au vu de l'interface de l'éditeur en ligne que j'ai récemment découverte : les écrans sont "verrouillés" sur une résolution définie ou de type "stretch" à chaque résolution.
En effet l'interface nwe du Nautilus et plutôt fixée, ce qui, sur certaines résolutions, laisse apparaître des ascenceurs verticaux disgrâcieux pouvant masquer "LE" bouton qu'on cherche.
Je suppose que cet aspect a été abordé.

[misterphilgood]

A la question de base : OUI c'est très bô 👍🏻👍🏻👍🏻

[Francois]

les écrans sont "verrouillés" sur une résolution définie ou de type "stretch" à chaque résolution.

C'est une des choses sur lesquelles je me penche en ce moment. Je suis un peu coincé du fait que je dépends de Ctrlr et pour l'instant je n'ai pas de solution pour un redimensionnement automatique. Il faut sans doute que je passe par JUCE, mais ça veut dire beaucoup de délai avant livraison de l'outil, et retard de livraison des outils = retard de publication du livre. Donc à l'heure actuelle, il faut pouvoir afficher le panneau avec un écran capable d'afficher 1500 pixels de large. Avec un laptop comme mon 14 pouces et 1366 pixels, tout le panneau n'est pas visible à l'écran et il faut faire défiiler avec la souris pour voir la partie initialement cachée. Il faut donc un écran de 20 pouces minmimum (1600 pixels) pour tout voir. Je continue les investigations pour voir si une solution de redimensionnement est possible.

D'un autre côté le gus qui fait de la MAO chez lui avec son home studio, normalement il doit avoir un écran d'au moins 20 pouces, et sans doute plus vu les tarifs actuels pour avoir un grand écran chez soi. Donc si je ne trouve pas de solution satisfaisante, je ne vais pas non plus m'inquiéter outre mesure que le panneau soit inaccessible pour certains. Et quand je dis inaccessible, on peut quand même l'utiliser, mais c'est moins confortable que de pouvoir tout voir d'un coup.

[Francois]

O les écrans sont "verrouillés" sur une résolution définie ou de type "stretch" à chaque résolution.

Alors après ma réponse initiale et la cogitation que cela a généré chez moi, je me suis sérieusement penché sur la questions ce soir, car même si 1500 pixels, ça me paraît faisable pour beaucoup, néanmoins, ça me laissait un goût d'inachevé dans la bouche. Du coup, j'en ai fait ma priorité pour voir comment gérer cela. Et j'ai trouvé !

Il m'a fallu me plonger dans Lua et dans Ctrlr pour voir (ça manque d'ailleurs de manuel super bien référencé). Et après quelques heures de recherche, j'ai vu que la solution existait depuis toujours !

Il y a 2 manières de procéder. La première, la plus simple, est d'utiliser une fonction de Ctrlr qui s'appelle uiPanelZoom (ça ne s'invente pas !!!). C'est la fonction native de Ctrlr, que j'aurais dû voir depuis le départ. Comme quoi, on a toujours besoin de l'oeil des autres pour voir ce qu'on ne voit pas soi-même, et ainsi obtenir des idées auxquelles on aurait pas pensé.

Une fois uiPanelZoom digéré, je me suis aperçu que ça restait basique et que c'était manuel. Donc il fallait réfléchir à une manière de rendre ça automatique. Et c'est là que Lua offre la solution. Plutôt que de mettre une fonction de 'manual override' dans le menu Ctrlr (qui néanmoins aurait pu garder en mémoire la résolution choisie), j'utilise le callback luaPanelLoaded lorsque le panneau a fini de se charger et l'adaptation à l'écran de l'utilisateur se fait toute seule. Ce que je testerai bien sûr sur mon laptop de 14 pouces à écran de 1366 pixels.

Voici le script pour Lua pour les programmeurs que ça intéresse (ceux qui veulent développer un panneau avec Ctrlr) :

-- Kronos Kontrol: shrink the 1500 x 414 panel to the screen width
REF_W = 1500
MARGIN = 24 -- window borders

function kkAutoScale()
local disp = Desktop.getInstance():getDisplays():getMainDisplay ()
local w = disp.userArea:getWidth() -- logical px, taskbar excluded
local s = math.min(1.0, (w - MARGIN) / REF_W)
s = math.floor(s * 100 + 0.5) / 100 -- round to 0.01
panel:setProperty("uiPanelZoom", s, false)
console("kkAutoScale: screen " .. w .. " px, zoom " .. s)
end

Et pour le jour, peut-être pas si lointain, où je convertis mon panneau Ctrlr en pure C++ et JUCE, ce callback devient:

auto area = juce::Desktop::getInstance().getDisplays().getPrim aryDisplay()->userArea; // JUCE 6+
float s = juce::jmin (1.0f, (area.getWidth() - 24) / 1500.0f);
mainComponent.setTransform (juce::AffineTransform::scale (s));
setSize (juce::roundToInt (1500 s), juce::roundToInt (414 s));

Et voilà. Encore un exemple de ce que la participation à un forum apporte. Des connaissances, mais surtout des idées ! C'est d'ailleurs un peu ce que je raconte dans l'avant-propos de mon livre.


Bref... merci kris.sko !