On Sun, Jul 9, 2017 at 3:36 PM, Be <b...@gmx.com> wrote:

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

Good question - currently no - but I do intend to add a lookup API. I've
added an issue to the Ctlra repo detailing the current proposal:
https://github.com/openAVproductions/openAV-Ctlra/issues/20

Note that the issue with MIDI using this method was control over colours,
and blinking. Various controllers support that in hardware, and the actual
"note velocity" would be mapped per-device to various colours, blinking
rates etc. There is no way for an application to lookup that info about a
MIDI device, or even know what device it is that its connected to.



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

You mean in the device specific .h files? Device specific .h files is not a
good solution - and I'm working towards removing them. The info should be
provided via API calls, not seperate files that the application must
#include or actually "manually" use. There is some progress here, as in the
POC branch with control-locations being exposed, all device controls (with
ID, name, and position) are available to the application via standard APIs
and struct accesses.

Again, homework assigned to Harry; post up that POC branch on device
control layout info already xD


On 07/09/2017 07:57 AM, Harry van Haaren wrote:
>
>> On Sun, Jul 9, 2017 at 1:23 PM, Daniel Schürmann <dasch...@mixxx.org
>> <mailto:dasch...@mixxx.org>> wrote:
>>
>>     Hi Harry,
>>
>>      > At no point to I think Ctlra will *require* also using TCC. It
>>     just so happens that they complement each other well for my use-cases.
>>
>>     That seams to be a good approach. If the architecture allows to put
>>     Ctlra drivers into runtime loaded object files, it does not matter
>>     which compiler is used and if it turns out that TCC is the best for
>>     our needs on a platform, fine.
>>
>>     > That proposal looks really good. It basically means,  from a Ctlra
>> POV, that Ctlra is plain old C code, and exposes
>>     generic events.
>>
>>     No, not generic events. The Ctlra using apllications should receive
>>     a specific event.
>>
>>
>> By "generic event", what I mean is a specific event type, with a specific
>> event ID. These two combined identify one specific control item on a
>> physical controller device. For example, a specific button (eg Play) sends
>> a button event when pressed / released, using this struct for metadata:
>> https://github.com/openAVproductions/openAV-Ctlra/blob/
>> master/ctlra/event.h#L63
>>
>> Note that the name of the control is *not* included here for performance
>> reasons. Passing strings around just isn't a good idea for performance.
>> Ctlra provides functions to lookup the name of each event based on type/ID.
>> I have "generic" applications (don't care about which HW controller is
>> used) that provide fully labelled UIs showing all control names - so your
>> use-case is covered here. (If there is an issue, we can resolve it at the
>> Ctlra API layer, but AFAIK the API caters for the application's
>> requirements).
>>
>>     If you turn the gain Knob on a controller, the application should be
>>     able to now that this is the Knob labeled with "Gain" grouped for
>>     Deck A.
>>
>>
>> See above paragraph - names of events are provided, based on the labels
>> physically printed on the hardware.
>>
>>     This might be done by a generic event + a link into a manifest file,
>>     which may also include a photo of the controller. This metada of
>>     each event should be optimized to be translated into a OSC address,
>>     this should be a mandatory part of Crtra. So we need a document like
>>     this:
>>     https://github.com/fabb/SynOSCopy/wiki
>>     <https://github.com/fabb/SynOSCopy/wiki>
>>
>>
>> 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/effec
>> ts/lv2/lv2manifest.cpp
>>     <https://github.com/mixxxdj/mixxx/blob/lv2_support2/src/effe
>> cts/lv2/lv2manifest.cpp>
>>     in Ctlra as well.
>>     (Sorry, I am not completely though the API so this might be wrong)
>>
>>
>> As above, I'm not liking the OSC semantic meaning side of things - Ctlra
>> is a C library and provides events. Mapping (to OSC, or whatever) is up to
>> the application. Or if there is value, somebody could create a
>> OscApiForCtlra library - but personally I don't see that as having value at
>> the moment.
>>
>>     We need a kind of generic data point enumerator expression for every
>>     event, which is able to discover all controller features.
>>
>>
>> Ctlra API enables this already. The ctlra_dev_info_t struct has all names
>> of all events, and the counts of each. In the POC implementation, the size
>> of the controller, and control position / size are available as integer
>> values in millimeters. This enables a GUI application to "mock up" the
>> controller, no photos / pictures involved.
>>
>>     Every data point should have a function for examine like
>>     ctlra_dev_get_osc_namespace() and ctlra_dev_get_picture_location()
>>     Will this work? Does this fit to the ctlra goals?
>>
>>
>> I feel the Ctlra API enables the events + physical device info already.
>> Adding OSC namespaces etc above it is not it the scope of Ctlra, nor should
>> it be in my opinion. (Due to not *demanding* applications use any
>> particular form of mapping / interpreting events). Visually enabling
>> controllers is achieved by providing physical layout info of the device,
>> instead of using a photo - a much better solution IMO.
>>
>> Thoughts / opinions? -Harry
>>
>>     Am 09.07.2017 um 13:18 schrieb Harry van Haaren:
>>
>>     On Sun, Jul 9, 2017 at 11:21 AM, Daniel Schürmann
>>>     <dasch...@mixxx.org <mailto:dasch...@mixxx.org>> wrote:
>>>
>>>         Hi Harry, Hi Be,
>>>
>>>         here some comments:
>>>
>>>         IMHO arguing about If C or JS is easier will not lead us ahead
>>>         in this discussion.
>>>
>>>
>>>     Good point - apologies for the rat-hole.
>>>
>>>         > As noted above, we can take TCC off the table for Mixxx's
>>>         use case. Personally I still love it - and it has radically
>>>         changed how I think about programming in C - but perhaps its
>>>         just not a good fit for Mixxx. I can work with that.
>>>
>>>         I am afraid a mandatory TCC based Ctlra solution will prevent
>>>         it from being successful.
>>>
>>>
>>>     At no point to I think Ctlra will *require* also using TCC. It
>>>     just so happens that they complement each other well for my
>>> use-cases.
>>>
>>>         Only a solution that works nice Windows as well as on non X86
>>>         based architectures will be accepted as a new standard.
>>>
>>>
>>>     TCC supports a variety of targets; and despite no official
>>>     releases, the git repo is pretty active:
>>>     http://repo.or.cz/w/tinycc.git
>>>
>>>         For me, the key is here to be modular. Similar to LV2 each
>>>         driver Ctlra driver can be shipped with a source file and a
>>>         meta-data file which should contain a recipe to turn the
>>>         source file into a *.so or a dll. In a future advanced step,
>>>         the hosts Ctlra library code should be responsible to read the
>>>         recipe and do what it should be done to turn it into a binary.
>>>
>>>
>>>     I'm not sure what the benefit is here - i see a pretty complex
>>>     workflow, but no ultimate gain that TCC doesn't already provide.
>>>     But I said I'd drop the TCC idea and discuss other options.
>>>
>>>         > Lets find a better solution for novice / casual users who
>>>         don't want to compile anything.
>>>
>>>         The compile step itself is not the issue. If we look for
>>>         example to OpenGL Shading Language, where we also have a
>>>         compiler step no one noticed.
>>>
>>>
>>>     Good point.
>>>
>>>         >> Even if we have a ctlra controller in Mixxx, we need to
>>>         adapt the signals to Mixxx Control Objects using xml or js files.
>>>
>>>         > Why XML or JS? I see many more options, and just because we
>>>         have existing infrastructure for a similar case doesn't mean
>>>         its always the correct solution.
>>>
>>>         Just because Mixxx is using it right now. It is IMHO not in
>>>         the responds of Ctlra to convert controller events into
>>>         application commands.
>>>
>>>
>>>     OK - then lets investigate this option more. Keep in mind that my
>>>     JS experience is limited, and that I'm not particularly familiar
>>>     with QT/Mixxx's JS engine capabilities.
>>>     I'll post a PR asap that exposes Ctlra events to Mixxx, and then
>>>     see what kind of JS magic is required on top to expose that to the
>>>     JS mapping scripts.
>>>
>>>         > I'm still not convinced it is possible for any
>>>         point-and-click system to fully map most controllers **in a
>>>         maintainable way**. ...
>>>
>>>
>>>         This is should be out of scope of Ctlra.
>>>
>>>
>>>     Absolutely yes - this is outside the scope of Ctlra - at this
>>>     point we are talking about the integration of Ctlra + Mixxx in
>>>     particular. This was noted by a few developers at the LAC too,
>>>     that device access is only a part of the problem. Providing a good
>>>     mapping mechanism is the harder part. But we need step 1 (Ctlra
>>>     device access) before step 2 (easy/powerful mappings).
>>>
>>>         IDEA:
>>>
>>>         Thinking of all of this again, I think this Ctlra project is a
>>>         great chance to fix some issues, existing standards have.
>>>
>>>         * Midi: Midi is that successfully, because it is defined up to
>>>         the Application layer for a Midi-Keyboard. Reusing this for
>>>         other types of controllers works, but pushes it down to the
>>>         Presentation Layer.
>>>         * OSC: OSC fails to define the Application layer. It is
>>>         promoted to be a Midi successor, but it even has no standard
>>>         way to even transport good old midi messages. There are
>>>         approaches to fix this in some OSC namespaces, but this is
>>>         somehow stucked.
>>>
>>>         It would be grate If we could get back to the state of
>>>         original Midi Plug-And-Play behaviour for Midi-Keyboard for
>>>         all type of controllers using Ctlra. If we do this along with
>>>         a OSC namespace for Ctlra, this will be a great benefit and
>>>         probably a very successfully.
>>>
>>>
>>>     Lets see!
>>>
>>>         On a Midi-Keyborad you know exactly which phsical key is
>>>         pressed an how just looking to the midi Message.
>>>         This can be done for Ctlra as well, I we define a message like
>>>         "Gain Knob Deck A 56 %" So a new controller will be instantly
>>>         usable for Mixxx with a basic default mapping. This is
>>>         probably not sufficient, but putting a new function on "Gain
>>>         Knob Deck A" can be done by existing mapping solutions.
>>>
>>>
>>>     Yes, simple "static" mapping schemes can be easily handled by
>>>     mapping event IDs to ControlProxy objects. As Be pointed out, the
>>>     difficult point is layering multiple functionalities over each
>>>     other in a user-workable way.
>>>
>>>         I have these Architectures in mind:
>>>
>>>         OpenAV setup:
>>>
>>>         HID-Controller
>>>                  V
>>>         Ctlra Driver
>>>                  V
>>>         Cltra Lib
>>>                  V
>>>         C Mapping
>>>                  V
>>>         OpenAV App
>>>
>>>
>>>         Mixxx setup:
>>>
>>>         HID-Controller
>>>                  V
>>>         Ctlra Driver
>>>                  V
>>>         Cltra Lib
>>>                  V
>>>         Controller Proxy
>>>                  V
>>>         XML / *js mapping
>>>                  V
>>>         Mixxx engine
>>>
>>>
>>>
>>>         Gnereic OSC setup:
>>>
>>>         HID-Controller
>>>                  V
>>>         Ctlra Driver
>>>                  V
>>>         Cltra Lib
>>>                  V
>>>         OSC Wrapper (process)
>>>                  V
>>>            UDP/TCP
>>>                  V
>>>         OSC to OSC mapper
>>>                  V
>>>         UDP/TCP
>>>                  V
>>>         OSC enabled DAW
>>>
>>>
>>>
>>>
>>>         What do you think?
>>>
>>>
>>>     That proposal looks really good. It basically means, from a Ctlra
>>>     POV, that Ctlra is plain old C code, and exposes generic events.
>>>     The application can interpret those in whatever way it wants -
>>>     OSC, JS/Mixxx, or however OpenAV stuff will end up doing this. It
>>>     keeps Ctlra just generic events, and allows the application to
>>>     solve the mapping problem in its own way. That sounds logical and
>>>     a good abstraction, which is exactly what Ctlra aims for.
>>>
>>>     In order to progress this idea, I'll post code up ASAP, which
>>>     makes the generic Ctlra events available in a callback as part of
>>>     the CtlraController class. After that, the Mixxx/JS components
>>>     must be designed / worked on to fully enable Ctlra in Mixxx.
>>>
>>>     Thanks for all the input - we seem to be converging on a solution,
>>>     great! -Harry
>>>
>>
<snip a whole lot of backlog - its available in ML archives anyway>

-- 

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

Reply via email to