None of those are an issue because Mixxx uses an actual programming language. :)
On 08/11/2015 11:12 PM, Ferran Pujol Camins wrote: > I've now well Traktor mapping system. It wouldn't be that bad (provided > we have scripting anyway) if: > > 1-Execution order of sentences could be determined. > 2-Modifiers could have an arbitrary value (double, text, etc...) instead > of just 0,..7. > 3-More than two conditionals could be defined for a sentence. > 4-The number of modifiers wasn't limited to 8. > 5-Modifiers could have a name. > > 2015-08-11 19:14 GMT+02:00 Be <b...@gmx.com <mailto:b...@gmx.com>>: > > I actually played around with Traktor's mapping system last night and it > isn't that great. Complex mappings quickly get messy. We can do > better. :) > > On 08/10/2015 04:29 PM, Be wrote: > > > > > > On 07/07/2015 10:14 AM, raskolni...@es.gnu.org > <mailto: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 > <mailto: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 > <mailto: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
