subject:"Re\: \[Mixxx\-devel\] \[Feature Proposal\] Ctlra Controller Hotplug Support"

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-10 Thread Harry van Haaren

On Sun, Jul 9, 2017 at 9:22 PM, Radu Suciu  wrote:

> Just want chime in that mapping controllers in Mixxx by binding to Ctrla
> callbacks and outputs directly in JS, without having to map midi signals in
> XML beforehand would make for a great experience.
>

Thanks for the input Radu! Indeed I see the Ctlra events being forwarded
directly to the JS engine, perhaps with a callback-per-event, to enable
easily handling the event. Would that sound like a good implementation from
the JS point-of-view? (Unfortunatly I do not have much experience mapping
controllers using the JS / XML approach).



> On Sun, Jul 9, 2017 at 11:35 AM, Harry van Haaren 
> wrote:
>
>> On Sun, Jul 9, 2017 at 7:04 PM, Daniel Schürmann 
>> 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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-10 Thread Harry van Haaren

On Sun, Jul 9, 2017 at 9:23 PM, Daniel Schürmann  wrote:

> Hi Harry,
>
> Ok, you are probably right.
>
> I did not follow the early discussion, but I would agree to the Linux
> Audio developers, that relying on those profiles will just not work.
> A powerful mapping system is mandatory to fully support a specific device
> from a specific application.
>

The "early discussion" was in a cafe in Berlin, apologies I should have
made it clear that it wasn't "public on list" as such.
The powerful mapping system is ultimately the answer yep!


> If we look at OSC, we also do not find initially application profiles.
> But due to it's namespace address, it is possible to define them.
> http://www.nime.org/proceedings/2014/nime2014_300.pdf
>
> So I still think we will have a benefit, if we add a machine readable
> string to each event just to be OSC compatible and transparent.
>

With my "perfect software architecture" hat I can whole-heartedly agree,
namespacing, discovery, auto-mapping, and plentiful accurate metadata are
the goals.
With a "pragmatic engineering" approach, the above are all "fluff" around
the core problem, and only confuse the "foot soldiers" implementing devices.

Next steps for me are to try to POC some features that Ctlra enables and
Mixxx currently don't support, "foot soldier style" :D



>
> Am 09.07.2017 um 20:35 schrieb Harry van Haaren:
>
>> On Sun, Jul 9, 2017 at 7:04 PM, Daniel Schürmann > > 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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-09 Thread Harry van Haaren

On Sun, Jul 9, 2017 at 7:04 PM, Daniel Schürmann  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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-09 Thread Daniel Schürmann

Hi Harry,

thank you for pointing me to ctlra_info_get_name.
That is a good help to locate the event on the controller.

However, I think we have the chance here to also represent the intended
use of a control in machine readable way and be also OSC compatible. For 
example I have two gain buttons on my controller, these two buttons can 
be found on any DJ controller, the same is true for example for the 
play/pause button.

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.

Kind regards,

Daniel

Am 09.07.2017 um 14:57 schrieb Harry van Haaren:
On Sun, Jul 9, 2017 at 1:23 PM, Daniel Schürmann > 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

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:

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-09 Thread Be

I agree with Harry, assigning meaning to each event should be out of the 
scope of Ctlra. There is far too much variability between controllers 
for that to be useful, hence why no such system has been invented for 
MIDI DJ controllers and why device-specific mappings exist.

One nice thing about MIDI is that it is usually easy to know which LED 
corresponds to which input. If I want to light the LED for the button 
that sends the input [0x91, 0x51, 0x7f], then I can assume that I need 
to send output [0x91, 0x51, 0x7f] to turn the LED on and [0x91, 0x51, 
0x00] to turn the LED off. Is there such a correspondence between the 
values used for input and output with Ctlra?

I am wondering how we could make the human-readable names in Ctlra's C 
enums accessible to Mixxx's JS environment...

