CopperLan démystifié

CopperLan at NAMM 2012

2011-12-14T13:58:00.000+01:00

NAMM Show 2012: come to meet us Booth# E13 (search for "CopperLan" in the Interactive Floorplan)

Interactive Floorplan

CopperLan SDK wrapper pour Microsoft .Net

2011-10-28T13:23:00.000+02:00

Un nouveau projet Sourceforge a été créé. Son objectif est de permettre l'utilisation du SDK CopperLan à partir de Microsoft. NET. C'est un énorme travail de remapper chaque classe, chaque méthode, chaque notification à quelque chose de compatible avec l'environnement .Net. J'ai écrit et expérimenté une base pour valider la méthodologie. Pour l'instant, c'est fourni avec une application démo type CopperLan Controller écrit en C#. Le slider peut être utilisé pour contrôler n'importe quel paramètre sur le réseau contrôlé par un message Modifier. Une fonction Learn a été ajoutée pour attribuer facilement le paramètre cible du slider. Cette application peut être testée avec l'application CopperLan Dummy Application. La synchronisation des paramètres est également mise en oeuvre, une fois le slider affecté à un paramètre, vous pouvez modifier sa valeur à partir de n'importe où (plusieurs contrôleurs, le GUI de l'application, le CopperLan Manager, la version iOS du CopperLan Controller/Manager ...) et chaque contrôleur pointant vers ce paramètre est automatiquement synchronisé.

Aide bienvenue pour poursuivre le projet jusqu'à ce que le SDK soit complètement couvert! :-)

https://sourceforge.net/p/copperlandotnet/home/Home

2011-09-22T17:07:00.001+02:00

New channel on YouTube related to CopperLan: http://www.youtube.com/user/zebigbuild

CopperLan Controller

2011-08-12T06:15:00.000+02:00

Le CopperLan Controller est disponible gratuitement dès aujourd'hui sur l'App Store pour iPad, iPhone et iPod Touch!!!

Il est compatible avec toute application supportant le Learning, comme le CopperPlug ou les versions CopperLanisées de Xlis3 et MiniMonsta (qui doivent cependant subir une mise à jour prochainement sur base sur SDK V1.0).

Le CopperLan Manager pour iPad devrait suivre d'ici peu.

Version 1.0 available

2011-07-25T16:12:00.000+02:00

Good news! Check out http://www.copperlan.org/index.php/download and take a look to the version :-) The User Manual (still draft version) tells more about CopperLan Manager news.

Hardware CopperLan

2011-07-12T11:53:00.000+02:00

Nous avons travaillé dur depuis Francfort pour finaliser la version embarquée de CopperLan. Le résultat dépasse nos espérances :-) Les produits Alyseum (CP-MIDI2 et CP-MIDI8) qui seront très prochainement disponibles en magasin offrent des performances époustouflantes tout en garantissant l'intégrité des flux MIDI, même en cas de patching d'enfer. Vous pouvez, spliter, merger, aiguiller au canal MIDI près, en noyant le tout de clocks et autres MTC sans surcharger pour autant le hardware. Il faut dire que celui-ci est à la hauteur; les processeurs utilisés disposent de la mémoire et de la puissance nécessaire pour gérer pleinement l'ensemble des flux CopperLan et leur traduction vers MIDI.

La dernière pierre à l'édifice vient d'être taillée : le Firmware Updater. Cet outil permet la mise à jour du chip CopperLan et jusqu'à 31 firmwares applicatifs (dans le cas de multiples MCU applicatif, c'est le cas de la CP-MIDI8 par exemple) en une fois, et ce à travers le réseau CopperLan lui-même! Les fabricants de matériel bénéficient donc désormais d'une offre CopperLan complète, allant du kit de développement jusqu'à la mise à jour de leur produit. Ils peuvent donc se concentrer sur la finalité de leur produit en s'appuyant sur CopperLan pour tous les aspects communication et maintenance.

voir la page CopperLan sur facebook.

Prix au Musikmesse 2011

2011-04-12T14:07:00.002+02:00

CopperLan a gagné le prix Gearjunkies dans la catégorie MIDI :-))

http://www.gearjunkies.com/news_info.php?news_id=6315

Etat d'avancement

2011-03-16T09:13:00.002+01:00

Petite news concernant l'avancement de CopperLan.

Nous sommes en train de finaliser la version RC2.0 qui est la dernière étape avant la publication de la version commerciale 1.0.

Note: cette version RC2 est actuellement distribuée uniquement aux partenaires qui développent actuellement des produits. La version finale 1.0 sera rendue publique pour le Musikmesse dans 3 semaines (avec un tout nouveau CopperLan Manager redesigné pour être aisément utilisable sur écran tactile!)

Le SDK est stable et existe maintenant pour iOS en plus de MacOS, Windows, et Embedded Linux. La machinerie CopperLan est en train de subir une campagne de test agressive afin de révéler les derniers petits bugs résiduels.

Si vous venez au Musikmesse cette année, ne manquez pas le stand CopperLan (5.1 D61), vous y verrez entre autres comment on peut piloter n'importe quel paramètre de n'importe quel VST présent n'importe où sur le réseau CopperLan à partir d'un iPad ou d'un iPhone, et ce de manière totalement générique! De plus, les premiers produits commerciaux (au pluriel!) seront présentés par leurs constructeurs :-)

N'hésitez pas à me contacter si vous êtes tenté par l'aventure CopperLan! :-)

A bientôt,

Musikmesse 2011

2011-02-02T16:56:00.001+01:00

CopperLan sera exposé au Musiekmesse 2011 à Francfort, stand 5.1 D61.

Venez nous rendre une petite visite si vous êtes de passage par là :-)

Q&A: connexion MIDI

2010-09-23T13:18:00.007+02:00

On m'a posé quelques questions relatives à l'interconnexion de ports MIDI entre deux ordis. Voici le message original (lien vers le forum) et mes réponses:

Je souhaite pour l’instant simplement envoyer des données midi depuis un laptop vers une tour PC. Mon but, piloter Cubase qui est installé sur la tour PC, ceci depuis le laptop à l’aide d’un clavier midi (surtout les commandes start/stop/rec/etc.).
Ce soft m’intéresse car je pourrais transporter le midi sur de plus grande distance grâce à Ethernet.

-Il faut installer le soft sur les 2 machines ?

