Ladies & Lads, 

Its good to see folks thinking on this stuff again. Whilst not a difficult 
problem on the surface, coming up with a solution that scales, is easy to grasp 
for DJs and offers flexibility is a challenging and important problem.

Back in the day, the vision I had for the control stuff was that most of the 
functions could slowly migrate from each individual controller.js file to a 
common.js file over time (each function knowing which deck it was called from 
and apply whatever operation to that deck)...   In that scenario the user could 
map any control on the device to any function using just the drop-down menu in 
mapping preferences panel.

That idea works [mostly] for stateless controllers, but is short of the mark 
for newer stateful controllers.  Also missing is that it doesn't account for 
the idea of variants of control layout for each device gracefully.

For the control layout variants I'm going to thinking about what building 
blocks might be used...   maybe some combination of XML includes, JS includes 
and controller.js init parameters can be used here (also need to consider 
feedback that info to the UI prefs and how to make it editable within the UI... 
  maybe the control mapping needs to be come a tree-table?)

Anyway I'll ponder that on the bus and see if anything percolates. 

Cheers,

-G


On 2010-09-19, at 9:09 AM, Anders Gunnarsson wrote:

> To implement new functionality on the limited amount of buttons on a
> controller, one might have to change functionality on some buttons,
> ans controls. While some users are happy with that, others may feel
> that previous functionality has been broken. Further, a user with both
> a dj controller and a pad controller may not want hotcues on the dj
> controller.
> 
> One way to do this is to have several mappings with slight different
> functionality. Since it requires more work to maintain several
> mappings, some script writers have included flags to configure the
> functionality of their scripts. This will of course lead to more
> complexity of the script, so there has to be some balance between
> workload and complexity. The second case however force a user to edit
> the script, so I guess a lot of users are stuck with the default. This
> is also the case with the XML mapping, a user can't move a script call
> from button to another without editing the XML.
> 
> Another thing that seem to confuse users is that the XML mapping is
> cached, to store settings from the preferences editor. The script
> isn't however, so if a mapping is replaced with a new one. the
> functionality might seem totally broken.
> 
> 
> I have a few proposals to improve the situation.
>   -Include some type of annotation of script functions that should be
> listed in the preferences editor
>   -Include an options configuration in the XML (maybe inspired by
> HTML controls), which can be reflected in and configured by controls
> in the preferences editor. These configuration values could then be
> passed to the script through the init function.
>   -Present the mapping description in preferences.
>   -Include a link to a manual for a mapping in the XML, which is also
> used in the preferences, so the manual can be opened directly from
> Mixxx.
> 
> This last point also calls for another thing needed. The wiki has a
> lot of useful information, but is maybe not structured in the best or
> most consistent way. For controllers it might be good to have one page
> per controller. For Hercules controllers for instance there are now
> two pages that contain info for all Hercules controllers. If approved
> I can do some work to organize at lest the Hercules controllers, and
> to gather manuals for them.
> 
> Keep up the good work!
> //Anders
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Mixxx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Reply via email to