I spend a lot of time writing documents to myself.    I have several "object oriented" design and architecture documents in the works, that i've started, around this general project.  

The main problem is that the project domain extends in so many directions, on so many dimensions, at the same time, that it has become difficult to manage, and that has somewhat affected my motivation to keep pressing forward.

The last few months have seen me mostly playing with 3d printing, and most recently, blowing the dust off of my existing rig in the Synthbox 1 project.  In doing so I've been practicing with the old rig, using Quantiloop Pro on the iPad as my looper.  In this configuration I keep running into the limitations in that software regarding switching between sequential and parallel looping between songs and adding and controlling layers in sequential loops.

So, I think the next push will be to make a simple proof of concept Looper.   This looper *should* be as functional as the existing Quantiloop program and steer away from introducing new paradigms for control and layering except to address the actual issues I am experiencing using said software in actual live gigs.

I envision a 4x4 (four sequences with upto four layers per sequence) looper, possibly with a dedicated designed and printed foot contorller.

Even so, architecturally, from a software perpective, this next step in the project is challenging. 

I never said my goals were modest **, and the result is that I have bitten off a tremendous amount to chew.   This bare metal v-guitar project, as it stands, has expanded outwards in many different dimensions, and frankly, is becoming difficult to manage.   Here are some of my main feelings at this point:

• The "arduino" framework for static initialization of the audio system is an artifice that does not blend well with Circle's run-time creation and initialization of the Kernel.   There's a fair chunk of complexity solely related to orchestrating run-time initialization of statically declared objects that could be removed.   This paradigm also constricts the ability to create more flexible audio configurations at run time.   While appropriate for the Arduino, pre-defining all of the audio connections and routing at compile time may not be the best way to go, moving forward, for this project.
• The goal of creating an event driven windowing system, though fine as it is, and workable for simple applications, itself needs a lot of effort.  Additional types of controls (sliders, knobs, and the all important vu-meter) need to be created.   Secondly, although I think not a show stopper for dedicated applications, the implementation is not a completely generalized windowing system with regards to clip regions and underlying window updating.    It works fine as long as there is only one window, and possibly a dialog up over that, but does not implement clipping and real-time updating of hidden or partially obscured windows.  So, for instance, a vu-meter, without kludges, implemented in it, will stop updating if a dialog window is popped up over it, partially obscuring it.   A real-world example application might reveal how important, or not, this is.  It is an area of the code that I really don't enjoy working on, and I do have concerns that a robust implementation will have performance effects, especially on non-optimized display hardware like cheap touch screens or LED arrays.
• Since I started the project, RST has released another 3rd party add-on UI library that is far better looking than mine or the previously available UGUI.   However it suffers both from the same structural flaws as the other Circle provided UI libraries (it is linked directly to the rPi screen and Circle USB mouse/touch devices and is not well generalized to other displays and input devices).   This is compounded by the fact that I could not get RST to include base class generalizations to those devices in the upstream codebase.  So, if I want to use this I will have to further diverge my Circle codebase from his, which is not a prospect I relish, esp, as for example, he has now come up with rPi4 support, and I have to re-merge all of my changes with his.
• I had only made a fledgling start on the midi/event subsystems that glue everything (the audio system, input devices, and the UI) together.  Even for a proof of concept looper I will have to address that and make design commitments with regards to how that's all going to work together.
• The realization, or reminder if you will, that in live performance settings, I really need good feedback, both on a tablet on a music stand, as well as on the floor where I have to look to move my feet, about what the system is doing.   To whit, all the ws2812b and display devices explorations and sub-projects.  I still have a number of devices, including a very cool 2mm RGB LED array to mess around with that I've not even tested yet.  Likewise, I have a nice mounting system (adafruit) for the rPI 7" screen ... still in the box ... that I should break out, even though I do all my development on an large HDMI TV screen.   At some point I have to start getting some real world scale into the hardware and get something I can actually put on the floor and test.
• And finally, I still have not completely come down on where I think a Teensy will fit into it, though my gut feeling is that there will be at least one of them in the system.   The rPi's GPIO is too limited, and, at a minimum I will need an expression pedal convertor somewhere in the system that uses analog inputs, of which there are none on the rPI. And the Teensy  is just so accessible and useful.  I *still* toy with the idea (and need to test) using it in a floor controller with a serial interface to the rPI (not necessarily MIDI) and whether I can usefully do that with a 6 or 10 foot serial cable.  I have many concerns about Circle's ability to handle multiple simultaneous MIDI devices in the context of the UI and audio processing on the rPI.

Without even getting into the synth or guitar effects parts of the project, a looper seems like the safest, as well as simplest, application that I can move forward on.    For testing I can continue to use the iPad synth (Sampletank 3) or even just the straight guitar, as input, as I keep exploring those avenues (including messing around with the Zynthian that I built, and/or building my own guitar effects).   I *could* even end up using a commercially availalble  guitar effects pefal, like a GR3X effects pedal, with such a proof-of-concept, dedicated, looper, if I wanted to.

And in spite of the fact that I have an AudioInjector Octo (6-in, 8-out) sound card working, it may be too much initial complexity to try to also incorporate the extra dimension of controlling and utilizing multiple inputs and outputs into and out of the looper in a proof-of-concept design.   So, I think the initial looper will probably just be stereo-in and stereo-out ... only on the guitar/synth .... not the vocals, or additional inputs like mics on the bongos or steel-pan, like I think could potentially happen, and be really cool, in the future.

--------------------------------------

So there you have it.   A pep talk to myself.   If anyone is following anything I'm talking about, I appreciate and welcome any and all comments and suggestions.

Thanks!

- Patrick

** asterisk :-)  .... essentially I am writing an operating system for the rPI.  Not really where I thought I would be after 9-10 months on the project.