Oui bien sûr! Le package CopperLan installe un service (deamon sous Mac) qui est en quelque sort le moteur de CopperLan, le driver Ethernet (propre à CopperLan, permet la connexion entre ordis sans devoir configurer d'adresse IP), et le driver MIDI virtuel qui crée 4 ports MIDI -> CopperLan et CopperLan -> MIDI permettant de connecter des softwares MIDI (comme Cubase) au réseau CopperLan.

-Il faut paramétrer le soft sur les 2 machines ?

Lors du premier lancement, le CopperLan Manager suggère de se connecter au réseau physique. Il faut bien entendu accepter et sélectionner l'interface Ethernet qui convient. Les ports MIDI virtuels sont accessibles d'office, mais il est également possible de connecter n'importe quel port MIDI "physique".

-Dans mon logiciel je dois utiliser les entrées/sorties nommées Copperlan Midi ?

Oui, il s'agit là des ports MIDI virtuels.

-Est-il possible d’utiliser Copperlan sur une seule machine pour faire des ports midi internes comme avec Midi Yoke http://www.midiox.com/myoke.htm ?

Tout à fait. Le service (deamon) qui est installé sur l'ordi crée un réseau CopperLan virtuel sur lequel peuvent s'accrocher une multitude d'applications tournant localement. La mise en réseau de plusieurs machines (connexion à un réseau Ethernet classique) étend automatiquement le réseau CopperLan qui est alors constitué de l'assemblage de tous les réseaux virtuels.

-Y a-t-il un tutoriel qui explique comment relier et configurer 2 machines pour y faire transférer du midi (si possible avec des schémas) ?

Nay-seven a posté un message sur son blog (http://nay-seven.com/detail.php?forumid=3&id=1703&s=copperlan) où il explique succinctement comment faire.
En fait, le MIDI est traduit en CopperLan, et non simplement transporté. ça veut dire qu'un contrôleur MIDI peut être utilisé pour piloter nativement des applications purement CopperLan, tout comme un synthé MIDI peut être piloté à partir d'une source CopperLan.
Lors de la traduction MIDI -> CopperLan, les 16 canaux MIDI sont aiguillés vers 16 outputs, une 17ème étant allouée aux messages qui n'ont pas de notion de canal. Symétriquement, la conversion CopperLan -> MIDI écoute sur 17 inputs et reconstruit un flux MIDI à partir des messages reçus.
Cela veut dire qu'il est possible de patcher les flux MIDI au canal près, chaque output étant libre d'émettre vers une ou plusieurs inputs.
Afin de simplifier l'utilisation, le CopperLan Manager dispose d'un bouton MIDI Virtual Cable qui connecte en une opération les 17 output d'un port MIDI vers les 17 inputs d'un autre.

Tutoriel: 3) Ajout d'un paramètre

2010-09-13T11:33:00.001+02:00

Source
Code source (Visual Studio 2008, attention de choisir le profil de compilation "DebugFreeware")

But
Dans ce troisième tutoriel nous allons ajouter un paramètre, et donc activer le mécanisme d'exploration qui permet à un éditeur universel par exemple de récupérer à distance les descriptifs des paramètres. Nous allons également voir comment fonctionne la synchronisation de valeur courante.

Définition du paramètre
La première chose à faire, c'est définir clairement notre paramètre. Nous allons donner la possibilité à notre application de modifier la transposition appliquée aux messages Event. La valeur peut être choisie de manière continue, il ne s'agit pas d'une sélection dans une liste. Le type de message utilisé pour transporter cette valeur est donc un Modifier. Un petit tour sur la section du Wiki qui traite des différents Modifiers nous permet de voir qu'il existe un Modifier standard (0x00A1) prévu exactement pour ça. Afin de faciliter la vie du programmeur, toutes les valeurs standard sont décrites dans des enums, dans le cas présent CPNS::Enums::MOD_Transpose.

Ce Modifier transporte une valeur signée 16 bits que nous allons utiliser pour représenter la transposition sur +/- 2 octaves. Normalement, le modifier est capable de recevoir la valeur exprimée en MKZ16, format 16 bits signé. Cela dit CopperLan exige qu'un modifier supporte au minimum le transport de valeur sous la forme de la position du bouton (de 0x0000 à 0x7FFF) ce qui permet un contrôle à disance à partir de n'importe quelle application. Par mesure de simplification, nous n'allons considérer ici que ce format. La valeur 0x8000 correspond donc à aucune transposition, 0xFFFF à +24 demi-tons, et 0x0001 à -24 demi-tons. La valeur 0x0000 est normalement ignorée ou assimilée à 0x0001.

Réception du Modifier
Nous allons ici ajouter le code nécessaure à OnInput_Message() pour recevoir le modifier CPNS::Enums::MOD_Transpose et donc agir sur le paramètre en question.

    case CPNS::Enums::OT_ModifierMessage:
        {
            // Récupération de l'interface des messages Modifier
            CPNS::IModifierMessage* p = pMsg->GetIModifierMessage();

            // Vérifie si le message est bien celui qu'on attend
            if (p->GetNumber() == CPNS::Enums::MOD_Transpose)
            {
                // Récupère la valeur brute (position du bouton)
                CPT::uint16 wV = pMsg->GetValue().GetRawValue();
                if (wV == 0) wV = 1; // rapporte la valeur 0 à 1
               // Calcul de la valeur signée
                CPT::int16 nV = wV - 0x8000;
                // Mise à l'échelle et stockage dans la variable du paramètre
                m_semiToneOffset = nV * 24 / 0x7FFF;
            }
        }
        break;

Traitement de la transposition
Nous allons appliquer une transposition sur un flux polyphonique, il est donc nécessaire de tenir une trace des notes qui sont actuellement actives. Utilisons un set tels que celui-ci:

std::set   m_CurrentTones;

Et donc, nous allons modifier le code de réception d'un message Event dans OnInput_Message() pour maintenir ce set de données.

    case CPNS::Enums::OT_EventMessage:
        {
            // Récupération de l'interface des messages Event
           CPNS::IEventMessage* p = pMsg->GetIEventMessage();

            // Vérifie si l'information de hauteur de son est disponible
            if (p->IsToneAvailable())
            {
                // Récupération du ton
                CPT::uint16 wTone = p->GetTone();
                // Vérifie si un déclenchement est disponible
                switch (p->GetProfileGate())
                {
                case CPNS::Enums::EGM_GateOn:
                    // Si le ton n'existe pas encore dans la liste, on l'ajoute
                    if (m_CurrentTones.find(wTone) == m_CurrentTones.end())
                    {
                        m_CurrentTones.insert(wTone);
                    }
                    break;
                case CPNS::Enums::EGM_GateOff:
                    // Si le ton existe, on l'enlève
                    if (m_CurrentTones.find(wTone) != m_CurrentTones.end())
                    {
                        m_CurrentTones.erase(wTone);
                    }
                    break;
                }
                // Appliquer la transposition. La résolution est de 256 valeurs par demi-ton
                p->SetTone(wTone + m_semiToneOffset * 256);
            }
            // Send du message (mis à jour)
            m_pOutput->Send(p);
        }
        break;

Alors, forcément, si on modifie la valeur de la transposition, il faut bien entendu "éteindre" les notes avant et les "rallumer" ensuite.

On peut faire ça aisément en modifiant le code de réception de CPNS::Enums::MOD_Transpose comme suit:

Extinction des notes courantes:

                // Création d'un message Event
                CPNS::IEventMessage* pE = m_pCHAI->CreateEventMessage();
                // Extinction des notes actives
                pE->SetProfileGate(CPNS::Enums::EGM_GateOff);
                for (std::set::iterator it = m_CurrentTones.begin(); it != m_CurrentTones.end(); ++it)
                {
                    pE->SetTone(*it + m_semiToneOffset * 256);
                    // Les messages sont envoyés en multipart.
                    // Ils sont empilés pour être empaquetés dans un minimum de messages de transport CopperLan.
                    m_pOutput->Send(pE, false);
                }
                // Flush
                m_pOutput->Flush();

Et réallumage des notes avec la bonne transposition

                pE->SetProfileGate(CPNS::Enums::EGM_GateOn);
                for (std::set::iterator it = m_CurrentTones.begin(); it != m_CurrentTones.end(); ++it)
                {
                    pE->SetTone(*it + m_semiToneOffset * 256);
                    m_pOutput->Send(pE, false);
                }
                m_pOutput->Flush();

                //Release de l'Event
                pE->Release();

Gestion de l'exploration
L'exploration d'un device pour que celui-ci expose ses paramètres est rendu possible par le fait d'activer sa notification d'exploration:

    m_pDevice->SetExplorationNotificationHandler(this);

Il faut dès lors que l'objet qui doit être notifié implémente CPNS::IBaseLocalDevice_ExplorationNotificationHandler.

La méthode OnBaseLocalDevice_RequestProperty() est appelée lorsqu'un device distant souhaite obtenir des infos sur les propriétés d'un device. Voici un exemple d'implémentation:

CPT::boolean Engine::OnBaseLocalDevice_RequestProperty(
    IN CPNS::IBaseLocalDevice * const pNotifiedObject,
    IN CPT::uint16 const wRequestID,
    IN CPT::uint16 const wPropertyID )
{
    switch (wPropertyID)
    {
    case CPNS::Enums::DP_SerialNumber:
        pNotifiedObject->Reply_RequestProperty(wRequestID, "My Serial Number");
        break;
    case CPNS::Enums::DP_FirmwareVersion:
        pNotifiedObject->Reply_RequestProperty(wRequestID, "My Firmware Version");
        break;
    case CPNS::Enums::DP_Description:
        pNotifiedObject->Reply_RequestProperty(wRequestID, "Stream Modifier sample for CopperLan");
        break;
    case CPNS::Enums::DP_ApplicationVersion:
        pNotifiedObject->Reply_RequestProperty(wRequestID, "1.0");
        break;
    }
    return TRUE;
}

Nous entrons maintenant dans le vif du sujet concernant l'exploration des paramètres. La méthode suivante est appelée durant la phase d'énumération des paramètres. L'argument eri contient une combinaison de flags qui indique ce que l'on cherche, c'est à dire le type de message, relatif à quel type de endpoint, est-ce le premier, le suivant, ...

CPT::boolean Engine::OnBaseLocalDevice_RequestInfo(
    IN CPNS::IBaseLocalDevice * const pNotifiedObject,
    IN CPT::uint16 const wRequestID,
    IN CPNS::Enums::ExplorationRequestInfo const eri,
    IN CPT::uint16 const wInputOutputID,
    IN CPT::uint16 const wNumber )
{
    // Vérification que la requête est bien relative à l'Input
    if (((eri & CPNS::Enums::_EIT_RelatedMask_) == CPNS::Enums::_EIT_Input_) &&
        (wInputOutputID == m_pInput->GetInputID()))
    {
        // Vérification du type de requête
        switch (eri)
        {
            // Juste un seul test ici car on a qu'un seul paramètre pour l'instant
        case CPNS::Enums::ERI_FindFirst_InputModifier:
            pNotifiedObject->Reply_RequestInputModifierInfo(
                wRequestID,
                // Numéro du message associé au paramètre
                CPNS::Enums::MOD_Transpose,
                // Index max
                0,
                // Nom
                "Transpose",
                // Position du point médian
                0x8000,
                // Labels
                "-24", "0", "+24",
                // Type de donnée préféré (bien qu'on en tienne pas compte pour l'instant)
                CPNS::Enums::DT_MKZ16,
                // Ordering (pas applicable vu qu'on a qu'un seul paramètre)
                0,
                // Informations de profil complémentaires. Pas applicable ici.
                CPNS::Enums::MP_None);
            return TRUE;
        }
    }
    return FALSE;
}

La prochaine méthode n'est pas strictement nécessaire dans notre exemple car on ne gère pas (encore) le type de donnée MKZ16. Cela dit, dans la description du paramètre on y indique qu'on aime bien ce type de donnée... et donc voici comment répondre à un contrôleur qui souhaite connaître les limites spécifiques à un type de donnée particulier:

CPT::boolean Engine::OnBaseLocalDevice_RequestInputModifierValueRange(
    IN CPNS::IBaseLocalDevice * const pNotifiedObject,
    IN CPT::uint16 const wRequestID,
    IN CPT::uint16 const wInputID,
    IN CPT::uint16 const wModifierNumber,
    IN CPNS::Enums::DataTypes const dataType)
{
    // Vérification de la requête
    if ((wInputID == m_pInput->GetInputID()) &&
        (wModifierNumber == CPNS::Enums::MOD_Transpose) &&
        (dataType == CPNS::Enums::DT_MKZ16))
    {
        pNotifiedObject->Reply_RequestInputModifierValueRange(
            wRequestID,
            // Min
            CPNS::Value(1,TRUE),
            // Mid
            CPNS::Value(0x8000,TRUE),
            // Max
            CPNS::Value(0xFFFF, TRUE));
        return TRUE;
    }
    return FALSE;
}

Maintenant, on doit répondre à une requête d'énumération des items d'un selector. Vu qu'on ne supporte pas de Selector, un simple return FALSE suffit.

CPT::boolean Engine::OnBaseLocalDevice_RequestInputSelectorValueText(
    IN CPNS::IBaseLocalDevice * const pNotifiedObject,
    IN CPT::uint16 const wRequestID,
    IN CPT::uint16 const wInputID,
    IN CPT::uint16 const wSelectorNumber,
    IN CPT::uint16 const wItemIndex)
{
    return FALSE;
}

Un contrôleur peut également souhaiter obtenir la valeur courante d'un paramètre spécifique. Cet exemple fait appel à une méthode _GetTransposeView() qui construit la valeur retournée ainsi que les textes associés. Le fait de délocaliser cette construction dans une méthode a du sens car on en aura aussi besoin un peu plus loin lorsqu'on parlera de la synchro.

CPT::boolean Engine::OnBaseLocalDevice_RequestCurrentValue(
    IN CPNS::IBaseLocalDevice * const pNotifiedObject,
    IN CPT::uint16 const wRequestID,
    IN CPNS::Enums::ExplorationItemTypes const type,
    IN CPT::uint16 const wInputOutputID,
    IN CPT::uint16 const wNumber,
    IN CPT::uint16 const wIndex)
{
    // Check que la requête
    if ((wInputOutputID == m_pInput->GetInputID()) &&
        (type == CPNS::Enums::EIT_InputModifier))
    {
        // Vérification de l'identité du message associé au paramètre
        if ((wNumber == CPNS::Enums::MOD_Transpose) && (wIndex == 0))
        {
            // Création d'une valeur qui représente le paramètre
            CPNS::Value v;
            CPT::UTF8String t;
            CPT::UTF8String u;
            _GetTransposeView(v, t, u);
            // Reply to the request
            pNotifiedObject->Reply_RequestInputModifierCurrentValue(
                wRequestID,
                v, t, u
                );
            return TRUE;
        }
    }
    return FALSE;
}

Et voici la méthode _GetTransposeView():

void Engine::_GetTransposeView(CPNS::Value& outValue, CPT::UTF8String& outText, CPT::UTF8String& outUnit)
{
    // Calcul de la position de bouton qui correspond à la transposition courante
    CPT::uint16 v = 0x8000 + m_semiToneOffset * 0x7FFF / 24;
    // Charge la valeur en mode bipolaire. C'est utile pour insiquer au contrôleur qu'il peut afficher un
    // bouton avec le zéro centré si il en est capable.
    outValue.SetValue(v, TRUE);
    // Création de la représentation textuelle
    outText.Set(CPT::UTF8String::FromInt32(m_semiToneOffset));
    // Unité
    outUnit.Set(" semitone");
}

Et enfin la méthode qui permet d'associer du texte aux index. Etant donné qu'on n'utilise pas d'index, on retourne simplement FALSE.

CPT::boolean Engine::OnBaseLocalDevice_RequestIndexText(
    IN CPNS::IBaseLocalDevice * const pNotifiedObject,
    IN CPT::uint16 const wRequestID,
    IN CPNS::Enums::IndexTextTypes const type,
    IN CPT::uint16 const wInputOutputID,
    IN CPT::uint16 const wNumber,
    IN CPT::uint16 const wIndex)
{
    return FALSE;
}

Et la synchro?
Et bien la synchro, c'est tout simple... Un contrôleur doit recevoir une mise à jour de la valeur courant des paramètres lorsque cette valeur change, ou bien lorsqu'il le demande.

Nous allons donc ajouter l'appel suivant dans OnInput_Message(), juste après avoir modifié m_semiToneOffset:

_RefreshCurrentValue();

et également dans OnInput_QueryCurrentValues():

void Engine::OnInput_QueryCurrentValues( IN CPNS::IInput * const pNotifiedObject, IN CPT::CEndPoint const & source )
{
    _RefreshCurrentValue();
}

Cette méthode _RefreshCurrentValue() utilise la méthode _GetTransposeView() préalablement définie et envoie les données récoltées vers l'Input qui elle-même transmettra l'info vers toutes les Outputs qui y sont connectées.

void Engine::_RefreshCurrentValue()
{
    // Récupération de la valeur courant de la transposition
    CPNS::Value v;
    CPT::UTF8String t;
    CPT::UTF8String u;
    _GetTransposeView(v, t, u);
    // Mise à jour à travers le mécanisme de synchronisation
    m_pInput->RefreshCurrentModifierValue(
        // Identité du message
        CPNS::Enums::MOD_Transpose, 0,
        // Données
        v, t, u
        );
}

Remarque importante concernant la synchronisation
Attention au fait que si on n'y prend garde on peu charger méchamment le réseau CopperLan, ce qui n'a pas ou peu d'impact lorsque ce réseau est constitué d'ordinateurs, mais qui peut devenir problématique si on s'adresse à du hardware qui n'a pas forcément la capacité de traitement d'un ordi.
Par exemple, un contrôleur hardware qui envoie des Modifiers issus d'une entrée analogique doit s'assurer qu'il n'y a pas de bruit sur cette entrée et n'envoyer des messages que lorsque c'est utile.
De même, le système de synchro s'adressant à priori à des êtres humains, ça ne sert à rien de signaler un changement de valeur courante à chaque fois si cela survient plus de 50 fois par seconde...

Conclusion
Et voilà, vous avez maintenant une application capable d'être éditée à partir du CopperLan Manager.

J'anticipe les remarques: la version actuelle du CopperLan Manager ne supporte pas le flag bipolaire, et donc le bouton de réglage de la transposition a son zéro calé à gauche...Ce ne sera plus le cas avec la prochaine version sur laquelle nous travaillons actuellement.

Naissance du petit frère

2010-09-07T17:26:00.001+02:00

Comme promis, une version anglaise de ce blog a vu le jour:

http://copperlan.blogspot.com

Il y a encore un peu de boulot pour ratrapper le retard, mais bon... ;-)

