[Mixxx-devel] PR#667 review merge
Hi, Can someone merge or comment PR#667 https://github.com/mixxxdj/mixxx/pull/667 please ? I missed HID mapping script in new mapping for Hercules DJ Control MP3 e2. This PR corrects this. MIDI driver for this controller is a real pain under Linux, so I think it is important to have correct HID support for it before 1.12 release. Thanks in advance, sb -- ___ 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
Re: [Mixxx-devel] brainstorming for future mapping format
Also, layers could have custom loading and unloading functions. As an example use case, in my Electrix Tweaker mapping, MIDI messages have to be sent to toggle the encoders between absolute EQ mode and relative mode with scripted control of the LED rings for loop mode (see https://github.com/mixxxdj/mixxx/blob/master/res/controllers/Electrix-Tweaker-scripts.js#L381 ). On 08/10/2015 04:29 PM, Be wrote: 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 -- ___ 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
Re: [Mixxx-devel] brainstorming for future mapping format
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
