Im not really replicating any work, as most of what Im using has been part of MEC/Orac for a long time (it existed prior to norns being released 
)
integrated engine - yeah, I understand from your perspective how this is desirable, as I kind of have the same approach with MEC (it can support multiple running Racks, which could be written in any language)… and I suspect I could ‘bridge’ my architecture into your engine (when it exists)
however, at least initially, this is not my preferred approach.
the reason is simple… Orac/MEC are cross-platform, they already run on Organelle/Eurorack/rPI/Mac etc.
so I rather see Fates as an additional platform, a derivative of my existing rPI platform.
Im used to doing derivatives… (Nebulae is also a derivative off rPI) and there will be likely be more
e.g. im considering doing the same for Zynthian
I see Fates as a hardware ‘hat’ for a rPI, a concrete UI to develop against, in similar way to the Organelle - rather than a ‘clone’ of norns (some how reliant on the norns software)
what’s my approach?
well you may or may not be aware that i did a lot of the work for the Organelle OS 3.x releases,
in particular changing C&G ‘launch menu’ to be able to launch patches of different types, rather than just Pure Data.
so this is the approach I want to take with Fates, one where arbitrary apps can be started/stopped from a central launcher ‘app’
more details, probably too much for many readers ;)
so, there will be a ‘background’ launcher process, which will provide users with a list of ‘applications’ to run, Norns and Orac will be just 2, but anything can be launch from this menu.
the way the user will ‘see’ this is
on startup the launcher will start the last used application (so if you only ever use norns, you wont ever see it) … unless you hold down B1, in which case it will bring up the menu instead.
once an application is launched, you use as normal
each application will have a simple message/option that will exit.
the launcher will then come up with a list of apps to run from which the user can choose.
(maybe some other settings/options to e.g. shutdown)
thats it - simples
this allows for there developers to release any apps they want to run without having to conform to anything.
how do I access access the display/encoders/buttons… directly
Ive actually written a small c++ library (FatesLite) what abstracts the hardware, which is what Ive integrated into MEC… but also could be used by other applications if they so wished.
very simple api, that provides display functions, and a properly threaded implementation for the GPIO.
PD does not access the display directly, as Orac is (like norns) based on a headless model for the sound engine - and MEC (written in C++) does the UI work. (similar role to matron i suppose). the communication if via OSC, but is abstracted by my Pure Data external which interface with my ‘Kontrol’ architecture (a kind of distributed parameter model ++ )
that said, I will probably do a quick PD wrapper for the FatesLite api , as its minimal effort.
the above needs a small change to Norns to allow the ability to ‘exit’, which I will do in my fork.
I do things in a compatible way, so maintenance is not an issue.
the other interesting change I have planned, is to update the display implementation.
as I currently also use Push2 as a display for Norns - Fates now brings in an interesting dimension “dual displays”.
so my plan is to allow the Push2 to be used as
- a mirrored display of the Fates (this is kind of what I have now)
- a dual (compatible) display … most like patches can be pushed to Push2 , and keep menus etc on Fates internal display… perhaps also lua support to control this.
- native push display… already there , a full RGB hi-res display that patches can access directly.
Im quite excited by this, as a secondary display would be super handy for many patches.
none of this means I disagree with your intent on an integrated engine - I think its a valuable addition to norns to be able to write engines with other backends (as i said, something Ive also planned for MEC)
however, I also appreciate the more ‘open approach’ that C&G have taken where you can launch anything you like … and that ‘application’ has full control over the hardware, and doesn’t have to ‘conform’ to a particular architecture or api.
something Ive learnt from the Organelle is some patch developers don’t want the complexity of having to implement modules within Orac (which requires known of the 'api/framework)
rather, they actually prefer the simplicity of just writing simple plain vanilla Pure Data code that does everything in PD (e.g. drawing to screen) … this is why Im planning on the Fates PD external to make this an option too.
I guess it’s where ‘us’ engineers have to be very careful,
we tend to love the beauty of apis/frameworks - we appreciate the consistency, the ‘re-use’, the thoroughness - but we don’t see the complexity, because we are so used to dealing with them.
anyway, thats the reason I want a launcher,
so non-developers can just hack stuff together, with simple tools , no complex frameworks/api … no necessity to learn another toolset, they can use what they already know and love(*) - and then easily launch it from the hardware.
sure, from an ‘engineering’ standpoint this is sub-optimal, but Im not writing this for engineers!
anyway, I don’t want to hijack this thread about this topic… as this topic is more about a hardware implementation… perhaps for further discussion, this is better discussed on the Orac topic or another topic?
p.s. Id point out none of this is contradiction with an integrated engine in norns, both can live side by side and actually compliment each other … and as i said, as such the launcher is not seen unless ‘invoked’.
however, I suspect it might be contrary to your ‘vision’ of norns… so unlikely something you’d want to bring in ‘as standard’ - thats cool too. Im perfectly happy for my work to continue to live separately.
(*) no reason for me to not add support for other languages to the FatesLite api e.g. python / sclang / csound - id prefer to offer choices, rather than be ‘prescriptive’ on what you write your stuff in