Tutoriel: 2) Transfert d'un message

2010-09-07T13:11:00.001+02:00

Source
Code source (Visual Studio 2008, attention de choisir le profil de compilation "DebugFreeware")

But
Ce deuxième tutoriel a pour but d'ajouter la capacité de réception et d'envoi de message à notre petite application.

Réception
Afin de pouvoir recevoir les messages arrivant sur son Input, l'application doit implémenter l'interface CPNS::IInputNotificationHandler et s'enregistrer auprès de l'Input.

La déclaration de la classe Engine précédemment créée doit donc être enrichie comme suit:

class Engine : protected CPNS::IInput_NotificationHandler

ce qui implique l'implémentation des méthodes suivantes:

protected:
    //====================
    // CPNS::IInput_NotificationHandler
    //====================

    virtual void OnInput_Message(
        IN CPNS::IInput * const pNotifiedObject,
        IN CPNS::IBaseMessage * const pMsg,
        IN CPT::boolean const fRecording
        );

    virtual void OnInput_SourceChange(
        IN CPNS::IInput* const pNotifiedObject,
        IN CPT::CEndPoint const & source,
        IN CPNS::Enums::ISCCauses const cause
        ) {/*NOP*/}

    virtual void OnInput_QueryCurrentValues(
        IN CPNS::IInput * const pNotifiedObject,
        IN CPT::CEndPoint const & source
        ) {/*NOP*/}

