Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cabl client interface #13

Open
quasart opened this issue Jun 19, 2018 · 0 comments
Open

Cabl client interface #13

quasart opened this issue Jun 19, 2018 · 0 comments

Comments

@quasart
Copy link

quasart commented Jun 19, 2018

Hello,
And first of all, thanks for your work :-)

I own a Maschine MK1 controler, it's a very nice hardware and I would love to use it more.
I found out your nice reverse-enginieering and abstraction project, and I'm looking forward trying your lib.
I'm reading the code now, and would like to share some feedbacks and enhancement proposals (enhancements I may develop myself)

I see two uses-cases for cabl :

  1. Wanting to bind any controller like a gamepad (for example 4 buttons and 4 knobs), ignoring hardware labels

  2. Making a music software.

  • Labels on hardware are very convenient : "Volume" knob should control client volume on every device.
  • On key pressed, client wants to know what note it was.

As a reminder, here is the current abstraction interface :

Client.h

  virtual void buttonChanged(Device::Button button_, bool buttonState_, bool shiftPressed_);
  virtual void encoderChanged(unsigned encoder_, bool valueIncreased_, bool shiftPressed_);
  virtual void keyChanged(unsigned index_, double value_, bool shiftPressed);
  virtual void controlChanged(unsigned pot_, double value_, bool shiftPressed);

My remarks:

  1. First use case is impossible to implement properly :
  • because Client developer doesn't know which Device::Button is available on actual user hardware.
  • About knobs and key, client may choose to listen to knob 0. However, does abstraction guarantee that ids should be contiguous and starting at 0?
  1. About 2nd use case:
  • When pressing shift-Play, the client will observe Device::Button::Play, however shift-Play is labeled "Metronome" on Maschine MK1
  • There is an enum for button but not for encoder (Client cannot know changed encoder is the one labeled "MainVolume" on the device)
  • The Volume may be controlled by an encoder on some device and by a pot on others.

Proposed interface:

virtual  void  buttonChanged(  unsigned  button_,  bool    buttonState_,     bool  shiftPressed_, Device::Label label_ );
virtual  void  encoderChanged( unsigned  encoder_, bool    valueIncreased_,  bool  shiftPressed_, Device::Label label_ );
virtual  void  keyChanged(     unsigned  index_,   double  value_,           bool  shiftPressed_, Device::Label label_ );
virtual  void  controlChanged( unsigned  pot_,     double  value_,           bool  shiftPressed_, Device::Label label_ );

the button/knob parameters would be integers in range [0..NbOfButton[, [0..NbOfEncodor[, [0..NbOfControl[

Device::Label would be an enum with all common Labels. pressing shift would change label_ value (but not button id)

Key index_ could simply be value of a MIDI note. Device implementation should choose the best octave range, but we could required them to implement at least C4.

Unfortunately, this change is a serious interface break for legacy clients.

I hope I'm clear.
Let me know what you think about this analysis, if I'm missing something, if your plans are incompatible with this proposal, or if I should start coding :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant