On 07/07/2015 10:14 AM, raskolni...@es.gnu.org wrote: > > On the OP topic: I think your proposed sintaxes look good and could be > useful, it's nice that you open this discussion! > > On the other hand, I have the impression that what we really need is a > two simple functions `map[Output,Input]Control(channel, value, group, > name, options)` that allows to define a MIDI mapping at run-time. This > would be the JS equivalent of the <control> tags. > > On top of this low-level API many richer high-level APIs can be > explored, including your JSON-style formats, Mixco, and further. But > most importantly, it would be possible to write advanced controllers > with JS mode switching, that are as performant as the pure XML scripts. > Right now, a important limitation in the framework is that it's all or > nothing, either you bind a MIDI signal statically in the XML, or handle > the MIDI events completely in JS -- an interesting approach is to be > able to create direct binding for Mixxx controls from JS that then > bypass the script for the individual events, providing better performance. > > Cheers! > > JP > >
I think this is the most reasonable way forward from where Mixxx is. This could facilitate a smooth phasing out of the XML format and a transition to JSON. All the info contained in the header of XML files could be defined in JSON with a metadata object. Looking into other programs' mapping systems, it looks like Traktor and possibly Ableton are the only ones that have mapping systems worth taking ideas from. Serato's system is primitive (at least the user-definable part; no one knows the secrets of how official, unmodifiable Serato certified mappings work). VirtualDJ has its own clunky mini-scripting language. Ableton allows scripting with Python but at first glace I don't see much documentation for it and I've heard there is no debugging output. Traktor's mapping system is flexible but tries to do so much in GUI that it ends up being cumbersome. I think it would be awesome to implement a GUI interface similar to Traktor's but allow direct input of JavaScript snippets from the GUI. For example, instead of selecting [Channel1] as the group for a mapping in the GUI, a user could type in a JS variable that could be toggled between [Channel1] and [Channel3]. Also, custom JS functions could be typed into the GUI. This could combine the best of a GUI interface and the flexibility of JavaScript. I got another idea that I think would be both powerful and straightforward: mappings could be built from layers, which would be JS objects containing groups of input and output mappings. In the GUI, layers would be presented as tabs at the top of the mapping editor. Button presses (or whatever) would be mapped to switch between layers. By default, activating a layer would overwrite active mappings that overlap with the layer being activated. Mixxx could remember the previously active mappings and revert to that when a layer is disabled, which would make implementing shift button layers trivially easy. Would it make more sense to implement layering functionality in C++ or as a JavaScript library making use of a new mapping (dis)connection function? ------------------------------------------------------------------------------ _______________________________________________ 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