La méthode OnInput_Message est appelée lorsqu'un message arrive. Chaque méthode de notification reçoit en premier argument le pointeur de l'objet visé, dans ce cas il s'agit d'une Input. Ce pointeur permet par exemple d'identifier à quelle Input se réfère le message dans le cas d'un device doté de multiples Inputs. L'argument pMsg pointe vers l'interface de base des messages, dont dérivent des interfaces dédiées aux différents types de messages.

ATTENTION: vous verrez dans le diagrame des classes de CopperLan que CPNS::IEventMessage dérive de CPNS::IBaseMessage (par exemple, c'est similaire pour tous les autres messages). Cependant vous ne pouvez pas caster directement le pointeur CPNS::IBaseMessage* en (CPNS::IEventMessage*). Les objets internes implémentent de multiples héritages, et les pointeurs ne correspondent pas. C'est pourquoi CPNS::IBaseMessage propose des méthodes telles que GetIEventMessage() qui ont pour but de retourner le bon pointeur en fonction de l'interface choisie.

L'argument fRecording est utilisé pour indiquer à l'application si le message reçu fait partie d'un flux d'enregistrement. Cet aspect sera couvert plus tard dans un autre tutoriel.

Le code à implémenter dans CPNS::OnInput_Message() est donc la plupart du temps calqué sur le schéma suivant:

    switch (pMsg->GetObjectType())
    {
    case CPNS::Enums::OT_EventMessage:
        {
            // Récupération de l'interface des messages Event
            CPNS::IEventMessage* p = pMsg->GetIEventMessage();

            // ... ici on fait quelque chose avec le message

            // Attention: p pointe sur une interface particulière de pMsg,
            // il ne faut donc pas le détruire, la durée de vie de pMsg étant
            // gérée par le CHAI et normalement limitée au temps d'exécution
            // de OnInput_Message().
            // Il est cependant possible de maintenir le message dans l'application
            // en vue d'un traitement ultérieur, mais il faut alors faire un
            // Acquire() dessus afin d'éviter sa destruction au retour de
            // OnInput_Message(), et surtout ne pas oublier de faire un
            // Release() une fois qu'on en a plus besoin.
        }
        break;
    case CPNS::Enums::OT_ModifierMessage:
        {
            // Récupération de l'interface des messages Modifier
            CPNS::IModifierMessage* p = pMsg->GetIModifierMessage();
            // ...... idem que pour l'Event...
        }
        break;
    // ... autres cases pour les autres types de messages...
    }

Les autres métodes OnInput_SourceChange() et OnInput_QueryCurrentValues() ne sont pas utilisées pour l'instant. Elles seront expliquées plus tard dans d'autres tutoriels.

Dernière petite chose, les méthodes de notification ne seront pas appelées tant que l'objet qui implémente le notification handler n'est pas enregistré auprès de l'Input... Il faut donc ajouter le code suivant dans la méthode Engine::Initialize(), à la suite de la création de l'Input:

    // Enregistre l'instance courante comme étant un notification handler pour l'Input
    m_pInput->RegisterNotificationHandler(this);

Emission
Nous avons là une application capable de recevoir des messages. L'étape suivante est de transmettre directement les messages vers l'Output. Bon, évidemment ça n'apporte pas de valeur ajoutée, mais ça permet déjà de comprendre le mécanisme de réception/émission des messages :-)

La manière d'envoyer un message est très compliquée. Il faut juste appeler la méthode Send() de l'Output :-D

Et donc, dans le code de OnInput_Message() ci-dessus, il suffit simplement d'ajouter la ligne suivante derrière le GetI***Message(), à la place du commentaire "// ... ici on fait quelque chose avec le message":

m_pOutput->Send(p);

Modification du message
Histoire d'agrémenter un peu notre programme, nous allons maintenant appliquer une simple transposition aux messages Event.

Les messages Event sont ceux qui transportent l'aspect musical de CopperLan. On peut comparer ce type de message au Note On/Off du MIDI, et c'est d'ailleurs sous la forme de messages Event que ces commandes MIDI sont traduites.

En CopperLan, un message Event peut transporter de façon dissociée le Gating (On, Off, et d'autres) et le Tone (hauteur du son exprimée en 256ème de demi-ton).

La transposition s'appliquant uniquement au Tone, nous devons vérifier que le message Event reçu contient bien cette information. Si c'est le cas, nous allons appliquer une transposition de 4 demi-tons vers le haut, et enfin envoyer le message. Tout se fait simplement en remplaçant dans le cas des messages Event le m_pOutput->Send(p); par ceci:

// Vérifie que le Tone est disponible
    if (p->IsToneAvailable())
    {
      // Récupération du Tone contenu initialement dans le message
      CPT::uint16 wTone = p->GetTone();
      // Application d'une transposition
      p->SetTone(wTone + 4 * 256);
}
    // Envoi du message
    m_pOutput->Send(p);
Voilà qui est fait. Le petit programme (disponible en téléchargement au début de cet article) permet désormais d'être destinataire d'une source (MIDI par exemple), de se voir attribuer des destinations, et d'appliquer une transposition au messages Event qui le traversent.

Le tutoriel suivant expliquera comment on peut y ajouter un paramètre pour régler la valeur de la transposition.

Tutoriel: 1) Les bases

2010-09-06T07:03:00.006+02:00

Voici le premier d'une série d'articles qui a pour but de vous aider à écrire votre première application CopperLan.

Prérequis

Il est bien entendu nécessaire que la dernière version de CopperLan disponible ici soit installée sur votre ordinateur.
Nous allons nous appuyer sur le SDK Freeware, téléchargeable après un simple enregistrement sur le Wiki de CopperLan.org.

Source
Code source (Visual Studio 2008, attention de choisir le profil de compilation "DebugFreeware")

But
Le but de ce premier module est d'écrire une application console qui déclare un device sur le réseau CopperLan. Cependant il s'inscrit dans le but global du tutoriel qui est une application de type boîte noire, donc sans interecation directe avec l'utilisateur, qui permet d'appliquer des modifications à un flux de messages CopperLan. L'idée étant de pouvoir disposer de petites applications qui peuvent tourner sur n'importe quelle machine du réseau, éditables à distances, et qui peuvent venir s'insérer par exemple entre un clavier et un synthé et appliquer des effets tels que transposition, retard, arpèges, ...

Classe Engine
Cette classe est le moteur de l'application. Il suffit de l'instancier dans le main() et d'en appeler la méthode Initialize() pour que l'application tourne. Un appel à Terminate permet de quitter proprement.

Voici donc le corps principal du programme:

Engine g_Engine;

int main(int argc, char* argv[]) {
//Initialisation
    if (g_Engine.Initialize())
    {
        printf("Program running... Press any key to exit\n");
        getchar();
        // Terminaison
        g_Engine.Terminate();
    }
    else
        printf("aborting...\n");
}

Nous allons maintenant définir le prototype de la class Engine, et donc faire appel à des resources CopperLan. Etant donné que cet example se base sur le SDK Freeware il convient de faire l'include suivant en s'assurant que le chemin d'accès à ce fichier a été défini globalement pour le projet, ou dans les paramètres par défaut de votre environnement de développement:

#include "CHAIFreeware_RC1.h"

class Engine
{
public:
//====================
// Constructeur/Destructeur
//====================
    Engine();
    ~Engine();
//====================
// Méthodes publiques
//====================
    bool Initialize();
    void Terminate();
private:
//====================
// Membres
//====================
    CPNS::ICHAI* m_pCHAI;
    CPNS::IBaseLocalDevice* m_pDevice;
    CPNS::IInput* m_pInput;
    CPNS::IOutput* m_pOutput;
};

L'implémentation du constructeur/destructeur est classique:

Engine::Engine() :
    m_pCHAI(NULL),
    m_pDevice(NULL),
    m_pInput(NULL),
    m_pOutput(NULL)
{
}

Engine::~Engine()
{
}

La méthode Initialize() crée une instance du CHAI, un Device, une Input et une Output.

bool Engine::Initialize()
{
    // Création d'une instance du CHAI, la clé du freeware permet d'identifier celui-ci.
    // Elle contient l'identité du freeware et le nom de l'application.
    // Vous pouvez obtenir gratuitement une nouvelle clé pour votre freeware sur simple
    // demande.
    m_pCHAI = CPNS::Factory::CreateCHAI("@7ZSwec9Pk@Yg5vjw1hQekXiuih8wWn2&3&@");

    // Ajout d'un device générique.
    // Ce device est déclaré faisant partie de la catégorie de devices de Performance,
    // c'est à dire qu'il participe à la création musicale.
    // Attention! le pointeur retourné est relatif à un objet maintenu par le CHAI (il
    // dérive de IObject). Il est interdit de faire un delete sur un tel objet.
    // La suppression d'un Device se fait via la méhode RemoveLocalDevice du CHAI.
    m_pDevice = m_pCHAI->AddLocalDevice(
        CPNS::Enums::DC_Performance);

    if (!m_pDevice) return false;

    // Ajout d'une Input au device.
// Les paramètres sont:
    // 1) une combinaison des capacités de l'Input, ici elle est capable de recevoir des
    //     messages Event, Modifier et Selector;
    // 2) le nom de l'Input
    m_pInput = m_pDevice->AddInput(
        CPNS::Enums::IOC_Msg_Event | CPNS::Enums::IOC_Msg_Modifier | CPNS::Enums::IOC_Msg_Selector,
        "Input");

    if (!m_pInput) return false;

    // Ajout d'une Output au Device
// Les paramètres sont:
    // 1) une combinaison des capacités de l'Output, ici elle est capable d'émettre des
    //     messages Event, Modifier et Selector;
    // 2) le nom de l'Output
    m_pOutput = m_pDevice->AddOutput(
        CPNS::Enums::IOC_Msg_Modifier | CPNS::Enums::IOC_Msg_Event | CPNS::Enums::IOC_Msg_Selector,
        "Output");

    if (!m_pOutput) return false;

    // A ce stade, le Device n'est pas encore visible sur le réseau CopperLan.
    // Lors de la connexion du CHAI, un test est réalisé pour vérifier si il n'y a pas un
    // conflit d'identité. Ceci peut arriver si on exécute plusieurs fois le même
    // programme en même temps. Dans ce cas, CopperLan attribue automatiquement
    // un nouveau DuplicateNumber afin de résoudre le conflit.

    bool fConnected = (m_pCHAI->Connect() == CPNS::Enums::ERR_None);

    return fConnected;
}

La terminaison de l'application consiste simplement à libérer les resources consommées préalablement.

void Engine::Terminate()
{
    // Déconnexion du CHAI
    m_pCHAI->Disconnect();
    // Destruction du CHAI et de toutes les resources associées
    m_pCHAI->Destroy();
    m_pCHAI = NULL;
    m_pDevice = NULL;
    m_pInput = NULL;
    m_pOutput = NULL;
}

Voilà, vous disposez maintenant d'une application qui déclare un Device, une Input et une Output sur le réseau. A ce stade, il est possible de lui envoyer des messages et de lui ajouter des destinations, mais attention, rien ne se passera étant donné que nous ne traitons pas encore les messages qui arrivent et nous n'en envoyons pas encore!!!

Dans le prochain article nous verrons donc comment recevoir un message à partir d'une Input, le décoder et le modifier, puis le transmettre à une Output.

Comment installer CopperLan sur son ordinateur?

2010-07-06T13:57:00.005+02:00

C'est très simple. Suivez ce lien vers le site www.copperlan.org, puis cliquez sur l'image Download, choisissez votre plateforme et téléchargez le package d'installation.
Il ne reste plus ensuite qu'à exécuter ce programme, et CopperLan est désormais présent sur votre ordinateur.

Que puis-je faire ensuite?
Sans rien installer d'autre, vous disposez désormais d'une énorme patch bay permettant de connecter des flux MIDI entre plusieurs ordinateurs au canal près!!! :-)
Lors de l'installation de CopperLan, 4 ports MIDI vers CopperLan et CopperLan vers MIDI ont été installés. Ces ports MIDI virtuels permettent à vos applications existantes de se raccorder au réseau CopperLan. Il suffit d'y sélectionner un de ces ports au lieu de vos ports MIDI classiques. Il devient alors possible de faire communiquer diverses applications localisées sur des ordinateurs différents (qu'ils soient Mac ou PC) à travers un câble MIDI virtuel.
Pour ce faire, vous avez besoin d'établir une connexion entre les ports MIDI virtuels. C'est entre autres une des tâches du CopperLan Manager, une application qui permet de gérer le réseau CopperLan et d'agir sur les Devices qui s'y trouvent.
Lors du premier lancement du CopperLan Manager, il vous suggère de vous connecter au réseau Ethernet. En effet, CopperLan peut parfaitement fonctionner localement, en interne dans votre ordinateur uniquement. Afin de communiquer avec le monde extérieur il est nécessaire de choisir l'interface réseau que vous souhaitez utiliser.
Rendez-vous ensuite dans l'onglet "Connections", vous y trouverez un device qui porte le nom de votre ordinateur. Cliquez sur le petit bouton d'extension qui s'y trouve afin d'ouvrir ce device et de voir apparaître les ports MIDI vers CopperLan qu'il contient.
Lorsque vous sélectionnez un device relatif à un de ces ports, vous voyez apparaître une liste de toutes ses Outputs, il y en a une par canal MIDI plus une pour les commandes non relatives à un canal. Chaque Output peut être aiguillée vers une ou plusieurs Inputs appartenant à n'importe quel Device du réseau... Vous pouvez alors aiguiller chaque canal MIDI individuellement, ou bien établir une câble MIDI virtuel.

Et mes ports MIDI habituels?
Et bien le CopperLan Manager permet également de prendre en charge tous les ports MIDI standards!
Vos ports MIDI existants peuvent être accrochés au réseau CopperLan simplement en les activant dans les Settings. Ils deviennent alors visibles derrière le device de votre ordinateur, tout comme les ports MIDI virtuels.

En conclusion
Rien que par le fait d'installer CopperLan sur vos ordinateurs, il devient possible de jouer du clavier ou de manipuler un banal contrôleur MIDI sur un ordinateur et d'envoyer ce flux MIDI vers un ou plusieurs programmes tournant sur d'autres ordinateurs.

Imaginez ce que ça pourra donner dès que vous utiliserez des programmes et du hardware nativement CopperLan :-)

