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

New Backend: "Bevin" #80

Open
15 of 21 tasks
oubiwann opened this issue Feb 20, 2021 · 6 comments
Open
15 of 21 tasks

New Backend: "Bevin" #80

oubiwann opened this issue Feb 20, 2021 · 6 comments
Assignees
Labels
Milestone

Comments

@oubiwann
Copy link
Contributor

oubiwann commented Feb 20, 2021

@gbevin has a couple of open source CLI tools for sending/receiving MIDI:

For situations where these are the only thing needed by a user, Extempore would be overkill (and the bevin backend would thus be quite welcome).

Ideally, we'd be able to start up two OS processes, one for each, put them in the supervision tree, and then pipe (using Erlang ports) commands as needed to these ... will have to look at the tools more to see what's possible. Even without that, though, it might still be worth the cost of an OS process for every command as a tradeoff for the increased simplicity of a backend like this.

Branch:

Tasks/features (some of this might get broken out into separate tickets):

  • Download & install the tools and explore their capabilities
  • Add configuration for new backend
  • Decide upon module prefix (maybe bv?)
  • Update the supervisor to only start the backend that's active
  • Create gen_servers for each, with spawned ports for the OS process
  • Select appropriate restart strategy(ies)
  • Add health checks for ports/processes #87 - Add health checks for ports/processes
  • Convert between time and tempo/beats/notes #83 - Add utility functions for converting from beats, tempo, notes timings, etc., to time strings (of the form HH:MM:SS.mmm)
  • Support MIDI note quantization #84 - Add utility functions for quantizing notes
  • Add support for CC-ramping (knob-turning) #85 - Adapt xt.midi:cc, xt.midi:cc-ramp, etc. for use with this backend
  • Display banner after backend starts
  • Add utility functions for getting CLI tool versions
    • done during system setup, so only one call to get the versions is ever made
    • os:cmd call should probably go in sysconfig module
    • update system state upon bring-up
    • add state-based API call for getting version info from cached data
  • Properly kill OS processes upon exit #88 - Properly kill OS processes upon exit
  • Capture ^C and ^D to exit #89 - Capture ^C and ^D to exit (and kill OS processes) on interrupt
  • Display the appropriate / configured REPL prompt after banner display
  • Add examples

Also:

@oubiwann oubiwann added the epic label Feb 20, 2021
@oubiwann oubiwann added this to the Backlog milestone Feb 20, 2021
@oubiwann
Copy link
Contributor Author

oubiwann commented Feb 20, 2021

Video for setup on Mac:

First 1/3rd is for beginners. Notes on the rest:

  • an Erlang port can read receivemidi's output
  • multiple ccs can be sent at the same time
  • Bidule might be nice to put in the docs to help users more easily set up MIDI on their systems
  • yes! sendmidi -- is supported!

@oubiwann oubiwann modified the milestones: Backlog, 0.4.0 Feb 20, 2021
@oubiwann
Copy link
Contributor Author

If this goes well, I might demo this at the next conference! (CodeBEAM in March).

@oubiwann
Copy link
Contributor Author

@oubiwann
Copy link
Contributor Author

Added a question at gbevin/SendMIDI#29 for guidance in adding MIDI time clock & code support in the backend.

@oubiwann
Copy link
Contributor Author

Basic reading and writing to the open Erlang ports for the OS process is working quite well (as expected). One problem so far, is that exiting the server doesn't seem to be causing the receivemidi process to exit. sendmidi exits just find, though.

@oubiwann
Copy link
Contributor Author

Basic reading and writing to the open Erlang ports for the OS process is working quite well (as expected). One problem so far, is that exiting the server doesn't seem to be causing the receivemidi process to exit. sendmidi exits just find, though.

This has its own ticket now: #88

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

No branches or pull requests

1 participant