there are a few options 
first, I recommend you get used to Orac using the the remote display options Ive provided for the rPI,
as its important before you do any kind of implementation that you understand Orac from a user perspective quite wellā¦
once you have done that, you will understand MIDI is used for notes, and also midi learn of parameters - this is a āuser levelā function, there are also some extras for mapping things like Aux key and expression input etc. (see router)
the principle idea being you can control Orac āheadlessā
then we move on to āproviding a UIā , this covers everything from controlling parameters, to selecting new modules, saving presets etc etc etc.
here there are currently 2 optionsā¦
a) quick nā simple - OscDisplay
this is the interface the Lemur and PD client patch use, its very simple to use, since basically you can send and receive OSC messages to just control the āmenuā and parameters.
but its kind of like a ādumbā client - the workflow is already dictated, you dont have to be concerned really with how Orac work, or providing a UI for browsing modules - its all done for you.
Iād recommend you start with this one, to just get you goingā¦
(itāll also means it feels very similar to organelle etc)
so the limitation of OscDisplay , is it makes lots of assumptions about how Orac is going to work, and how the workflow is⦠e.g. a central menu - this is what makes it so quick to build new clients,
you only need to deal with a few messages and bang you have all the functionality of Orac
b) full OSC control
Orac itself has a full OSC implementation to do pretty much everything, this is actually what MEC uses to talk to Orac and then is able to implement OscDisplay, and also a Push 2 interface.
this OSC interface makes very few assumptions on how you are using Orac, so you could do things like have multiple displays - or make use of dedicated buttons⦠have a display of arbitrary size.
(if you look at my Push2 demo, you will see that the UI on the Push2 looks nothing like the Organelle UI)
the downside is there are a lot of messages, and currently as Im the only one using it⦠its not documented that well⦠so you pretty much have to grok the code, or use something like oscdump to see what messages are flying.
also⦠your āappā will need to be able to handle state e.g. meta data is sent about what parameters there are on a module, and what modules are available - you need to be able to keep that, for display purposes. (whereas OscDisplay is āstatelessā so much easier to use)
if you are going to use this OSC interface, youāll also need to have a much better grasp of how Orac is used, and also a little more about how it works.
do you need to put your extra code in MEC? no not really, but if you know C++ it might be easier⦠as you could potentially reuse some of the existing code there - e.g. you might find some of the āstateā handling useful.
as with all programming, lots of different ways to do it, depends on your skills, and time available and how āintegrated you want itā on which way is best for you.
a couple of small notes:
- Iām going to be adding supports for Fates shortly, so the implementation of that may give you some ideas.
- I plan to reorganise the MEC device code (OscDisplay/Push2/Organelle) a little bit in the future, to make them a little more consistent, and allow them to either live in MEC or PD directly (in KontrolRack)
- I donāt have much time for support of this till about Mid Sept due to other projects
- I know I should write up the OSC messages, and I plan too - but its not happening for a while, due to my other commitments.