Thanks Be.,

this new way would be a great improvement over the current situation.  If you
don't mind, I'd share some additional thoughts and an alternative way to the
problem.

In the current state, I generate the mapping script with an XML template engine
from the button definitions in JS, to solve the issue of duplication. Needless
to say a purely JS mapping would be awesome. However, since object notation
makes it possible to write things pretty declaratively in JS, I wonder if we
could leverage this for the mappings, so simple things remain simple for the
(non/rookie) programmers even without XML.  What I am thinking about is turning
the current script interface into a description that resembles the XML e.g.:

NovationLaunchpadMK2 = {
  info: {
    name: 'Novation Launchpad-MK2',
    author: 'Midiparse',
    description: 'Novation Launchpad mapping for Mixxx',
    forums: 'https://github.com/szdavid92/mixxx-launchpad'
  },
  controller: {
    controls: [{
      group: '[Master]',
      status: 0xB0,
      midino: 0x68,
      key: 'NovationLaunchpadMK2.myCallback', // or the below version is even 
better
    }, {
      group: '[Master]',
      status: 0xB0,
      midino: 0x69,
      listener: myCallback,
    }]
  },
  // and so on, your custom things here
  myCallback: function () {},
  init: function () {}
}

I think, this definition would remain still pretty understandable, and also
most programmers would not need to resort to the imperative API in
most cases.

Seems a bit irrelevant, but with regards to the engine.connectControl method,
afaik currently you can only disconnect functions referred to by name, not
function objects. It would be better to be able to disconnect function objects
too, and I don't think that the method signature has to be changed (by
introducing e.g. an id), because the function objects could be simply tested
against reference equality. Of course this can result in hard-to-understand
situations typically when used in conjuction with bind, apply, call and such
things that return new functions.

var myFun = function () { };
engine.connectControl('[Channel1]', 'play', myFun);
engine.connectControl('[Channel1]', 'play', myFun, true);

Now, rethinking the proposed API for connecting MIDI signals to handlers
in this light, why not keep the API uniform and provide the same interface?
Instead of returning an object that can be disconnected with an instance
method, we could have one analogous to engine.connectControl

var myFun = function () { };
midi.connectControl(0xB0, 0x69, myFun);
midi.connectControl(0xB0, 0x69, myFun, true);

What do you think?

Stay awesome,

David

> On 21 Mar 2017, at 17:01, Daniel Schürmann <dasch...@mixxx.org> wrote:
> 
> Hi Be,
> 
> Thank you for the design draft.
> It looks very solid and should be already very useful.
> 
> I am just wondering how this interacts with the mapping GUI.
> Use case: A non programing experienced user wants to reassign the deck gain 
> knob to the aux volume.
> He can probably do it easy in one direction. JS -> XML how can he revert it, 
> or swap two JS mapped functions?
> A solution my also include "learning jog wheels".
> 
> 
> An other issue is that we final loose the single point of entry for tracking 
> the mappings.
> Today a user can lookup the xml file to track the midi signals. It does not 
> require a physical controller nor
> a running Mixxx only GitHub access.
> Maybe we can add an auto generated xml file or other self-documentation to 
> issue this uses case.
> 
> Kind regards,
> 
> Daniel
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 2017-03-16 8:18 GMT+01:00 Be <b...@gmx.com <mailto:b...@gmx.com>>:
> Hi,
> I have started planning how to implement a way to register MIDI input
> callbacks from JavaScript so we can write mappings entirely in
> JavaScript without the hassles of the XML format. I'm not sure when I'll
> get around to implementing this, but it won't be in 2.1.
> 
> http://mixxx.org/wiki/doku.php/registering_midi_input_handlers_from_javascript
>  
> <http://mixxx.org/wiki/doku.php/registering_midi_input_handlers_from_javascript>
> 
> Please reply with your thoughts and questions.
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> <http://sdm.link/slashdot>
> _______________________________________________
> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
> http://mixxx.org <http://mixxx.org/>
> 
> 
> Mixxx-devel mailing list
> Mixxx-devel@lists.sourceforge.net <mailto:Mixxx-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel 
> <https://lists.sourceforge.net/lists/listinfo/mixxx-devel>
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot_______________________________________________
> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
> http://mixxx.org
> 
> 
> Mixxx-devel mailing list
> Mixxx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org


Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Reply via email to