On 07/09/2017 07:57 AM, Harry van Haaren wrote:
On Sun, Jul 9, 2017 at 1:23 PM, Daniel Schürmann > 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

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

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  (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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-09 Thread Harry van Haaren

On Sun, Jul 9, 2017 at 1:23 PM, Daniel Schürmann  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

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
>

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  (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

>
> > 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
> in Ctlra as well.
> (Sorry, I am not completely though the API so this might be wrong)
>

As above,

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-09 Thread Daniel Schürmann

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. 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. 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

> 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.

> 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
in Ctlra as well.
(Sorry, I am not completely though the API so this might be wrong)
We need a kind of generic data point enumerator expression for every 
event, which is able to discover all controller features.
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?

Kind regards,

Daniel

Am 09.07.2017 um 13:18 schrieb Harry van Haaren:
On Sun, Jul 9, 2017 at 11:21 AM, Daniel Schürmann > 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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-09 Thread Harry van Haaren

On Sun, Jul 9, 2017 at 11:21 AM, Daniel Schürmann 
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
>

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-09 Thread Daniel Schürmann

Hi Harry, Hi Be,

here some comments:

IMHO arguing about If C or JS is easier will not lead us ahead in this 
discussion. Both are easy and hard in different aspects. It is all an 
issue about "Know your tools".  The embedded developers in the 
controller companies will be most likely C-Natives. So for now I think a 
C driver in a C library is not that bad, because it does not introduce a 
second programming language.
From the security aspect, we have the same issue for LV2 effects they 
can crash Mixxx. This can be solved by fixing them or move them to a 
quarantine process.  But this decision can IMHO not be done inside Ctlra.

> 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. Only a solution that works nice Windows as well as on 
non X86 based architectures will be accepted as a new standard.
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.

> 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.

>> 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.

> 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.

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.

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.

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?

Kind regards,

Daniel

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

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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-08 Thread 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

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

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 == 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.

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

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/ 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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-08 Thread Be

On 07/08/2017 06:51 PM, Harry van Haaren wrote:

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

> if(e->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

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.

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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-08 Thread Harry van Haaren

On Sat, Jul 8, 2017 at 10:32 PM, Daniel Schürmann 
wrote:

> I share Be's concerns about TinyCC compiler. On one hand it is available
> in the Ubuntu repos, on the other hand it is "not recommended for
> production use" in the explaining text.
>
> But that is not a big problem. For me it makes no difference if we dynamic
> ling a device.so file generated from TinyCC or GCC.
> GCC is available by default and calling it from ctlra or manual should not
> a big issue. We most likely cannot rely on TinyCC for Windows anyway.
>
> I think we have to distinguish between two areas of device depended code.
> 1. The driver part, which presents the controller in a generic way like it
> already happens with midi controllers
> 2. The application mapping, to adapt application features to controller
> features.
>
> If I get it right, ctlra aims to cover only 1.

Ctlra exposes generic events. These must be interpreted by the application
in *some* way - it can be C code, XML, JS, or whatever. But *somehow* the
event need to be bound to a ControlProxy in Mixxx yes.

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.

> The other point of view is the knowledge out there among audio artists.
> Here are two stats sources:
>
> https://octoverse.github.com/
> https://www.tiobe.com/tiobe-index/

All this tells me is that "more" people are programming - logical thinking.
If we present easy-to-use functions in plain C, I'm sure any JS developer
will be able to understand it. Its about making the problem easy to
understand and achieve your goals with, more than choosing tools some might
have experience with. Aka: lets focus on solving the problem in the easiest
way, not trying to use the "easiest" or "most used" tools.

No comment, I see neither of those as a good solution for this particular
problem.

> > 2. If a user wanted to replace a precompiled mapping that came with
> > Mixxx with one they made or got online, what would that process go like?
> Would the user need to install TCC? Would we have to include TCC in Mixxx?
>
> Mixxx should already have access to a C compiler, if we decide to go the C
> way. The other option would be to share pre-compiled *.so files.
> But they are not cross platform and can contain a trojan.

Lets move away from the dynamically compiled code for Mixxx. Given the
problem, maybe TCC isn't the best fit. It served me well in developing
complex mappings - as a developer. Perhaps its not the best for users, and
that's OK. Lets find a better solution for novice / casual users who don't
want to compile anything.

> > 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.
>
> This is not a biggest issue for me, because even if you know Javascript or
> likewise C, you cannot instantly start over to hack up your driver.
> You need a lot of reading and probably reverse engineering, which is
> probably harder than adopt a sample script of a partly unknown language

Good point - and I don't expect anybody to "just pop up" and start hacking
a driver from zero-experience.

> IMHO the success of Ctlra depends to a high degree to the numberer of
> supported popular controllers. If we manage to push this number up, all the
> technical issues are secondary.

Yes, agreed. Enabling cool features (screens!!) and such might sway some
people to consider using Ctlra too - lets see!

> If we fail, Ctlra is just another controller interface to support.
> https://xkcd.com/927/

Heh - that's one of my favorites. Thanks for that :)

> Kind regards,
>
> Daniel
>
>
>
>
>
> Am 08.07.2017 um 22:00 schrieb Be:
>
>> Thanks for taking up this project! Reading your proposal on the wiki
>> page, the way you intend to integrate into Mixx's ControllerManager and
>> Controller classes makes more sense now.
>>
>> The big question I am wondering about is the process of creating the
>> mappings from Ctlra events to Mixxx's state. Your idea to use TCC is
>> interesting and I think it's no problem for a proof-of-concept, but I am
>> doubtful it would be a good way to integrate Ctrla support into
>> applications for several reasons:
>> 1. Is it possible for a controller mapping to crash the application? That
>> should not happen under any circumstance.
>> 2. If a user wanted to replace a precompiled mapping that came with Mixxx
>> with one they made or got online, what would that process go like? Would
>> the user need to install TCC? Would we have to include TCC in Mixxx?
>> 3. The programming language. It is a lot

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-08 Thread Harry van Haaren

On Sat, Jul 8, 2017 at 9:00 PM, Be  wrote:

> Thanks for taking up this project! Reading your proposal on the wiki page,
> the way you intend to integrate into Mixx's ControllerManager and
> Controller classes makes more sense now.
>

Thanks, and glad to hear it.

> The big question I am wondering about is the process of creating the
> mappings from Ctlra events to Mixxx's state. Your idea to use TCC is
> interesting and I think it's no problem for a proof-of-concept, but I am
> doubtful it would be a good way to integrate Ctrla support into
> applications for several reasons:
> 1. Is it possible for a controller mapping to crash the application? That
> should not happen under any circumstance.
>

Agreed that this *should* not happen. We could discuss details of exactly
how/what, but lets leave it aside for now, to address comments below.

> 2. If a user wanted to replace a precompiled mapping that came with Mixxx
> with one they made or got online, what would that process go like? Would
> the user need to install TCC? Would we have to include TCC in Mixxx?
>

As mentioend later in this thread Daniel expressed concern over using TCC -
so let me answer that later.

> 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

> 4. Mixxx, and other applications, already have systems for supporting MIDI
> controllers. Like Mixxx, some of these applications already have their own
> scripting environments. Maintaining code and documentation for separate
> ways for mappings to interact with the application would be a burden for
> the application developers. For controller mapping developers, their
> experience would be totally different depending on whether they were
> mapping a MIDI controller or a Ctlra supported controller. This would be a
> barrier to sharing knowledge and code between people mapping MIDI
> controllers and Ctlra supported controllers.
>

Yes, having other types of devices supported via Ctlra would mean a
different type of mapping. That's just the way it is - I don't see that as
a blocker - actually I see it as an opportunity to improve the UX of
mapping a controller.

> 5. TCC is unmaintained. The last release was 4 years ago. If we found
> issues with it, it would probably be upon us to fix them. I for one would
> much rather spend my time working on Mixxx than a C compiler.
>

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.

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_handl
> ers_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.

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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-08 Thread Be


On 07/07/2017 11:37 AM, Daniel Schürmann wrote:
In terms of am everage use, a library is updated by the various Linux 
distros in a two years cycle.


If someone chooses a distro with a slow release cycle like Ubuntu LTS or 
Debian stable they should understand that access to the latest software 
updates will not be so straightforward. Unfortunately, ~2 years has been 
about how often Mixxx releases happen too...


I am in doubt that the manufacturer a will 
ship a Ctlra build along with there hardware.


I don't think this is such a far-fetched goal. Manufacturers have been 
increasingly open about their controllers in the last few years. For 
example, Novation has published firmware for the Launchpad Pro:

https://github.com/dvhdr/launchpad-pro
and Ableton published documentation and a demo application for the Push 2:
https://github.com/Ableton/push-interface
https://github.com/Ableton/push2-display-with-juce

I'd imagine it would be nicer to write code for Ctlra than write a big 
manual with words.


This brings up the question of the license to use for Ctlra. I have 
suggested using the Mozilla Public License. If you have thoughts about 
that, join the discussion on the GitHub issue:

https://github.com/openAVproductions/openAV-Ctlra/issues/9

--
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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-08 Thread Be


On 07/08/2017 04:32 PM, Daniel Schürmann wrote:

I think we have to distinguish between two areas of device depended code.
1. The driver part, which presents the controller in a generic way like 
it already happens with midi controllers
2. The application mapping, to adapt application features to controller 
features.


If I get it right, ctlra aims to cover only 1. Even if we have a ctlra 
controller in Mixxx, we need to adapt the signals to Mixxx Control 
Objects using xml or js files.


 From this point of view, it would be kind of odd to have an other 
scripting engine in action just for 1. If this is also the QT js engine 
this would be great for Mixxx, but not for all other Ctlra using 
applications not Qt based.


I think you are misunderstanding a bit. Ctlra would take care of step 1 
in C, then pass those events to Mixxx.


This is not a biggest issue for me, because even if you know Javascript 
or likewise C, you cannot instantly start over to hack up your driver.
You need a lot of reading and probably reverse engineering, which is 
probably harder than adopt a sample script of a partly unknown language.


This is the benefit of Ctlra. The reverse engineering of the device 
specific bit-level details are abstracted from the mapping developer so 
that mapping an HID device is more like mapping a MIDI device.




IMHO the success of Ctlra depends to a high degree to the numberer of 
supported popular controllers. If we manage to push this number up, all 
the technical issues are secondary. If we fail, Ctlra is just another 
controller interface to support. https://xkcd.com/927/


Thanks for the reminder about that XKCD comic, it has a good point. I am 
leaning towards the opinion that it would be better for Ctlra to focus 
specifically on HID controllers. We already have PortMIDI and RtMidi. I 
don't think we need another cross platform MIDI library. If Ctlra 
presents applications with a MIDI-like event interface for HID 
controllers, that makes it relatively easy for applications to add 
support for such devices by adapting their existing code for MIDI 
controllers. It may be helpful for Ctlra to support a few other non-HID 
devices like the older Hercules and Native Instruments controllers that 
use their own custom USB protocols.




Kind regards,

Daniel










Am 08.07.2017 um 22:00 schrieb Be:
Thanks for taking up this project! Reading your proposal on the wiki 
page, the way you intend to integrate into Mixx's ControllerManager 
and Controller classes makes more sense now.


The big question I am wondering about is the process of creating the 
mappings from Ctlra events to Mixxx's state. Your idea to use TCC is 
interesting and I think it's no problem for a proof-of-concept, but I 
am doubtful it would be a good way to integrate Ctrla support into 
applications for several reasons:
1. Is it possible for a controller mapping to crash the application? 
That should not happen under any circumstance.
2. If a user wanted to replace a precompiled mapping that came with 
Mixxx with one they made or got online, what would that process go 
like? Would the user need to install TCC? Would we have to include TCC 
in Mixxx?
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.
4. Mixxx, and other applications, already have systems for supporting 
MIDI controllers. Like Mixxx, some of these applications already have 
their own scripting environments. Maintaining code and documentation 
for separate ways for mappings to interact with the application would 
be a burden for the application developers. For controller mapping 
developers, their experience would be totally different depending on 
whether they were mapping a MIDI controller or a Ctlra supported 
controller. This would be a barrier to sharing knowledge and code 
between people mapping MIDI controllers and Ctlra supported controllers.
5. TCC is unmaintained. The last release was 4 years ago. If we found 
issues with it, it would probably be upon us to fix them. I for one 
would much rather spend my time working on Mixxx than a C compiler.


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:

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-08 Thread Daniel Schürmann


Hi Be, Hi Harry,

I share Be's concerns about TinyCC compiler. On one hand it is available 
in the Ubuntu repos, on the other hand it is "not recommended for

production use" in the explaining text.

But that is not a big problem. For me it makes no difference if we 
dynamic ling a device.so file generated from TinyCC or GCC.
GCC is available by default and calling it from ctlra or manual should 
not a big issue. We most likely cannot rely on TinyCC for Windows anyway.


I think we have to distinguish between two areas of device depended code.
1. The driver part, which presents the controller in a generic way like 
it already happens with midi controllers
2. The application mapping, to adapt application features to controller 
features.


If I get it right, ctlra aims to cover only 1. Even if we have a ctlra 
controller in Mixxx, we need to adapt the signals to Mixxx Control 
Objects using xml or js files.


From this point of view, it would be kind of odd to have an other 
scripting engine in action just for 1. If this is also the QT js engine 
this would be great for Mixxx, but not for all other Ctlra using 
applications not Qt based.


From this point of view a pure C implementation works probably best.

The other point of view is the knowledge out there among audio artists.
Here are two stats sources:

https://octoverse.github.com/
https://www.tiobe.com/tiobe-index/

> 1. Is it possible for a controller mapping to crash the application?
> That should not happen under any circumstance.

If we go for C drivers, yes. This could be handled by putting Ctlra into 
a quarantine process, but this consumes the c performance gain and would 
put whole Ctlra into question compared to OSC.


> 2. If a user wanted to replace a precompiled mapping that came with
> Mixxx with one they made or got online, what would that process go 
like? Would the user need to install TCC? Would we have to include TCC 
in Mixxx?


Mixxx should already have access to a C compiler, if we decide to go the 
C way. The other option would be to share pre-compiled *.so files.

But they are not cross platform and can contain a trojan.

> 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.

This is not a biggest issue for me, because even if you know Javascript 
or likewise C, you cannot instantly start over to hack up your driver.
You need a lot of reading and probably reverse engineering, which is 
probably harder than adopt a sample script of a partly unknown language.


IMHO the success of Ctlra depends to a high degree to the numberer of 
supported popular controllers. If we manage to push this number up, all 
the technical issues are secondary. If we fail, Ctlra is just another 
controller interface to support. https://xkcd.com/927/


Kind regards,

Daniel










Am 08.07.2017 um 22:00 schrieb Be:
Thanks for taking up this project! Reading your proposal on the wiki 
page, the way you intend to integrate into Mixx's ControllerManager and 
Controller classes makes more sense now.


The big question I am wondering about is the process of creating the 
mappings from Ctlra events to Mixxx's state. Your idea to use TCC is 
interesting and I think it's no problem for a proof-of-concept, but I am 
doubtful it would be a good way to integrate Ctrla support into 
applications for several reasons:
1. Is it possible for a controller mapping to crash the application? 
That should not happen under any circumstance.
2. If a user wanted to replace a precompiled mapping that came with 
Mixxx with one they made or got online, what would that process go like? 
Would the user need to install TCC? Would we have to include TCC in Mixxx?
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.
4. Mixxx, and other applications, already have systems for supporting 
MIDI controllers. Like Mixxx, some of these applications already have 
their own scripting environments. Maintaining code and documentation for 
separate ways for mappings to interact with the application would be a 
burden for the application developers. For controller mapping 
developers, their experience would be totally different depending on 
whether they were mapping a MIDI controller or a Ctlra supported 
controller. This would be a barrier to sharing knowledge and code 
between people mapping MIDI controllers and Ctlra supported controllers.
5. TCC is unmaintained. The last release was 4 years ago. If we found 
issues with it, it would probably be upon us to fix them. I for one

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-08 Thread Be

Thanks for taking up this project! Reading your proposal on the wiki 
page, the way you intend to integrate into Mixx's ControllerManager and 
Controller classes makes more sense now.


The big question I am wondering about is the process of creating the 
mappings from Ctlra events to Mixxx's state. Your idea to use TCC is 
interesting and I think it's no problem for a proof-of-concept, but I am 
doubtful it would be a good way to integrate Ctrla support into 
applications for several reasons:
1. Is it possible for a controller mapping to crash the application? 
That should not happen under any circumstance.
2. If a user wanted to replace a precompiled mapping that came with 
Mixxx with one they made or got online, what would that process go like? 
Would the user need to install TCC? Would we have to include TCC in Mixxx?
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.
4. Mixxx, and other applications, already have systems for supporting 
MIDI controllers. Like Mixxx, some of these applications already have 
their own scripting environments. Maintaining code and documentation for 
separate ways for mappings to interact with the application would be a 
burden for the application developers. For controller mapping 
developers, their experience would be totally different depending on 
whether they were mapping a MIDI controller or a Ctlra supported 
controller. This would be a barrier to sharing knowledge and code 
between people mapping MIDI controllers and Ctlra supported controllers.
5. TCC is unmaintained. The last release was 4 years ago. If we found 
issues with it, it would probably be upon us to fix them. I for one 
would much rather spend my time working on Mixxx than a C compiler.


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
It would be great if we could create JS APIs that are almost identical 
for MIDI and Ctlra.


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
[2] https://www.mixxx.org/wiki/doku.php/ctlra_support
[3] http://openavproductions.com/doc/ctlra.html
[4] https://github.com/openAVproductions/openAV-ctlra

--

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



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-08 Thread Harry van Haaren

On Sat, Jul 8, 2017 at 10:39 AM, Sébastien Blaisot 
wrote:

> Le 08/07/2017 à 03:00, Harry van Haaren a écrit :
>
> On Fri, Jul 7, 2017 at 8:45 PM, Sébastien Blaisot 
> wrote:
>
>
>> Mixxx is a cross-platform application (Linux, MacOS, Windows).
>>
> Is ctrla also a cross-platform library ?
>>
>
> Currently nope, it is a WIP library developed and tested on Linux only.
> The APIs are not
> OS-specific in any way, and the libraries (currently) in use all claim to
> be cross-platform.
> That means *in theory*, Ctlra is cross-platform too, but actually
> compiling/testing/etc is
> required (and as you probably know, that's a huge amount of work :)
>
>
>
ok, so is could be "theorically" possible to have ctrla croos-platform some
> time in the future ;)
>

Yep! And until there is value in actually *doing* it, it will probably
remain theory :D



> If this is not the case, it is a show stopper IMHO.
>>
>
> I understand that for Mixxx it would be ideal if Ctlra supported all
> targets - totally understand.
> As you're aware x-platform development requires significant time, testing,
> and access to the
> platforms themselves. I do not have access to large quantities of time, or
> OsX/Win platforms.
>
> no problem, htat's where the community is helpful : divide time required
> and access to hardware into smaller chunks
>

Good point.


> I'll ask a few questions, just to get understand your point-of-view that
> this could be a show stopper.
> How much of the blueprint / wiki / youtube-video / etc are you familiar
> with? I'd like to avoid
> sweeping the Ctlra idea off the table just because its not currently cross
> platform - even if it is only
> a POC on how to implement hotplug/HD screens, isn't that a valuable
> contribution to Mixxx?
>
>
> Well, when talking about show stopper, I meant that we should not release
> a version of Mixxx with a different user experience on the different
> platforms and that we should try to have a similar experience on all
> platform the most that we can.
> This is my opinion (only mine, I won't talk for others).
>
> My intent is not to discourage you from integrating Ctrla to Mixxx. Each
> feature of Mixxx has started as a POC and has been polished before reaching
> the application and being shipped in a release.
> It's more like a goal to achieve ;)
>
> Sorry if my message sounded a bit rude, this was not my intent. I find the
> idea really interresting.
> We can start on linux only to prove the working of the concept, but I
> think we should resolve the cross-platform thing before shipping a version
> of Mixxx with ctrla.
>

Thanks for explaining your point-of-view more. I agree that having similar
user-experience on different
platforms is a good goal, and adds value to the Mixxx project. I'm working
on an initial set of commits
that I can send for review - with basic functionality (so no TCC etc, just
1 event hardcoded -> ControlProxy).

Once that's in a place where its worth sharing, I'll send a PR to the Mixxx
github, and post on list :)

Thanks for your input - of course when suggesting a new method/library to
> do things, there will
> be "bumpy" parts that need to be worked through, and I appreciate your
> highlighting that in this
> case cross-platform support is likely going to be one of those bumpy parts!
>
>
> that's the point :)
>
> regards,
>
> sb
>

Yep, and its a good point! Cheers, -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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-08 Thread Sébastien Blaisot


Le 08/07/2017 à 03:00, Harry van Haaren a écrit :
On Fri, Jul 7, 2017 at 8:45 PM, Sébastien Blaisot > wrote:


Mixxx is a cross-platform application (Linux, MacOS, Windows).

Is ctrla also a cross-platform library ?


Currently nope, it is a WIP library developed and tested on Linux 
only. The APIs are not
OS-specific in any way, and the libraries (currently) in use all claim 
to be cross-platform.
That means *in theory*, Ctlra is cross-platform too, but actually 
compiling/testing/etc is

required (and as you probably know, that's a huge amount of work :)


ok, so is could be "theorically" possible to have ctrla croos-platform 
some time in the future ;)



If this is not the case, it is a show stopper IMHO.


I understand that for Mixxx it would be ideal if Ctlra supported all 
targets - totally understand.
As you're aware x-platform development requires significant time, 
testing, and access to the
platforms themselves. I do not have access to large quantities of 
time, or OsX/Win platforms.
no problem, htat's where the community is helpful : divide time required 
and access to hardware into smaller chunks


I'll ask a few questions, just to get understand your point-of-view 
that this could be a show stopper.
How much of the blueprint / wiki / youtube-video / etc are you 
familiar with? I'd like to avoid
sweeping the Ctlra idea off the table just because its not currently 
cross platform - even if it is only
a POC on how to implement hotplug/HD screens, isn't that a valuable 
contribution to Mixxx?


Well, when talking about show stopper, I meant that we should not 
release a version of Mixxx with a different user experience on the 
different platforms and that we should try to have a similar experience 
on all platform the most that we can.

This is my opinion (only mine, I won't talk for others).

My intent is not to discourage you from integrating Ctrla to Mixxx. Each 
feature of Mixxx has started as a POC and has been polished before 
reaching the application and being shipped in a release.

It's more like a goal to achieve ;)

Sorry if my message sounded a bit rude, this was not my intent. I find 
the idea really interresting.
We can start on linux only to prove the working of the concept, but I 
think we should resolve the cross-platform thing before shipping a 
version of Mixxx with ctrla.


Thanks for your input - of course when suggesting a new method/library 
to do things, there will
be "bumpy" parts that need to be worked through, and I appreciate your 
highlighting that in this
case cross-platform support is likely going to be one of those bumpy 
parts!


that's the point :)

regards,

sb
--
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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-07 Thread Harry van Haaren

On Fri, Jul 7, 2017 at 8:45 PM, Sébastien Blaisot  wrote:

> Hi Harry,
>

Hey!

> Mixxx is a cross-platform application (Linux, MacOS, Windows).
>
Is ctrla also a cross-platform library ?
>

Currently nope, it is a WIP library developed and tested on Linux only. The
APIs are not
OS-specific in any way, and the libraries (currently) in use all claim to
be cross-platform.
That means *in theory*, Ctlra is cross-platform too, but actually
compiling/testing/etc is
required (and as you probably know, that's a huge amount of work :)

> If this is not the case, it is a show stopper IMHO.
>

I understand that for Mixxx it would be ideal if Ctlra supported all
targets - totally understand.
As you're aware x-platform development requires significant time, testing,
and access to the
platforms themselves. I do not have access to large quantities of time, or
OsX/Win platforms.

I'll ask a few questions, just to get understand your point-of-view that
this could be a show stopper.
How much of the blueprint / wiki / youtube-video / etc are you familiar
with? I'd like to avoid
sweeping the Ctlra idea off the table just because its not currently cross
platform - even if it is only
a POC on how to implement hotplug/HD screens, isn't that a valuable
contribution to Mixxx?

Regards,
>
> sb
>

Thanks for your input - of course when suggesting a new method/library to
do things, there will
be "bumpy" parts that need to be worked through, and I appreciate your
highlighting that in this
case cross-platform support is likely going to be one of those bumpy parts!

Thanks again, -Harry

PS: You've replied to the first email I sent, not the latest email in the
thread, in which I attempted to
explain the value of the Ctlra library to Mixxx - reasons for using C, and
hopefully what value add
the Ctlra library would have for a project like Mixxx. If you didn't see
the newer one yet, perhaps
it is of interest.

>
> Le 06/07/2017 à 23:57, Harry van Haaren a écrit :
>
> 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
> [2] https://www.mixxx.org/wiki/doku.php/ctlra_support
> [3] http://openavproductions.com/doc/ctlra.html
> [4] https://github.com/openAVproductions/openAV-ctlra
>
> --
>
> 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
>

-- 

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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-07 Thread Sébastien Blaisot



Hi Harry,

Mixxx is a cross-platform application (Linux, MacOS, Windows).
Is ctrla also a cross-platform library ?

If this is not the case, it is a show stopper IMHO.

As far as I can see, it only seems to be documented under linux.

Regards,

sb

Le 06/07/2017 à 23:57, Harry van Haaren a écrit :

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
[2] https://www.mixxx.org/wiki/doku.php/ctlra_support
[3] http://openavproductions.com/doc/ctlra.html
[4] https://github.com/openAVproductions/openAV-ctlra

--

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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-07 Thread Harry van Haaren

On Fri, Jul 7, 2017 at 5:37 PM, Daniel Schürmann  wrote:

> Hi Harry,
>

Hi!

> I have looked a bit closer to the concepts of Ctlra
>

Thanks for looking!

> and it has a strong issue: "The device specific files are written in c."
>

Yes it written in C. This is a deliberate design choice, which has various
consequences. Some of them are positive, other are negative.

These are some benefits: performance, availability of various libraries for
device access (bluetooth, MIDI, serial, others), ability to easily create
wrappers to other languages, integration into low-power/embedded systems
(RPi, beaglebone, etc), "lowest-common-denominator" of programming
languages.

Downsides include (as you point out); typically a more static workflow,
slower development pace, libraries update slower (although even if the
libraries were JS, that wouldn't solve the issue, this is a distro
packaging rate issue regardless of what feature/project we talk of).

> In terms of am everage use, a library is updated by the various Linux
> distros in a two years cycle. I am in doubt that the manufacturer a will
> ship a Ctlra build along with there hardware. So it takes about two years
> after a brand new controller reaches the Ctlra shipped with distros.
> Looking at pre-installed default mappings Mixxx suffers the same issue.
>
> There is only a minority of users a talented musician, spending a
> reasonable amount of money for a new controller and a talented C programmer
> at the same time. It is a high hurdle to set up an build environment,
> reengineer the controller, build a library and make it work.
>

Exactly - which is why I feel that unless we integrate this all into a
library that we can all benefit from, the controller situation with the
Linux platfrom will not improve.

> If the user actually manages this, it is another hurdle to bring the
> device specific into a rock solid maintainable state and merge it upstream.
> And even if the user manages all these, the upstream maintainer cannot
> verify the proposed  code, because he most likely did not own the new shiny
> controller as well. Mixxx has the same issue regarding pre-installed
> default mappings.
>

Correct again - which is why we must be vigilant to help contributors who
have devices - perhaps even find a way to collaborate on device support.

>  fortunately Mixxx has a point and click GUI to map even unknown
> controllers.
>

Only for MIDI controllers IIRC? Or does it "magically" work for USB HID
devices too? If so, please tell me more - I'm all ears.

> It provides an outstanding scripting engine that is relative easy for
> simple tasks but has the full power of a Touring-complete language.
> Integrating a brand new hid mapping still requires bit smashing, but at
> least it can be done with a simple text editor, nothing more.
>

So can writing scripts in C, by using TCC and writing "C script files". Its
not a common workflow (yet) but it really is a fantastic way of writing
Mixxx bindings. I know because the POC of Mixxx with Ctlra integration
works beautifully - DJ tracks while updating the mapping for a device using
C as the language.

Did you get the point?
>

I understand your concern yes - and believe me I have thought about exactly
this issue, but stand with the choice I have previously made.

> How to solve this?
>

TCC. TCC allows us to dynamically script in C, removing the issue of
"compiling". If you haven't yet, please look at the video here, where I
demonstrate the value of TCC:
https://youtu.be/-bwynA7HRow?t=2038

> Not sure if it works, but how about benefit from all the work already done
> in Mixxx? Instead of making Ctlra a new controller type in Mixxx we can put
> it between the Mixxx engine an the Mixxx controller mapping.
> This way all openAV apps can benefit from the existing mappings in Mixxx
> and from the sounds scripting language to solve hard issues. Mixxx can
> benefit from modern controller support contributed directly to openAV.
>
> What do you think?
>

I see your point of view - and understand the concern about the work. Yes
there is a lot of work to be done, and it requires both skilled programmers
and access to the device itself. I don't see a method to avoid that -
regardless of the tooling, programming requires skill and that's that.

My reasons for creating Ctlra are more than an attempt to bring more modern
controllers to Mixxx - it is to enable any audio application easily
integrate support for controllers. This means that the device is available
with all its functionality: that includes HD screens and fancy features. I
do not see a way to allow HD screens be updated from JS - another reason
why C is the language I chose for Ctlra.

In short, I think I'm aware of the magnitude of the work required to make
Ctlra a useful library - but I see this as work that can be reused
throughout the community if we design and implement it well, which
ultimately provides more value to the community than

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-07 Thread Daniel Schürmann

Hi Harry,

I have looked a bit closer to the concepts of Ctlra, and it has a strong
issue: "The device specific files are written in c."

In terms of am everage use, a library is updated by the various Linux
distros in a two years cycle. I am in doubt that the manufacturer a will
ship a Ctlra build along with there hardware. So it takes about two years
after a brand new controller reaches the Ctlra shipped with distros.
Looking at pre-installed default mappings Mixxx suffers the same issue.

There is only a minority of users a talented musician, spending a
reasonable amount of money for a new controller and a talented C programmer
at the same time. It is a high hurdle to set up an build environment,
reengineer the controller, build a library and make it work.

If the user actually manages this, it is another hurdle to bring the device
specific into a rock solid maintainable state and merge it upstream. And
even if the user manages all these, the upstream maintainer cannot verify
the proposed  code, because he most likely did not own the new shiny
controller as well. Mixxx has the same issue regarding pre-installed
default mappings.

 fortunately Mixxx has a point and click GUI to map even unknown
controllers. It provides an outstanding scripting engine that is relative
easy for simple tasks but has the full power of a
Touring-complete language. Integrating a brand new hid mapping still
requires bit smashing, but at least it can be done with a simple text
editor, nothing more.

Did you get the point?

How to solve this?

Not sure if it works, but how about benefit from all the work already done
in Mixxx? Instead of making Ctlra a new controller type in Mixxx we can put
it between the Mixxx engine an the Mixxx controller mapping.
This way all openAV apps can benefit from the existing mappings in Mixxx
and from the sounds scripting language to solve hard issues. Mixxx can
benefit from modern controller support contributed directly to openAV.

What do you think?

Kind regards,

Daniel



Am 07.07.2017 1:07 vorm. schrieb "Daniel Schürmann" :

> Hi Harry,
>
> welcome to Mixxx.
>
> That is awesome.  :-)
> A BIG thank you to make this real!
>
> I have just skimmed over the linked resources and it looks like this
> closes exactly the gap between Mixxx and HID controllers.
>
> Currently Mix has HID controller support, but it requires scripting, and a
> lot of bit mashing to make a controller work.
> Unlike MIDI controllers, you cannot learn them via point and click GUI.
>
> You need a lot of knowledge of the interns of the controller.
> It is a great idea to put this knowledge in a single library and share
> these info between all Linux Audio Projects.
>
> Are you going to contribute to Mixxx an work towards an Ctlra interface?
>
> Here are some links:
>
> Our HID API js is described here:
> https://www.mixxx.org/wiki/doku.php/hid_device_api
>
> Which is used for example here:
> https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0f
> fac4b2afd7359afa8a/res/controllers/Nintendo-Wiimote.js
>
> Here is a good introduction how we work in the Mixxx project:
> https://www.mixxx.org/wiki/doku.php/bugfix_workflow
>
> If I understand the Ctlra concept correct, it can finally replace all our
> controller APIs on a long run. On a short run, it can be used parallel to
> portmidi, right?
>
> The portmidi implementation can be found here:
> https://github.com/mixxxdj/mixxx/tree/master/src/controllers/midi
> https://github.com/mixxxdj/mixxx/blob/2cf29ba14da099a9d19f43
> 5a71b2ee95b9f4815e/build/depends.py#L28
>
> Can we roughly name the steps to do? :
> * crate src/controllers/ctlra
> * copy all files over
> * adopt them for ctlra
>
> Of cause there will be a lot more things to consider.
>
> Do you see a chance to port this to Mac and Windows as well?
>
> Kind regards,
>
> Daniel
>
>
>
>
>
>
>
>
>
>
>
> Am 06.07.2017 um 23:57 schrieb Harry van Haaren:
>
>> 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].

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

2017-07-06 Thread Daniel Schürmann


Hi Harry,

welcome to Mixxx.

That is awesome.  :-)
A BIG thank you to make this real!

I have just skimmed over the linked resources and it looks like this 
closes exactly the gap between Mixxx and HID controllers.


Currently Mix has HID controller support, but it requires scripting, and 
a lot of bit mashing to make a controller work.

Unlike MIDI controllers, you cannot learn them via point and click GUI.

You need a lot of knowledge of the interns of the controller.
It is a great idea to put this knowledge in a single library and share 
these info between all Linux Audio Projects.


Are you going to contribute to Mixxx an work towards an Ctlra interface?

Here are some links:

Our HID API js is described here:
https://www.mixxx.org/wiki/doku.php/hid_device_api

Which is used for example here:
https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/res/controllers/Nintendo-Wiimote.js

Here is a good introduction how we work in the Mixxx project:
https://www.mixxx.org/wiki/doku.php/bugfix_workflow

If I understand the Ctlra concept correct, it can finally replace all 
our controller APIs on a long run. On a short run, it can be used 
parallel to portmidi, right?


The portmidi implementation can be found here:
https://github.com/mixxxdj/mixxx/tree/master/src/controllers/midi
https://github.com/mixxxdj/mixxx/blob/2cf29ba14da099a9d19f435a71b2ee95b9f4815e/build/depends.py#L28

Can we roughly name the steps to do? :
* crate src/controllers/ctlra
* copy all files over
* adopt them for ctlra

Of cause there will be a lot more things to consider.

Do you see a chance to port this to Mac and Windows as well?

Kind regards,

Daniel











Am 06.07.2017 um 23:57 schrieb Harry van Haaren:

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
[2] https://www.mixxx.org/wiki/doku.php/ctlra_support
[3] http://openavproductions.com/doc/ctlra.html
[4] https://github.com/openAVproductions/openAV-ctlra

--

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



--
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

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

24 matches

Site Navigation

Mail list logo

Footer information