Orac on organelle

General discussion
21

I don’t think technically that would be possible…
the issue is to load a preset, it has to hit the filesystem… not only are the presets held in files, but when a preset is loaded - it is potentially loading many new pure data submodule (files) as well…
so although, whilst they feel that they load extremely quickly, in practice there is no way that this could be ‘timed’ perfectly, since that filesystem activity takes an indeterminate time. e.g. we have no idea if it takes 1 or 2 beats, or even an entire bar.

also practically, things like reverb tails, would always be cut…
I tend to stop the audio engine during preset loading, since pure data can create some nasty audio glitches if you rewrite a patch (as orac does) , while its processing audio.

1 Like
22

Hi there,

I just received my E1 mk2, what a great day! So first of all, hello to the community!

I am using Organelle and Orac as well, and being able to control it with the E1 might be a real game changer. So I wanted to ask @thetechnobear , what is the current state of this project? The thread is already quite old, did you ever release a public version of the orac firmware incorporating E1 functionality? Please forgive me, I’m really new to this whole topic, so I might be missing something.

Best regards,
Rudi

23

Hi @daugava, welcome here!

I will leave the orac part for @thetechnobear. I just want to mention that orac integration he worked on was E1 mk1. It needs to be adjusted to get it running on E1 mk2.

There is one major improvement on the mk2. It allows users to have more firmwares uploaded to the controller and switch between them without reprogramming the firmware with the computer. That means you can switch between the “standard” controller firmware and alternative firmwares very easily with a few clicks on the controller.

2 Likes
24

@martin @thetechnobear On the youtube Mark posted, I see blue backgrundcontrols with pink foreground color.

How did you do that?

image
image894×451 91.7 KB

25

yeah… so this all got put on hold…and its not really started up again.

why? well, historic really…
I first did an Orac integration prior to the firmware being open source, basically by re-write a preset, took quite a bit of effort, but was a bit slow - due to the amount of sysex the was going back n’ forth.

so I then re-wrote it all when we could write our own firmware.again a lot of effort and it did work really well… and was what I showed above, and had intended to release.

BUT then the e1 firmware was updated (for good reasons, and it was much better) but it would require a lot of big changes to this work again… and also I was waiting of the e1 firmware to ‘stabilise’
and honestly , I just didn’t have the energy to ‘re-write’ for a third time :frowning:
esp. as Ive got a load of other projects on my plate, and not been doing much with Orac of late, so its kind of ended up on the back burner.

the source code is available, and I guess it kind of builds (though I dont have time to support it)
basically it two parts…

a) custom firmware

I think its the v1 branch, as I think v2, was kind of a start to move towards the later firmware?
(though, it has moved on again since then)

b) MEC
so MEC is the application that runs on the Organelle (or whatever e.g. rPI) that sends the necessary data to the E1 ( using a custom protocol) - I think its on the electraone.1 branch.

(I’d have to double check these branches etc… as its been a while :wink: )

@NewIgnis its custom firmware, so I ‘manually’ draw these elements on to the screen.

so when I did this the firmware api was very low level, so things like parameter display was all part of the ‘midi app’, so I had to do it myself, along with things like ‘window handling’.

I believe this is where the v2 api is much richer… and so ironically, would make writing this part of my firmware much easier… but of course, involves re-writing it all to make use of it… which is where I kind of lost the energy.

2 Likes
26

Thanks for the info @thetechnobear. I don’t believe I will be capable to work on custom firmware myself in the forseeing future, but your explanation of the status quo for sure will be helpful as a starting point if anyone ever decides to go on with this.