Un Device? qu'est-ce que c'est?

2010-06-23T09:22:00.001+02:00

Comme nous l'avons vu dans Qu'est-ce qu'une Application CopperLan, une Application utilise un CHAI pour accéder aux ressources du réseau. Mais ce n'est pas pour autant qu'elle est visible sur ce réseau. En effet, certaines applications peuvent se contenter d'observer ce qui s'y passe ou de contrôler à distance l'une ou l'autre chose sans pour autant devoir s'exposer.

En fait, une Application sera visible seulement si elle déclare un ou plusieurs Device. Généralement, une Application crée un Device racine qui la représente, et derrière lequel une arborescence de Sub-Devices peut être créée pour distinguer les différentes sous-fonctionnalités de l'application. Par exemple, dans un synthé, on peut imaginer la structure suivante:

Synthé (A)

Clavier & panneau de contrôle (B)
Générateur sonore (C)

Le Device A est le device principal, B et C représentent un découpage des deux fonctionnalités principales du synthé qui dès lors peuvent être accessibles distinctement à partir du réseau. Initialement, un lien fort existe entre B et C (on peut l'assimiler au Local ON bien connu), mais CopperLan permet très simplement d'y insérer l'un ou l'autre Device (un arpégiateur par exemple) quel que soit l'emplacement physique et logique où celui-ci se trouve. Mais n'allons pas trop vite, nous verrons ça plus tard.

Chaque Device possède une identité unique sur le réseau, le DeviceID. Il s'agit d'une information composite 64 bits construite à partir de 4 mots de 16bits: BrandID, ModelID, DuplicateNumber et ModuleID.

Le BrandID est un numéro attribué à chaque fabricant permettant d'identifier l'origine d'un Device.
Le ModelID est défini par le fabricant et permet d'identifier la nature d'un device (en association éventuelle avec le ModuleID)
Le DuplicateNumber est un numéro permettant de distinguer plusieurs instances d'un même Device. Ce numéro est généralement attribué automatiquement lorsqu'un conflit d'identité apparaît sur le réseau. Cela dit, il est possible de le fixer lorsqu'on fige la topologie d'un réseau.
Le ModuleID permet de distinguer les Sub-Devices. Ce numéro est attribué par l'Application lorsqu'elle crée une arborescence de Devices. Les sous-devices prennent alors la même identité que le device de tête sauf que leur ModuleID sera différent de 0 (réservée au device de tête). Une application qui expose un seul device attribuera toujours 0 au ModuleID de ce Device. Si une arborescence de Devices est créée, la racine de l'arbre aura toujours un ModuleID à 0 et les sous-devices auront toujours un ModuleID différent de 0. Dans ce dernier cas, c'est l'association (ModelID, ModuleID) qui permet d'identifier clairement la nature du Device.

Un Device est également marqué par ses Device Capabilities. Il s'agit d'un ensemble de flags qui permettent d'identifier d'un coup d'oeil le domaine d'application du device (instrument, mix, lumière, sono...) ainsi que ses capacités particulières (supporte le snapshot, convertisseur MIDI, éditable...). Ces Device Capabilities sont très utiles lorsqu'on effectue des recherches sur le réseau pour trouver les Devices qui correspondent à certains choix.

En résumé, on appelle Device une entité logique qui représente une fonctionnalité propre à une application. Chaque Device est identifié de manière unique grâce à son DeviceID, et possède des Device Capabilities permettant de filtrer aisément le contenu du réseau.

Nous verrons dans le prochain article comment communiquent ces Devices entre eux.

Qu’est-ce qu’une Application CopperLan ?

2010-06-17T09:05:00.004+02:00

Une Application peut être un programme tournant sur un PC ou un Mac, ou embarquée dans du hardware spécifique. Dans tous les cas, l’Application est intégrée au réseau CopperLan virtuel (VNM) de sa machine hôte grâce au CopperLan Host Application Interface (CHAI).

Dans le cas d’Application pour ordinateur, le CHAI est disponible sous la forme d’une librairie C++ qui offre une représentation tout-objet du réseau CopperLan. Le CHAI prend en charge la gestion du réseau et toutes les interactions inter-applicatives qui ne nécessitent pas d’autres informations que celles dont le CHAI dispose. Le développeur d’Application peut donc se concentrer sur son business en utilisant les interfaces de haut niveau du CHAI sans devoir se soucier de la bonne marche du reste du réseau.

Pour les Applications embarquées dans du hardware nous avons mis en place le CHAILink, un moyen de télécommander un CHAI distant. Dans ce cas, le développeur dispose du code source du CHAILink Client qui reflète toutes les possibilités du CHAI dans un langage totalement portable (le C). Le CHAILink Client prend en charge le protocole CHAILink qui permet de discuter avec le CHAILink Server et son CHAI associé qui se situent dans ce cas au sein du VNM. La communication physique entre le CHAILink Client et le CHAILink Server est à charge du développeur et peut prendre n’importe quelle forme à partir du moment où une communication bidirectionnelle est possible. Une Application CopperLan peut ainsi par exemple tourner dans une clé USB dotée d’un tout petit micro-contrôleur 8 bits, toute la puissance nécessaire au CHAI étant consommée dans la Machine hôte (généralement un ordi).

En résumé, toute Application a besoin d’un CHAI pour accéder au réseau CopperLan, c’est pas beaucoup plus compliqué que ça :-)

