search

openAVproductions / openAV-Ctlra

A plain C library to program with hardware controllers.
BSD 3-Clause "New" or "Revised" License
78 stars 16 forks source link

user preferences #10

Closed Be-ing closed 7 years ago

Be-ing commented 7 years ago

It would be nice for mappings to be able to support preference options. This would let users customize their workflow somewhat without needing to program. I don't know if it would be a good idea for Ctrla to handle persistent storage for those preferences or if it would be better to expose an API to the host application so the host application can integrate it with whatever preference system it uses.

harryhaaren commented 7 years ago

I'm leaning towards "UNIX Philosophy" of do one thing do it right. That means "device access abstracted to generic events" and feedback to the devices - but only that and what really relates to it (device metadata, physical layout etc). I don't see Ctlra having "preferences" - it has some options for developers to use (things like using a global or per-instance libUSB context) but no user-preferences. Thanks for the input - marking closed.

Be-ing commented 7 years ago

I'm not sure you're understanding the idea here. What I mean is exposing options to users like what you can find in Traktor's preferences for each of Native Instruments' controllers. In Mixxx, mappings have been using JS variables declared at the top of the source code file for this, which is better than nothing but having to edit a text file is not a great user experience. Sometimes these are used as quick hacks around functionality that is not implemented in Mixxx, but ideally they are used to support different device-specific ways of interacting with the controller without the user needing to edit the mapping. Refer to the Mixxx wiki pages for some controllers for examples: https://mixxx.org/wiki/doku.php/pioneer_ddj-sb2 https://mixxx.org/wiki/doku.php/hercules_p32_dj

harryhaaren commented 7 years ago

I'll re-open and lets figure this out, apologies for closing before discussion was concluded :)

I understand what you're saying about the "user preferences" - they are variations in e.g. the feedback LED mapping between Mixxx's state, and the LEDs on the device.

What I am proposing with the Ctlra API is at a Generic Event level - so there are no mappings here. The mappings (how they are done, what language they use, etc etc) is all up to the application. That means that the actual mapping logic is not part of the Ctlra project.

As mentioned in para 2 of this comment on the "Goals of Ctlra" thread, providing a mechanism to map Events from Ctlra into the Application is a large problem, and something that also needs to be solved.

My opinion on this is that it should be a separate project, that is not required to be used by Applications using Ctlra. I think you suggest something similar in a comment somewhere - don't recall exactly which topic/comment, sorry :)

TL;DR: Yes mapping is a problem, I think Ctlra should only provide device access, and another project should address the mapping between Ctlra <-> Application.

Be-ing commented 7 years ago

Okay, now that you've clarified the scope of the project I agree that this is out of scope.