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

[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 

[Mixxx-devel] Ctlra and Mixxx PR

[Harry van Haaren]

Hi All,

The topic for this thread* is to discuss the current design of Ctlra
integration as per the PR on
github, and to discuss concrete next-steps to work towards a POC that
enables users to script
or map in some way the Ctlra events to the Mixxx ControlProxy objects.

The PR is here, and a youtube video explains the current state:
https://github.com/mixxxdj/mixxx/pull/1308
https://www.youtube.com/watch?v=sNC4r7-TB0Y

Thanks for looking, and as always if you're interested, please do post!
-Harry

* The topic for the other thread is much wider, I'd like to keep scope
small and concrete here if possible.

-- 

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

[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

[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

[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

[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

[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

[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] Ctlra and Mixxx PR

[Be]

Hi Harry,
We typically keep discussion about code on GitHub pull requests and use 
the mailing list for broader discussions that don't specifically 
reference code.


On 07/09/2017 01:59 PM, Harry van Haaren wrote:

Hi All,

The topic for this thread* is to discuss the current design of Ctlra 
integration as per the PR on
github, and to discuss concrete next-steps to work towards a POC that 
enables users to script

or map in some way the Ctlra events to the Mixxx ControlProxy objects.

The PR is here, and a youtube video explains the current state:
https://github.com/mixxxdj/mixxx/pull/1308
https://www.youtube.com/watch?v=sNC4r7-TB0Y

Thanks for looking, and as always if you're interested, please do post! 
-Harry


* The topic for the other thread is much wider, I'd like to keep scope 
small and concrete here if possible.


--

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

[Mixxx-devel] Proper way to update PR's

[Waylon Robertson]

What is the proper way to update to master, for the pr's ive got
integrated into my source?
my source was created by first git checking out the master.. then i
pulled in ratings, git git pull with the pr number. Then i merged
master into it. I git pulled the WriteAudioTags pr, switched to it,
git merged ratings into WriteAudioTags, then i branched again, to
implement a local patch. Now, how do i bring all my PR's up to date?
or is it easier to restart my source from scratch?

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