On Wed, Nov 22, 2017 at 12:24 AM, Sean M. Pappalardo - D.J. Pegasus <
spappala...@mixxx.org> wrote:
> On 11/20/2017 03:42 PM, Harry van Haaren wrote:
> > Developers, checkout 17:15, where the "Virtual Devices" concept is
> > introduced.
>
> That /would/ be very handy in allowing users up the expertise chain (so
> to speak) troubleshoot/develop mappings with the hardware owners. The
> only thing I would suggest to make that process work well is to create a
> bonehead-easy way for a very non-technical user to create a virtual
> representation of their controller. (I'm thinking a GUI with a wizard
> that walks them through the process, automating as much as possible.
> Like have them take a photo of the device with their cell phone or Web
> cam, then try to auto-identify controls in the image so the user needs
> only edit their properties and move them around a bit instead of having
> to create them all manually.) That also lessens the responsibility for
> you and the OpenAV team to have to create virtual devices yourselves
> from every controller ever made.
Yes I like the idea of "making it easy to support new controllers" - we
might argue about image-detection or user-input or ... or ... but we're on
the same page :)
>
> > it
> > hopes to allow accessing HD screens on
> > all Ctlra supported devices, and get tight integration to the next
level.
>
> That sounds good on the surface, but wouldn't that then restrict the
> ability of applications to style the information on the screens to a set
> of pre-defined designs/layouts Ctrla supplies?
The Ctlra API for screens is not finished yet. Currently it exposes the
*native* data format that is required to be pushed down the USB cable to
the device. This does not scale at all, and is a nightmare for applications
(trust me - there are some *wacky* encodings out there :)
Long term goal:
1) Provide "raw access" pointer to data structure if application *demands*
it - but strongly advise against using it, as it renders work 1:1 as
Software : Controller, which will benefit very few people in general.
2) Provide a generic RGB interface. which should work with all colour
screens. Note that different screen sizes / layouts are still going to
require some kind of implementation, similarly with the "what to display".
(Techie note: yes this requires mushing RGB into whatever data format the
device requires. Performance wise, modern CPUs easily handle this - and if
a specific low-CPU-power device and Controller *must* be supported, then
option (1) allows that).
> I imagine a DJ
> application like Mixxx will want to use the screens quite differently
> than an audio editing application like Audacity or a DAW like Ardour.
Yes correct. Or a live-performance looper / FX / virtual-instrument / etc.
Long term goal is to use AVTKA (same as virtual controllers - so many
projects will be building/shipping it already), and use that to "generate"
interfaces somehow. I'm not sure on the details yet, but there's a lot of
options and flexibility possible. AVKTA is very dynamic and easy to add new
widget types, and it is intentionally simple to code simple-ish UIs. Ctlra
will not *force* AVTKA usage, but provide it as a helper to get things done
quickly, and provide good UX for users: or that's the goal anyway.
> Another argument for not having another translation layer is
> performance, especially where low-latency response is expected from a DJ
> application with a moving-platter controller for example that sends over
> 1000 messages per second. How much latency does Ctrla add at the moment?
Ctlra works inline (aka, the CPU checks for events, and handles them
immediately). There is no buffering longer than the time between the CPU
checking for events. As such, Ctlra doesn't *add* any latency. It uses the
minimum required buffering to function, and apart from that it depends on
the Application on how frequently it requests events.
I have a device that sends a huge number of URBs to transmit pad pressure
values which are filtered into note-on/off events by SW. The note-on/off
event is converted into a LED message, and toggles the LED on when the pad
is pressed. This "round trip" from pad -> CPU -> light under pad "feels"
instantanous. Of course, its hard to measure the latency here being
physical / light feedback.. but don't worry about this - just compile the
PR at some point and test it :)
> Sincerely,
> Sean M. Pappalardo
> "D.J. Pegasus"
> Mixxx Developer - Controller Specialist
Thanks for your input! -Harry
--
http://www.openavproductions.com
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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
