On Sun, Jul 9, 2017 at 7:04 PM, Daniel Schürmann <dasch...@mixxx.org
<mailto:dasch...@mixxx.org>> wrote:
Hi Harry,
thank you for pointing me to ctlra_info_get_name.
That is a good help to locate the event on the controller.
Yep, and together with the layout info, it is enough to provide good UX
on what it is, and where it is on the device.
However, I think we have the chance here to also represent the
intended use of a control in machine readable way
Interestingly, my "v1" iteration of the Ctlra library worked like that.
Human/machine readable strings, that would be interpreted between device
and application, to attempt to provide "semantic" meaning to a control,
so the application would "automagically" connect with it. I discussed
the idea with a few Linux Audio developers who's opinions I regard
highly (aka; they have years of experience), and they discouraged the
idea. In *theory* it works really well, but then practice comes along
and it just doesn't work as intended.
For DJ controllers to DJ software, it will probably work OK. Gain,
Pitch, Play - those have pretty obvious mapping targets. But then
there's a range of other capabilities, that just *dont* fit, and unless
the user maps them explicitly, its just not gonna work. For example, how
to map a WiiMote to Mixxx; there is no "correct" or even "logical" way
of mapping it. Its user-specific, depending on what they want to do.
It would be just natural to define some kind of application profiles
for a controller, that a controller manufacturer may implement.
This can be linked into the OSC namespace. Just to be compatible
with OSC. OSC can benefit in the same way from our application
profiles. And when we one day have a device connected over network
using OSC it can be quite well wrapped and presented in Ctlra. There
is no other relationship between OSC and Ctlra and OSC just the
shared OSC address.
For example we can define
"Deck X Gain profile":
A control that is intended to control the gain of a deck.
Value x means lowest gain value y means highest gain and value z
(centre) means 0 dB.
OSC Address: /CTLRA/DEVICE/DECK1/GAIN
Thats all. This is IMHO quite natural and does not effect directly
the API.
For now it requires "only" an other string for each event.
ctlra_info_get_osc_address(). Which can default to
/CTLRA/DEVICE/TYPE/ID if there is no profile defined.
This solves also the LED connections:
"Deck X Play/Pause profile":
A control that is intended to toggle between play and pause of a deck.
Value x means pressed value y means released. It may feature also an
indicator light that can be controlled independently.
OSC Address: /CTLRA/DEVICE/DECK1/PLAY_PAUSE
OSC Address: /CTLRA/DEVICE/DECK1/PLAY_PAUSE_LED
All this is optional, but if a controller implements Application
Profiles, it is instantly usable with a basic function in all Ctlra
enabled devices. We are back in the good old midi days, where you
can plug in a keyboard and it just works.
The OSC Addresses are only needed once to setup the initial mapping
for a direct Ctlra application and are used as OSC as communication
address in case of a OSC gateway.
I see that OSC is increasingly supported by various DAW application.
So Ctlra will immediately benefit from it. There is no need to
explain the DAW and Controller manufactures: "You do not need OSC,
use Ctlra".
We can ask them, to consider the "Ctlra Application Profiles" on top
of the OSC support, to benefit from great source of instantly usable
controllers. This will IMHO help a lot to make Ctlra popular, and
wash away the impression that Ctlra is just a new concurrent standard.
I don't object to an application taking this route - if it wishes to map
events to OSC, that's fine. I don't think adding some form of OSC
metadata overlay into the plain C Ctlra API makes any sense. Unix
philosophy, one thing, and do it right. That one thing is making
hardware devices available under a single API, and abstracting events
and feedback to be generic.
Taking a step back, the problem we are trying to solve is to easily
allow users to use their hardware with an application (eg: Mixxx).
Say a developer (me) adds a default Ctlra map for a device (eg, the NI
S2 Mk2), and provides sane default mappings. 80% of DJs will probably be
happy. The remaining 20%, probably want to remap a few FX controls, or
have some buttons perform differently (sampler control instead of loops,
or smth). For these 20%, we provide a way to re-purpose controls - the
existing JS Mixxx infrastructure for example. Is that not a good-enough
end goal?
I see the above suggestion as the "pragmatic" path to success. Lets not
try fix all the mapping problems, semantic usages, and OSC-DAW
integration at once. Lets fix hardware integration, in a forward
compatible way so that more devices can be implemented under it, and
that the device-implementation effort is shared across manufacturers and
all developers in the community.
My 0.02$, Cheers -Harry
PS: I'll kick off a new thread to discuss the Ctlra/Mixxx PR itself.
Am 09.07.2017 um 14:57 schrieb Harry van Haaren:
On Sun, Jul 9, 2017 at 1:23 PM, Daniel Schürmann
<dasch...@mixxx.org <mailto:dasch...@mixxx.org>
<mailto:dasch...@mixxx.org <mailto:dasch...@mixxx.org>>> wrote:
Hi Harry,
> At no point to I think Ctlra will *require* also using
TCC. It
just so happens that they complement each other well for my
use-cases.
That seams to be a good approach. If the architecture
allows to put
Ctlra drivers into runtime loaded object files, it does not
matter
which compiler is used and if it turns out that TCC is the
best for
our needs on a platform, fine.
> That proposal looks really good. It basically means,
from a Ctlra POV, that Ctlra is plain old C code, and exposes
generic events.
No, not generic events. The Ctlra using apllications should
receive
a specific event.
By "generic event", what I mean is a specific event type, with a
specific event ID. These two combined identify one specific
control item on a physical controller device. For example, a
specific button (eg Play) sends a button event when pressed /
released, using this struct for metadata:
https://github.com/openAVproductions/openAV-Ctlra/blob/master/ctlra/event.h#L63
<https://github.com/openAVproductions/openAV-Ctlra/blob/master/ctlra/event.h#L63>
Note that the name of the control is *not* included here for
performance reasons. Passing strings around just isn't a good
idea for performance. Ctlra provides functions to lookup the
name of each event based on type/ID. I have "generic"
applications (don't care about which HW controller is used) that
provide fully labelled UIs showing all control names - so your
use-case is covered here. (If there is an issue, we can resolve
it at the Ctlra API layer, but AFAIK the API caters for the
application's requirements).
If you turn the gain Knob on a controller, the application
should be
able to now that this is the Knob labeled with "Gain"
grouped for
Deck A.
See above paragraph - names of events are provided, based on the
labels physically printed on the hardware.
This might be done by a generic event + a link into a
manifest file,
which may also include a photo of the controller. This
metada of
each event should be optimized to be translated into a OSC
address,
this should be a mandatory part of Crtra. So we need a
document like
this:
https://github.com/fabb/SynOSCopy/wiki
<https://github.com/fabb/SynOSCopy/wiki>
<https://github.com/fabb/SynOSCopy/wiki
<https://github.com/fabb/SynOSCopy/wiki>>
I see no value in *demanding* that Ctlra supports OSC, in the
same way that Ctlra will not demand the use of TCC. Ctlra must
be a standalone library (with only *essential* dependencies like
libUSB). Any metadata should be directly related to the physical
device capabilities. Mapping and adding semantic meaning to the
controls is up to the application.
I do not wish to include images in Ctlra - it complicates
things, and is generally just un-conventional. That said, I so
see value in "visually showing" users what controls are
available, and what thier labels are. This has already been
discussed, and a POC implemented:
https://github.com/openAVproductions/openAV-Ctlra/issues/7
<https://github.com/openAVproductions/openAV-Ctlra/issues/7>
(note to self, I still need to cleanup and publish the branch
with the POC).
I feel the scope of Ctlra should not include the "semantic
meaning" of controllers. This was discussed previously (there's
one question at the end of the LAC talk asking exactly this),
and it doesn't scale well, and only complicates things. So Ctlra
will provide an Event per button press/release, with type/ID to
identify the exact physical change. Interpreting the meaning of
that event, and mapping it to application functionality is *not*
in the scope of Ctlra.
> The application can interpret those in whatever way it
wants -
OSC, JS/Mixxx, or however OpenAV stuff will end up doing
this. It
keeps Ctlra just generic events, and allows the application
to solve
the mapping problem in its own way. That sounds logical and
a good
abstraction, which is exactly what Ctlra aims for.
Yes, that is right. Today in case of midi, the user has to
figure
out which midi key is doing what. With a Ctlra enabled
controller
this issue should be gone. The mapping solution can for
example show
the photo of the controller, and highlight the place of action.
But even without the photo, the user knows exactly how to
enable a
knob LED, using the OSC name-space as address.
The human-readable string that is provided by Ctlra library API
enables the user to understand the event. For an example of the
name lookup, please see here:
https://github.com/openAVproductions/openAV-Ctlra/blob/master/examples/simple/simple.c#L51
<https://github.com/openAVproductions/openAV-Ctlra/blob/master/examples/simple/simple.c#L51>
> In order to progress this idea, I'll post code up ASAP,
which makes the generic Ctlra events available in a callback as
part of the CtlraController class. After that, the Mixxx/JS
components must be designed / worked on to fully enable
Ctlra in Mixxx.
Thank you :-)
I think for the OCS Plug and Play stuff we just need to
rethink the
API a bit.
I would like to do something like this
https://github.com/mixxxdj/mixxx/blob/lv2_support2/src/effects/lv2/lv2manifest.cpp
<https://github.com/mixxxdj/mixxx/blob/lv2_support2/src/effects/lv2/lv2manifest.cpp>
<https://github.com/mixxxdj/mixxx/blob/lv2_support2/src/effects/lv2/lv2manifest.cpp
<https://github.com/mixxxdj/mixxx/blob/lv2_support2/src/effects/lv2/lv2manifest.cpp>>
in Ctlra as well.
(Sorry, I am not completely though the API so this might be
wrong)
As above, I'm not liking the OSC semantic meaning side of things
- Ctlra is a C library and provides events. Mapping (to OSC, or
whatever) is up to the application. Or if there is value,
somebody could create a OscApiForCtlra library - but personally
I don't see that as having value at the moment.
We need a kind of generic data point enumerator expression
for every
event, which is able to discover all controller features.
Ctlra API enables this already. The ctlra_dev_info_t struct has
all names of all events, and the counts of each. In the POC
implementation, the size of the controller, and control position
/ size are available as integer values in millimeters. This
enables a GUI application to "mock up" the controller, no photos
/ pictures involved.
Every data point should have a function for examine like
ctlra_dev_get_osc_namespace() and
ctlra_dev_get_picture_location()
Will this work? Does this fit to the ctlra goals?
I feel the Ctlra API enables the events + physical device info
already. Adding OSC namespaces etc above it is not it the scope
of Ctlra, nor should it be in my opinion. (Due to not
*demanding* applications use any particular form of mapping /
interpreting events). Visually enabling controllers is achieved
by providing physical layout info of the device, instead of
using a photo - a much better solution IMO.
Thoughts / opinions? -Harry
Am 09.07.2017 um 13:18 schrieb Harry van Haaren:
On Sun, Jul 9, 2017 at 11:21 AM, Daniel Schürmann
<dasch...@mixxx.org <mailto:dasch...@mixxx.org>
<mailto:dasch...@mixxx.org <mailto:dasch...@mixxx.org>>> wrote:
Hi Harry, Hi Be,
here some comments:
IMHO arguing about If C or JS is easier will not
lead us ahead
in this discussion.
Good point - apologies for the rat-hole.
> As noted above, we can take TCC off the table for
Mixxx's
use case. Personally I still love it - and it has
radically
changed how I think about programming in C - but
perhaps its
just not a good fit for Mixxx. I can work with that.
I am afraid a mandatory TCC based Ctlra solution
will prevent
it from being successful.
At no point to I think Ctlra will *require* also using
TCC. It
just so happens that they complement each other well
for my use-cases.
Only a solution that works nice Windows as well as
on non X86
based architectures will be accepted as a new standard.
TCC supports a variety of targets; and despite no official
releases, the git repo is pretty active:
http://repo.or.cz/w/tinycc.git
For me, the key is here to be modular. Similar to
LV2 each
driver Ctlra driver can be shipped with a source
file and a
meta-data file which should contain a recipe to
turn the
source file into a *.so or a dll. In a future
advanced step,
the hosts Ctlra library code should be responsible
to read the
recipe and do what it should be done to turn it
into a binary.
I'm not sure what the benefit is here - i see a pretty
complex
workflow, but no ultimate gain that TCC doesn't already
provide.
But I said I'd drop the TCC idea and discuss other options.
> Lets find a better solution for novice / casual
users who
don't want to compile anything.
The compile step itself is not the issue. If we
look for
example to OpenGL Shading Language, where we also
have a
compiler step no one noticed.
Good point.
>> Even if we have a ctlra controller in Mixxx, we
need to
adapt the signals to Mixxx Control Objects using
xml or js files.
> Why XML or JS? I see many more options, and just
because we
have existing infrastructure for a similar case
doesn't mean
its always the correct solution.
Just because Mixxx is using it right now. It is
IMHO not in
the responds of Ctlra to convert controller events into
application commands.
OK - then lets investigate this option more. Keep in
mind that my
JS experience is limited, and that I'm not particularly
familiar
with QT/Mixxx's JS engine capabilities.
I'll post a PR asap that exposes Ctlra events to Mixxx,
and then
see what kind of JS magic is required on top to expose
that to the
JS mapping scripts.
> I'm still not convinced it is possible for any
point-and-click system to fully map most
controllers **in a
maintainable way**. ...
This is should be out of scope of Ctlra.
Absolutely yes - this is outside the scope of Ctlra -
at this
point we are talking about the integration of Ctlra +
Mixxx in
particular. This was noted by a few developers at the
LAC too,
that device access is only a part of the problem.
Providing a good
mapping mechanism is the harder part. But we need step
1 (Ctlra
device access) before step 2 (easy/powerful mappings).
IDEA:
Thinking of all of this again, I think this Ctlra
project is a
great chance to fix some issues, existing standards
have.
* Midi: Midi is that successfully, because it is
defined up to
the Application layer for a Midi-Keyboard. Reusing
this for
other types of controllers works, but pushes it
down to the
Presentation Layer.
* OSC: OSC fails to define the Application layer. It is
promoted to be a Midi successor, but it even has no
standard
way to even transport good old midi messages. There are
approaches to fix this in some OSC namespaces, but
this is
somehow stucked.
It would be grate If we could get back to the state of
original Midi Plug-And-Play behaviour for
Midi-Keyboard for
all type of controllers using Ctlra. If we do this
along with
a OSC namespace for Ctlra, this will be a great
benefit and
probably a very successfully.
Lets see!
On a Midi-Keyborad you know exactly which phsical
key is
pressed an how just looking to the midi Message.
This can be done for Ctlra as well, I we define a
message like
"Gain Knob Deck A 56 %" So a new controller will be
instantly
usable for Mixxx with a basic default mapping. This is
probably not sufficient, but putting a new function
on "Gain
Knob Deck A" can be done by existing mapping solutions.
Yes, simple "static" mapping schemes can be easily
handled by
mapping event IDs to ControlProxy objects. As Be
pointed out, the
difficult point is layering multiple functionalities
over each
other in a user-workable way.
I have these Architectures in mind:
OpenAV setup:
HID-Controller
V
Ctlra Driver
V
Cltra Lib
V
C Mapping
V
OpenAV App
Mixxx setup:
HID-Controller
V
Ctlra Driver
V
Cltra Lib
V
Controller Proxy
V
XML / *js mapping
V
Mixxx engine
Gnereic OSC setup:
HID-Controller
V
Ctlra Driver
V
Cltra Lib
V
OSC Wrapper (process)
V
UDP/TCP
V
OSC to OSC mapper
V
UDP/TCP
V
OSC enabled DAW
What do you think?
That proposal looks really good. It basically means,
from a Ctlra
POV, that Ctlra is plain old C code, and exposes
generic events.
The application can interpret those in whatever way it
wants -
OSC, JS/Mixxx, or however OpenAV stuff will end up
doing this. It
keeps Ctlra just generic events, and allows the
application to
solve the mapping problem in its own way. That sounds
logical and
a good abstraction, which is exactly what Ctlra aims for.
In order to progress this idea, I'll post code up ASAP,
which
makes the generic Ctlra events available in a callback
as part of
the CtlraController class. After that, the Mixxx/JS
components
must be designed / worked on to fully enable Ctlra in
Mixxx.
Thanks for all the input - we seem to be converging on
a solution,
great! -Harry
Am 09.07.2017 um 06:52 schrieb Be:
Hi Harry,
I read the paper for the presentation at LAC
2017 that you
linked on IRC:
http://musinf.univ-st-etienne.fr/lac2017/pdfs/01_C_E_137795.pdf
<http://musinf.univ-st-etienne.fr/lac2017/pdfs/01_C_E_137795.pdf>
<http://musinf.univ-st-etienne.fr/lac2017/pdfs/01_C_E_137795.pdf
<http://musinf.univ-st-etienne.fr/lac2017/pdfs/01_C_E_137795.pdf>>
Going along with what I mentioned in my
previous post, I do
not think Ctlra should be aware of the
"userdata". IMO that
should be left to the application and its
scripting environment.
On 07/08/2017 08:36 PM, Be wrote:
On 07/08/2017 06:51 PM, Harry van Haaren wrote:
3. The programming language. It is
a lot easier to find
someone who
knows JavaScript, or at least kinda
knows JavaScript
enough to get
by for a small project, than it is
to find someone who
knows C. For
people with minimal or no prior
programming experience,
higher level
languages are much easier to learn.
Surely anybody somewhat proficient in
JS can figure out
what this (link below) does??
Programming is programming -
logical thinking. I don't think that
the C code there is
"harder" than achieving the same in JS.
Keep in mind we're
not asking people to do pointer-magic
here - its basic
arithmetic, and calling a functions.
https://github.com/openAVproductions/openAV-Ctlra/blob/master/examples/vegas_mode/z1.c#L45
<https://github.com/openAVproductions/openAV-Ctlra/blob/master/examples/vegas_mode/z1.c#L45>
<https://github.com/openAVproductions/openAV-Ctlra/blob/master/examples/vegas_mode/z1.c#L45
<https://github.com/openAVproductions/openAV-Ctlra/blob/master/examples/vegas_mode/z1.c#L45>>
C is more difficult to learn than
JavaScript. There are a
lot of details in that code that you simply
don't have to
think or know about with JavaScript. To a
novice developer
who knows nothing about C, they'd have to
answer these
questions:
> if(e->slider.id <http://slider.id>
<http://slider.id> ==
NI_KONTROL_Z1_SLIDER_LEFT_FADER) {
What is the difference between "->" and "."?
> uint32_t iter = (int)((d->volume+0.05) *
7.f);
1. What is a uint32_t? Why should I use
that instead of a
different number type?
2. What is that "(int)" doing?
3. Why is there a ".f" after the "7"?
That's just the tip of the iceberg of
understanding a few
lines of code. Fully mapping controllers
requires
considerably more complex logic than that.
So, I think it would make more
sense to expose Ctlra to
Mixxx's
existing JavaScript environment for
controller mapping.
There would
only need to be two capabilities
added for this to work:
1. Scripts would be able to
register JavaScript
callback functions
that would be called when
particular Ctlra events are
passed to Mixxx.
2. Scripts would need to have a way
to send output
messages to
Ctlra. There should be a way to
freeze/unfreeze the
sending of
output messages so many outputs
could be updated
simultaneously in a
single HID packet.
I have written a proposal for how
to do this with MIDI:
https://mixxx.org/wiki/doku.php/registering_midi_input_handlers_from_javascript
<https://mixxx.org/wiki/doku.php/registering_midi_input_handlers_from_javascript>
<https://mixxx.org/wiki/doku.php/registering_midi_input_handlers_from_javascript
<https://mixxx.org/wiki/doku.php/registering_midi_input_handlers_from_javascript>>
<https://mixxx.org/wiki/doku.php/registering_midi_input_handlers_from_javascript
<https://mixxx.org/wiki/doku.php/registering_midi_input_handlers_from_javascript>>
<https://mixxx.org/wiki/doku.php/registering_midi_input_handlers_from_javascript
<https://mixxx.org/wiki/doku.php/registering_midi_input_handlers_from_javascript>>
It would be great if we could
create JS APIs that are
almost
identical for MIDI and Ctlra.
I'm still not sold on the idea of
wrapping all of Ctlra up
in JS callbacks and then exposing it to
Mixxx. Its
possible, but I fail to see why this
should be the
holy-grail of how mappings should work.
I should probably
do up a design-doc or video on how I
think *eventually* the
Ctlra / Mixxx UX for mapping a
controller would look: and
if I can figure out the technical
parts, it will be pretty
revolutionary in how it enables novice
users to create
unique mappings. Punch line is to
present the functionality
(multi-layered bindings) in a way that
is easily consumed
by "ordinary" humans, and provide a doc
+ video explaining
it. Give me a few weeks - some POC
Ctlra + Mixxx code
first, then onwards to the exact
mapping UX.
I'm still not convinced it is possible for any
point-and-click system to fully map most
controllers *in a
maintainable way*. Years ago, device
specific hacks were
added to Mixxx in C++ to make the XML
system work with MIDI
signals for jog wheels. Someone please
correct me if I am
wrong, but my understanding is that the JS
engine was added
to avoid the need for such compiled-in
device specific
hacks. Almost all mappings submitted for
inclusion in Mixxx
recently have been done mostly or entirely
in JS. Traktor
has an elaborate point-and-click mapping
system and users
complain how awful it is to work with (refer to
https://djworx.com/what-do-you-want-from-traktor-pro/
<https://djworx.com/what-do-you-want-from-traktor-pro/>
<https://djworx.com/what-do-you-want-from-traktor-pro/
<https://djworx.com/what-do-you-want-from-traktor-pro/>>
for
example).
I have previously thought about designing a
GUI that used
tabs to organize different layers of
functionality. But this
would break down quickly for handling the
interaction of
multiple layers and create a mess even
worse than Traktor's
mapping GUI. For example, consider a cue
button that uses
the cue_default ControlObject normally but
start_stop while
a shift button is held. You could define a
layer that the
unshifted button belongs to and another
layer that the
shifted button belongs to. Okay, easy
enough. Now you want
to make that side of the controller able to
be toggled
between deck 1 & deck 3. How would you
accomplish this? With
a simple layering system, you could create
4 different layers:
Deck 1 unshifted
Deck 1 shifted
Deck 3 unshifted
Deck 3 shifted
Then you'd need to copy & paste all those 4
layers for the
other side of the controller with decks 2 &
4! It would be
possible to hack support for toggling decks
into Mixxx so
the mapping could deal with a virtual deck
and Mixxx would
maintain the state of which deck is active,
but that would
only handle this specific use case. And
you'd still need to
copy & paste for the left & right sides of
the controller.
What if I want pushing a button to use the
beatloop_activate
ControlObject when no loop is active but
use reloop_toggle
when a loop is active? I'd need to create a
layer for a loop
being enabled and a layer for no loop
enabled, then somehow
tell Mixxx to switch between them when that
state changes.
Then I'd have to duplicate both those
layers for deck 1 &
deck 3. Now I want pressing that button to
act differently
when shift is pressed -- and act
differently depending on
whether a loop is active. When shift is
pressed, I want to
use reloop_toggle with no loop active and
reloop_andstop
with a loop active. With a GUI layering
system, I'd need
layers for:
Deck 1, loop disabled, no shift
Deck 1, loop disabled, shift
Deck 1, loop enabled, no shift
Deck 1, loop enabled, shift
Deck 3, loop disabled, no shift
Deck 3, loop disabled, shift
Deck 3, loop enabled, no shift
Deck 3, loop enabled, shift
And again copy and paste for decks 2 & 4.
Now there are 16
layers for pushing this button! What if you
wanted to remap
it? Maintaining even this example would be
a pain, and
that's just one component of the
controller. Programming an
entire mapping this would would be awful.
Also consider how you could implement
https://mixxx.org/wiki/doku.php/standard_effects_mapping
<https://mixxx.org/wiki/doku.php/standard_effects_mapping>
<https://mixxx.org/wiki/doku.php/standard_effects_mapping
<https://mixxx.org/wiki/doku.php/standard_effects_mapping>>
for the Kontrol X1, S2, S4, and S5 with
such a system.
Again, you could hack all that logic into
the C++ side of
Mixxx like the deck toggling case, but then
what would you
do to implement something like the effects
mapping for the
Pioneer DDJ-SB2:
https://mixxx.org/wiki/doku.php/pioneer_ddj-sb2#effects
<https://mixxx.org/wiki/doku.php/pioneer_ddj-sb2#effects>
<https://mixxx.org/wiki/doku.php/pioneer_ddj-sb2#effects
<https://mixxx.org/wiki/doku.php/pioneer_ddj-sb2#effects>>
(particularly the Mixxx 2.1 mapping).
This video talks about the uselessness of
visual diagramming
languages like UML, and I think much of
what is said about
visual diagramming languages in this
applies to programming
with a GUI as well:
https://www.youtube.com/watch?v=4_SvuUYQ5Fo
<https://www.youtube.com/watch?v=4_SvuUYQ5Fo>
<https://www.youtube.com/watch?v=4_SvuUYQ5Fo
<https://www.youtube.com/watch?v=4_SvuUYQ5Fo>>
That said, if you have revolutionary ideas
for how to design
a GUI for mapping controllers that could
actually handle all
the complexity above and not be a huge pain
to work with,
please share. I'd love to be proven
wrong... but I think
it's more likely that you'd waste time that
could be better
spent making Mixxx do other cool things or
writing a new
OpenAV application.
Thanks for your input again - good
points raised. -Harry
On 07/06/2017 04:57 PM, Harry van
Haaren wrote:
Hi All,
First of all - this is my first
post to the
Mixxx-devel list, so
a brief intro is in order;
I'm Harry van Haaren, developer
of the OpenAV audio
software,
bit of a music/tech/linux head :)
I've recently been working on
improving controller
support in
Linux audio land, in particular
what I call "modern USB HID"
controller devices
(think DJ
controllers like
Akai/NI/Abletons range).
I've developed the Ctlra
library as OpenAV, which
provides
access to these hardware devices
on Linux. The library allows
hotplug and various other
"advanced" features like accessing
screens on devices.
I'd like to integrate Ctlra
into Mixxx - to provide
access to
hardware currently not available
to Linux users, and also to
provide hotplug support
to those
controllers. I've created a
blueprint
on Launchpad[1], and written an
introduction on
Ctlra and how I
propose to integrate it in
Mixxx[2].
Finally, there is a
documentation page on what
Ctlra itself
achieves here[3], and the
source is here[4].
If you have an interest in
hotplug of controllers,
controller
support or hardware on Linux,
do have a read of the wiki page
and others, and I'd
appreciate
your input on the ideas!
Thanks for all your efforts on
Mixxx so far,
onwards and upwards!
-Harry of OpenAV
[1]
https://blueprints.launchpad.net/mixxx/+spec/ctlra-controller-support
<https://blueprints.launchpad.net/mixxx/+spec/ctlra-controller-support>
<https://blueprints.launchpad.net/mixxx/+spec/ctlra-controller-support
<https://blueprints.launchpad.net/mixxx/+spec/ctlra-controller-support>>
<https://blueprints.launchpad.net/mixxx/+spec/ctlra-controller-support
<https://blueprints.launchpad.net/mixxx/+spec/ctlra-controller-support>>
<https://blueprints.launchpad.net/mixxx/+spec/ctlra-controller-support
<https://blueprints.launchpad.net/mixxx/+spec/ctlra-controller-support>>
[2]
https://www.mixxx.org/wiki/doku.php/ctlra_support
<https://www.mixxx.org/wiki/doku.php/ctlra_support>
<https://www.mixxx.org/wiki/doku.php/ctlra_support
<https://www.mixxx.org/wiki/doku.php/ctlra_support>>
<https://www.mixxx.org/wiki/doku.php/ctlra_support
<https://www.mixxx.org/wiki/doku.php/ctlra_support>>
<https://www.mixxx.org/wiki/doku.php/ctlra_support
<https://www.mixxx.org/wiki/doku.php/ctlra_support>>
[3]
http://openavproductions.com/doc/ctlra.html
<http://openavproductions.com/doc/ctlra.html>
<http://openavproductions.com/doc/ctlra.html
<http://openavproductions.com/doc/ctlra.html>>
<http://openavproductions.com/doc/ctlra.html
<http://openavproductions.com/doc/ctlra.html>>
<http://openavproductions.com/doc/ctlra.html
<http://openavproductions.com/doc/ctlra.html>>
[4]
https://github.com/openAVproductions/openAV-ctlra
<https://github.com/openAVproductions/openAV-ctlra>
<https://github.com/openAVproductions/openAV-ctlra
<https://github.com/openAVproductions/openAV-ctlra>>
<https://github.com/openAVproductions/openAV-ctlra
<https://github.com/openAVproductions/openAV-ctlra>>
<https://github.com/openAVproductions/openAV-ctlra
<https://github.com/openAVproductions/openAV-ctlra>>
--
http://www.openavproductions.com
<http://www.openavproductions.com>
<http://www.openavproductions.com
<http://www.openavproductions.com>>
<http://www.openavproductions.com
<http://www.openavproductions.com>>
<http://www.openavproductions.com
<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
<mailto:Mixxx-devel@lists.sourceforge.net>
<mailto:Mixxx-devel@lists.sourceforge.net
<mailto:Mixxx-devel@lists.sourceforge.net>>
<mailto:Mixxx-devel@lists.sourceforge.net
<mailto:Mixxx-devel@lists.sourceforge.net>>
<mailto:Mixxx-devel@lists.sourceforge.net
<mailto:Mixxx-devel@lists.sourceforge.net>>
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel>
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel>>
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel>>
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel>>
------------------------------------------------------------------------------
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
<mailto:Mixxx-devel@lists.sourceforge.net>
<mailto:Mixxx-devel@lists.sourceforge.net
<mailto:Mixxx-devel@lists.sourceforge.net>>
<mailto:Mixxx-devel@lists.sourceforge.net
<mailto:Mixxx-devel@lists.sourceforge.net>>
<mailto:Mixxx-devel@lists.sourceforge.net
<mailto:Mixxx-devel@lists.sourceforge.net>>
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel>
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel>>
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel>>
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel>>
--
http://www.openavproductions.com
<http://www.openavproductions.com>
<http://www.openavproductions.com
<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
<mailto:Mixxx-devel@lists.sourceforge.net>
<mailto:Mixxx-devel@lists.sourceforge.net
<mailto:Mixxx-devel@lists.sourceforge.net>>
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel>
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel>>
------------------------------------------------------------------------------
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
<mailto:Mixxx-devel@lists.sourceforge.net>
<mailto:Mixxx-devel@lists.sourceforge.net
<mailto:Mixxx-devel@lists.sourceforge.net>>
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel>
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel <https://lists.sourceforge.net/lists/listinfo/mixxx-devel>>
------------------------------------------------------------------------------
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
<mailto:Mixxx-devel@lists.sourceforge.net>
<mailto:Mixxx-devel@lists.sourceforge.net
<mailto:Mixxx-devel@lists.sourceforge.net>>
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel>
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel>>
--
http://www.openavproductions.com
<http://www.openavproductions.com>
<http://www.openavproductions.com
<http://www.openavproductions.com>>
--
http://www.openavproductions.com <http://www.openavproductions.com>
--
http://www.openavproductions.com
