Initial MIDI module implementation

[JessyJP]

A working midi module. It does what I previously demonstrated via external HTTP translation but this thing is much better. It's faster and it loads up with Quelea. Right so:

• The midi module class that is initialized in Main.java, similar to the server, i.e try-catch no problem it fails etc.

  • There are 2 classes in the file (actually 4 in total).
  • MidiEvent which is a struct class.
  • The mouthful MidiInterfaceConnector is the handler. There are 2 implementations of MIDI receiver and transmitter.
  • The receiver is implemented the transmitter is not. I made a function for each because I assumed later, people might want to use different midi devices for in and out.

• The module attaches to an existing device i.e. you need loopmidi for a DAW. But that means you can directly attach to a midi controller.

• NO GUI for now but everything works. (Ummm, I haven't tested it all actually, but it uses the RChandler)

  • The GUI could be implemented and I actually started working on the panel but I am not too familiar with that side. I will probably need a template. This is something that should be seriously discussed by the users though.

• The transpose song function needed an overload.

  • The overload could be called in the one that gets the Http ... inside the other one for simplification. (that's optional)
  • //songEntryWindow.saveSong();This one is a bit confusing for me I haven't checked what exactly what saves what. Technically here is what should happen.
    • Whenever you make a direct call for transpose from the main window you probably want to save that.
    • Whenever you press transpose from a MIDI controller or remote etc. you probably don't want to save that... Rather it's a matter if it should be in the database or not. In live you don't want that in the database. At best you want that in your current schedule but not in the database.

• The rest is the properties section. Notepad++ is amazing, wow writing code vertically? Amen!

  • Each property has 4 parts as it says in the comments. That's handled by MidiEvent.

---

So that's the prototype. Works awesome. The more complicated part is how to decide on the MIDI out.

• I think first we should discuss the MIDI in.
  • Should there be an individual channel per event or a global midi channel I will propose a GUI template that I will smack real quick in Matlab and share here:

The matter of the differed output is a feature that will allow Quelea to act as a controller for other software. So Quelea makes a MIDI request rather than change, and then the other software updates quelea. Hence, you use quelea as normal but multiple things could happen. We can talk about that later. For now, this is the standard thing that I think most users would expect.

[JessyJP]

Ooops apparently can't rename the branch after making a pull request.

[JessyJP]

The second commit is to improve the close functions.

[JessyJP]

Improve the MIDI module and preparing all output midi relevant methods.

[JessyJP]

• The transmit connection is improved.

• Get MIDI-ready state functions added

• QueleaApp now has access to the Module with get and set functions.

  • Get called in the main.

• Send midi message prototype overloaded made

  • It uses the device previously stored

• Null Checks, initialization/reinitialization improved and reset to Null for the devices and the receiver.

  • Actually we don't need to store the device instances. (we can find them again). Also, once the transmitter and receivers are set then later they can be reset. But since for both in and out the open() function is called we use those handles for close(). I wonder if we really need to open and close them though. It will work without that also ( I think )

• sendMidiEvenMsg overloaded. One internal version and one with external velocity. (i.e. Data 2)

• Set defer to disabled by default for now.

• COPY-PASTE to any handler handle function the snippet that sends midi and interrupts. Only the relevant key needs to be changed. The snippet could be put into a function but it is meant to interrupt the calls to the RC in deferred mode.

• Soo this could be a function like : public/private boolean handleMidiSend(String Midi Event , int velocity=0){ // The snippet here return isDeffered; } or could be: that deffer is simply called externally .... ahhhh right String ip = he.getRemoteAddress().getAddress().toString(); if (!isDeffered(ip) && RCHandler.isLoggedOn(ip)) That would be much more elegant. That part is more invasive so it can be discussed.

  The defer control mode a unique feature that is not implemented in any other presentation software. The relevant calls do not make changes to quelea but inform another software that such change is requested. Then the other software makes the changes to quelea. Also, the feature has to be added to the quelea mobile app. For it to work as expected.