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