push 1 support
Ive answered this a few times…
push 1 and 2 are completely different beasts to code, as different as a launchpad and a keyboard 
so the push 2 code will not work with the push 1, due to the display.
could the push 1 be made to work, yes… but I dont have a push 1 anymore (I traded it for the Push2), so there is no way I can do this.
UI for editing Orac presets
the intention is to use a remote interface - Ive supplied a pure data remote control and one for lemur, but you could use others - I think someone here (read this thread, its got a ton of info) had a web browser implementation.
could you run the pure data remote control on the rPI itself, yes… if you want to start X server.
why doesn’t Orac have a UI
Orac was not designed to be a desktop synth, and I dont really have any interest in taking it this way - there are so many options for this e.g. sunvox is fantastic.
rather it was designed to be used headless, so without attaching a monitor,keyboard and mouse to your rPI. hence the ‘remote interface’ concept, and things like Push2 support.
for sure the ‘remote interface’ could do with more development, Id actually hoped that the community might do more in this area - alas, I dont think any developers had interested in it, so it kind of languished a bit… this was most noteable on the rPI since other platforms like Norns/Organelle have a UI.
so I do fully recognise its not as plug n’ play, end-user friendly as I set out for it to be.
one point to note, since I released Orac 2 , and the videos in this post - Monome released a rPI Shield version of Norns… which is considerbly cheaper - and I created a version of Orac that supported this.
I also have support for another rPI option, which I’ll be announcing soon
future of orac
recently, most effort Ive spent on Orac (excluding support) has been on adding new platforms.
(as I said, a new one is nearly ready …)
I do recognise there are a few areas that could do with a little ‘love’ - the remote UI is functional, but is a bit ‘meh’, the modulation needs improvement… I think generally the issue on a ‘raw rPI’ is that it needs a second ‘iteration’ to reach the maturity that Orac has on say the Organelle, Norns.
however, Im busy on other projects at the moment… Im doing some open source stuff surrounding Eurorack, and also currently updating a few of my projects to handle apple silicon.
from there I need to think about Orac, and where to take it…
some of this is back to basics…
Orac has been pretty popular, and what Id like to do is focus on why is that?
there are so many options out there, why are users choosing orac?
(on the Organelle, custom modules have become a thing… not so much outside the Organelle)
on the flip side, one of its ‘problems’ is hightlighted in this post… as one developer, its not practical to develop lots of different versions, or support devices/controllers I dont have.
so what exactly should it target.
reality is, Id say 90% of users that use Orac regularly are using in on an Organelle…is that due to its completness? or its ‘maturity’? or what?
answering these questions will help me focus on - what next? should I refine orac?
should I write the ‘next thing’ ?
(I’ve got a lot of idea on both of these approaches… so once I have the time, I’ll work this out )
time for an upgrade
home/media/orac/usermodules/