Thanks for your feedback.
I will get a chance to complete the NI Kontrol S4 Mk2 mapping soon, so I
have been studying its code and the common-hid-packet-parser.js library.
Like the XML mapping system, it takes the approach of conflating a
connection with details of the implementation of its handling. I am
convinced this is a bad idea. It necessitates a bunch of cumbersome
imperative code to manage switching between layers.
common-hid-packet-parser.js has some magic keywords ("deck", "deck1",
and "deck2") for the library to manage a common use case for layers, but
as far as I can tell there is no way to reuse that layer handling code
for any other use cases. So, to reimplement the effects mapping design
in https://github.com/mixxxdj/mixxx/pull/1211 for the S4, it will be a pain.
The Components library ( http://mixxx.org/wiki/doku.php/components_js )
would wrap the simple input connection objects and their associated
output connections into an interface similar to the example you
provided. However, it is much more powerful than that and can be used
for managing any arbitrary layers defined by the script author.
As articulated on the plan on the wiki, I think the XML file should be
kept solely for metadata. Otherwise Mixxx would have to execute every
JavaScript file in the mapping directory to get a list of available
mappings.
engine.connectControl() actually does return an object representing the
connection, but no one has ever documented this. I discovered it
accidentally, years after it was implemented, when reading the C++
source to fix a bug in engine.connectControl() with
https://github.com/mixxxdj/mixxx/pull/656 . I think overloading this
function was horribly confusing, so I am proposing to deprecate it and
replace the good part of engine.connectControl with a new function that
has a clean, consistent API in
https://github.com/mixxxdj/mixxx/pull/1218 (and also fix an awful bug
that just came back to bite again on
https://github.com/mixxxdj/mixxx/pull/1211 ).
The problem with engine.connectControl's API -- as it is documented --
is that there is no way for Mixxx to know which connection to disconnect
unless it forbids connections that share the same group, key, and
function. However, as I just discovered in
https://github.com/mixxxdj/mixxx/pull/1211 , that capability is very
useful because even if the function is the same, the 'this' object can
be different and each connection can have a different effect. It is also
confusing to have a connection called "connectControl" that disconnects.
On 03/21/2017 02:35 PM, Dávid Szakállas wrote:
> 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
>> <mailto: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://slashdot.org>!
>> 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://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
>
------------------------------------------------------------------------------
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