Un réseau en grappe

2010-06-15T07:59:00.007+02:00

Un réseau CopperLan a pour but d’interconnecter différentes choses qui peuvent être virtuelles ou physiques.

Selon une approche top-down classique, commençons par l’élément de base sans quoi rien ne serait possible.

Une Machine est un élément hardware du réseau CopperLan qui peut héberger une ou plusieurs Applications. Les Machines discutent entre elle à travers un réseau Ethernet en utilisant un protocole dédié : le Protocole CopperLan (Ethertype IEEE 0x8927). C’est le seul protocole qui est strictement nécessaire pour constituer un réseau CopperLan, tous les autres (TCPIP, UDP, ...) peuvent être désactivés sauf bien entendu si vous en avez besoin pour d’autres transports (audio ou accès internet par exemple).

Chaque Machine abrite un réseau virtuel CopperLan (VNM) lui permettant d’héberger plusieurs Applications CopperLan de manière autonome. Un ordinateur peut ainsi mettre en relation plusieurs programmes CopperLan, du hardware CopperLan branché en USB, Firewire ou autre, des ports MIDI physiques ou virtuels. La connexion de cet ordinateur à d’autres via Ethernet permet d’étendre le réseau CopperLan, chaque Application pouvant alors échanger des informations avec n’importe quelle autre, quel que soit sa localisation physique.

