Hey Petah,
On Mon, May 27, 2013 at 1:16 PM, petah <mi...@djpetah.com> wrote:
> Hey,
>
> On Mon, 27 May 2013 03:14:50 -0400
> RJ Ryan <russelljryan-re5jqeeqqe8avxtiumw...@public.gmane.org> wrote:
> > 1) It's valuable to have a structured representation of the mappings.
> Code
> > is a black box and Mixxx has no visibility into it. This means that
> > mappings expressed purely in code are not manipulatable by Mixxx. It
> > doesn't matter what the declarative format is (JSON, YAML, XML, etc.)
>
> So if this declarative table (which is obviously needed to standardize the
> glue interface) was returned from script itself that'd be ok right? After
> all Mixxx doesn't need it to be a disk file as long as it can retrieve a
> standard data structure. In that case driver writers could choose whatever
> storage they want if they're allergic to one file format or another.
>
> Switching to such an architecture just needs a standard Javascript
> function that loads existing XMLs.
>
This would work fine if all Mixxx needed to do was load a preset but it
also has to be able to serialize presets. If the script returns the
mappings from a standard function call then Mixxx would have no way to
write an updated script with the user's modified mappings.
>
> > but a
> > practical consideration is that breaking compatibility with the extensive
> > set of controller scripts in the wild would be an extremely sub-optimal
> > outcome.
>
> Agreed, it's a problem for many reasons.
>
> > If you care about performance, you should instead be coming up with a
> > standard, non-script way to implement scratching. Compared to executing
> > code in a VM, the current XML bindings are orders of magnitude more
> > efficient (It's a hash-map lookup to figure out which control to dispatch
> > a message to).
>
> I only know how my own CDJ scratch works, it's a continuous stream of
> absolute timestamps. Post-processing the position deltas to detect
> play/pause/rew/ff/loop could probably be done in script.
>
> Are there other critical latency cases like resuming a cue to do a Roger
> Sanchez style needle-drop mix? (good luck:)
>
Well, there are lot of issues around wheels in general in Mixxx and our
solution today kind of sucks. There's no standard way for a preset to
provide options the user can tweak such as wheel sensitivities -- our
answer is "just pop open the JS file in a text editor and change this
number". Also, for wheels that act "normal" for whatever values of normal
we define, we should provide a generalized non-script infrastructure for
processing scratching and jog-wheeling that bypasses script and supports
the user customizing it in the most common ways (sensitivity,
touch-enabling, inertia, etc.)
>
> > 5) Controller scripts are a mechanism for advanced script authors to get
> > full control and customization. Throwing out the mappings eliminates all
> > possibility for non-advanced users to customize their controller without
> > writing code.
>
> Does it make sense to separate/layer 'low-level driver' from higher-level
> customization, which could use a UI?
>
>
What would be the intermediate level language between the raw interface
(MIDI/HID/OSC/Keyboard) and the high level (ch1 volume, crossfader,
sampler4 play button, microphone push-to-talk).
Would it be what the thing is truly labeled on the metal (ok.. most likely
plastic ;) )? (e.g. Let's say the user wants a knob labelled master volume
on their controller to be mapped to master balance. MIDI command -> knob
labelled master volume on the controller -> master balance.)
The main benefit I can see to this intermediate layer is that the user
could clear all of the preset's customizations independently of the device
default behavior. I see where you are going with this in the context of
this discussion -- a "driver" that is written in something not meant to be
dealt with by mere mortals translates from raw MIDI/HID into controls and
then a Mixxx user's customizations are saved on top of this (in some other
structured format).
The thing is -- there is no such thing as an absolute truth in translating
low-level MIDI to higher-level controls. What I mean is, really everything
is opinion and everything is a customization. Take for example a knob that
is labelled something that Mixxx does not support (for example, FX
wet/dry). A preset author today will pick something arbitrary to map to
that knob -- usually something that fits their workflow. A user who wants
that knob to do something else would be just as right in changing it to
something else. Similarly, certain knobs have semantics in some software
that Mixxx doesn't replicate or vice-versa. The way it is handled today is
that the preset author expresses their opinion. What about a control
surface that is designed to be fully customized (e.g. devices like the MIDI
Fighter)?
A "driver" implies a lack of ambiguity, as if there is one way a device
should act. A USB soundcard driver has a very well-defined and achievable
task. A driver in the sense you are describing... not so much. That's why I
would say there is no use in creating a distinction between low-level
translation and "user customizations". Maybe you could explain more if I've
misunderstood :).
Instead, I think it makes more sense to empower users to easily publish
their customizations. We'll continue to try and make the standard preset
that comes with Mixxx as close of a faithful representation of the
controllers functionality as written on the plastic and give users easy
access to alternative mappings from the community via the community
controller presets repository (the aforementioned GSoC project). With
comments, download counts, photos, and ratings I think the best presets
will rise to the top.
Best regards,
RJ
> cheers,
>
> -- p
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> 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
>
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
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