En bref, il suffit d’installer le package CopperLan pour transformer n’importe quel ordinateur Windows ou Mac en Machine. D’autre part, tout autre équipement doté d’un connecteur Ethernet et hébergeant un VNM est également une Machine : pédale de guitariste, console de mix, surface de contrôle, instrument, ampli, projecteur…

Juste pour donner une petite idée...

2010-06-12T16:51:00.002+02:00

Voici quelques informations en vrac. Ce n'est pas très structuré, mais CopperLan est tellement vaste et a un tel potentiel que c'est difficile de le décrire succinctement. De plus le risque est grand de laisser sous-entendre une complexité qui n'existe pas…
Tout ce qui est décrit ci-dessous est soit géré automatiquement, soit ne nécessite que peut d'effort de programmation.

Et donc, CopperLan est une technologie de mise en réseau d'équipements et d'applications conçu sur base des principes suivants:
- le réseau peut passer à travers n'importe quel support physique (USB, Firewire, Ethernet...)
- les performances permettent l'exploitation temps réel. Elles dépendent cependant des capacités du réseau physique et du hardware connecté.
- l'utilisateur est libéré de tout problème de configuration. Par exemple, les équipements USB ne nécessitent pas de driver dédié (un driver générique est fourni avec le package CopperLan), et la connexion Ethernet ne nécessite pas d'adresse IP (CopperLan a son propre Ethertype IEEE 0x8927, il est donc possible de désactiver tous les protocoles réseau... excepté CopperLan bien sûr)
- le réseau est totalement décentralisé, son intelligence est distribuée sur toutes les machines. Il n’y a pas de maître de sorte que la perte d’une machine ne fera jamais tomber l’entièreté des applications (autres que celles tournant sur la machine perdue évidemment).
- une application (terme utilisé pour décrire un hardware ou software CopperLan) doit pouvoir être déplacée sans impact sur son adressage
- le débranchement accidentel d'un hardware ne perturbe pas le réseau, tout comme son rebranchement.
- une application est déclarée automatiquement lors de son arrivée sur le réseau de sorte à pouvoir être exploitée par d'autres. Cette déclaration contient des informations telles que l'identité propre (utile pour les applications en bundle), le domaine d'application (musical, lumière, audio, ...), ses capacités spécifiques, etc...
- l’établissement de connexion est assisté par CopperLan qui permet de filtrer les destinations potentielles compatibles avec la source indiquée. Ainsi on peut n’afficher que les instruments lorsqu’on cherche une destination pour un clavier, que les mixeurs pour un certain contrôleur, que les plugins pour un autre, etc…
- transport de message normalisés et/ou customisés de type numérique à haute résolution, texte ou bloc binaire; mais aussi des horloges à résolutions multiples, des signaux, des messages d'alerte...
- le réseau supporte l’envoi de message direct, multicast ou broadcast.
- plusieurs messages peuvent être encapsulés dans une transaction afin de permettre l'application instantanée de multiples paramètres.
- l'automation est bien entendu largement supportée
- les options de recording permettent aisément à une application d'espionner une source pour ensuite se faire passer pour elle.
- une source est avertie lorsqu'une destination lui est attribuée ou supprimée. De même une destination est avertie lorsqu'une source est connectée ou déconnectée. Bien que les connexions puissent être gérées de n’importe où, une application peut donc toujours contrôler avec qui elle parle.
- toute entité exposée sur le réseau peut être masquée à l’utilisateur si nécessaire (il est parfois utile de masquer un point d’accès privé par exemple)
- afin de garantir une compatibilité avec l'existant, le MIDI est traduit en CopperLan pour pouvoir attaquer nativement des applications CopperLan, et inversément CopperLan peut être traduit en MIDI moyennant une perte de résolution.
- chaque application peut exposer ses paramètres de sorte à pouvoir permettre une découverte dynamique et d’être éditable à partir de n’importe où sans connaissance préalable de sa topologie. Editable veut dire qu'une application tierce peut modifier ses paramètres mais aussi être avertie des changement de valeur et répliquer la valeur courante sur son interface.
- chaque application peut également échanger des blocs binaires (dont elle maîtrise le format) avec des systèmes de collecte et restauration de setup. Ceci permet une sauvegarde centralisée de tous les settings de l’ensemble du réseau.
- un hardware léger n'ayant aucun bouton ou afficheur est toutefois totalement éditable à travers le réseau. On peut ainsi aisément réaliser un plugins sous forme d'une boîte noire hardware juste dotée d'un connecteur Ethernet qui s'insère dans un flux CopperLan suite au simple fait d'être connecté au réseau...

Restons-en là pour aujourd'hui... mais il y a encore tellement de choses à dire :-)

Mise en appétit

2010-06-09T19:11:00.002+02:00

Imaginez...

Un studio personnel où vous pouvez sortir de votre ordi et interconnecter librement toute application ou matériel, quel que soit et indépendamment de l'endroit où il est physiquement situé...

Imaginez une surface de contrôle USB que vous pouvez déplacer à volonté d'un PC à un Mac ou même sur le module d'une batterie électronique... qui reprend son rôle sans devoir reconfigurer quoi que ce soit...

Imaginez un Mac, un PC et du hardware interconnectés en Ethernet directement sortis de la boîte, sans devoir configurer une quelconque adresse IP...

Imaginez qu'en branchant un contrôleur quelque part une application située ailleurs détecte instantanément ce nouvel arrivant et propose de l'utiliser...

Imaginez un instrument de musique exotique générant des messages haute résolution à partir de multiples capteurs, reconnu instantanément, sans besoin d'installer un quelconque driver, directement prêt à l'emploi et compatible nativement avec toutes vos sources sonores...

Imaginez un mariage en douceur entre synthés/contrôleurs analogiques et le monde tout numérique...

Imaginez les autres mises en appétit qui suivront prochainement...

Bienvenue!

2010-06-09T14:37:00.002+02:00

CopperLan est un nouveau moyen de communication plug&play, sans configuration, temps réel et supportant de multiples transports physiques. Initialement dédié à l'industrie de la musique, CopperLan est toutefois capable de réunir dans un même réseau instruments, consoles audio pro, lumière, ou tout autre équipement.

Cela fait plusieurs années maintenant que je travaille au développement de CopperLan en tant que chef de projet chez ICT7. Notre bébé arrivant à terme, le temps est maintenant venu de faire la lumière sur ce qu'est réellement CopperLan.

Ce blog a pour but de le démystifier, démontrer la simplicité d'implémentation et l'étendue des capacités de CopperLan. Nous y discuterons technique, développement, mais nous pourrons aussi analyser des cas concrets de mise en oeuvre.

J'espère que vous trouverez ici les réponses à vos questions, dans le cas contraire n'hésitez pas à me les soumettre!

Phil.