Ambika XT - how much processing power is left for it?

Hi everybody!

First of all: Thanks @Pinchenettes for making your hard work open source - I spend a fairly decent amount of time scrolling through the code and schematics and it is first-class! Very readable, hackable, even portable! Makes me immediatly want to build the stuff and start modding!

Now to the topic: I’ve been lurking around here for quite some time - got very interested in the Ambika and the Shruthi XT (for its nice interface). Then I thought: Why not combine both worlds and make an Ambika XT?
I know this has been discussed before and people say it probably doesn’t make as much of a difference for the Ambika as it did for the Shruthi. Yea, that’s right, but the open-ness of the hardware and code just makes my hands shaking to try it out!

I know that all the uCs in the Ambika are pretty much maxed out - I programmed a lot of Atmel chips before and know about their performance. Its amazing how much functionality the firmware manages to put into those little controllers. So before I start creating test boards and circuits, I wanted to ask, if there is even enough power left to implement a larger control interface like the Shruthi XT…

My concerns are:

  • Is there enough RAM free to implement the necessary buffers for the potentiometers?
  • Is there enough flash free to implement the scanning algorithms?
  • The UI is scanned in a timer with a rate of 4,8kHz (according to the comments in the code). Does the timer interrupt allow for multiplexed pot-scanning? (I mean: are there even free cycles for processing?).

I really can’t estimate how much ressources are free for a larger control interface. Maybe someone could give me a hint here!

Thanks in advance,

Hardware ports: DOABLE

Currently, the 8 pots on the front panel go into the 8 channels of the 644p ADC mux. Instead, you could use the same scheme as on the Shruthi XT - use 5 or 6 pins to generate addresses and INH for 4051s, and mux everything onto one line. Keep the internal ADC locked to the same channel and mux outboard.


This is really not much overhead, if you accept the lower scanning rate. 4.8kHz / 48pots = 100 Hz per pot (let’s say you add 40 extra pots).

You can probably improve things by using the same scheme as on the Shruthi XT - scan the most recently active pot at 2.4kHz, scan the rest at 2.4kHz / 47.


This is just 1 byte per pot but we’re that close to the limit. You would have to kill the sequencer or things like that.


You would need 500-600 bytes of code. Again, killing a feature would help.

1 Like

Ah, just what I expected… Killing the sequencer sounds like a solution, but hey - the sequencer is a very nice feature…
Arrrr, what a pity…
I could use another uC in conjunction with the extension port though.

Another solution might be to port everything to a midibox core module. I have an STM32 flying around with no use. Since you abstracted the hardware layer very well in the code, it might be doable with relatively little trouble. The midibox framework has some nice timer tasks that could work as a replacement for the timer ISR you used. However, I don’t know if the default makefiles support c++ - at least I could try it. Oh and the whole PROGMEM stuff is probably not portable as well…

Whatever - thanks for your really fast response. I’ll see what i can do.

PS: Just received a Shruthi kit - amazing packaging with the quickstart guide! Cool!

Just realized that the PROGMEM is not even necessary for STM32 and gcc. A simple const seems to be sufficient.

I am not sure how far this is possible, but wouldn’t it be possible to offload UI / interfacing to another microprocessor and communicate changes to the existing microprocessor? Then you are free to do whatever you want (eg. sexy graphical Oled screen) with tons of buttons. It would mean to rewrite the UI code though, but it seems to have been nicely abstracted as far as i can see on github.

I would love to see an Ambika XT version with a nice screen similar to the Prophet 12 / Waldorf Blofeld.

> wouldn’t it be possible to offload UI / interfacing to another microprocessor and communicate changes to the existing microprocessor?

Sure! But then we would need to develop a communication protocol that allows parameters on Ambika to be externally controlled. Technical tip: for this, maybe it would be nice to use a 5mA current loop, opto-isolated… With DIN-5 connectors. 31250 baud serial. 7-bit data, and the 8th bit set occasionally to indicate a command byte! We could call this the “Mutable Instruments Data Interconnect”.

Hihi. :wink:

>We could call this the “Mutable Instruments Data Interconnect”.

Please can we have this Engraved on the next Batch of Cases ?

:slight_smile: :slight_smile: :slight_smile:

What will be the first two devices to communicate with this brave, new protocol?

I tested my BCR2000 with it’s unofficial support via this secret patch and an Ambika 20 minutes ago. It worked well :smiley:

You used a Berhinger! How uncouth!
Seriously, I owned one of those for three hours before it died on me, never to work again…

Why do you guys always buy that crappy Behringer stuff and wonder why it breaks down -
2400 fully enlighted encoders for 39€…… hows do you expect this to work? :wink:

@fcd72: Do you know of any other knobby device with automatic SYSEX/Mutable Instruments Data Interconnect learning? If you do, let me know!

1 Like

I own a Bcr2000 and a Bcf2000 for al least 8 years a they’re always working fine…

I wish they would make a new more compact version of the bcr.

I only have one Device thats easily programmable, knobby and tight in timing for this purpose - and tanks are built like that.
Otherwise i would hardcode this particular problem in an PicAxe using this famous Mutable Instruments Data Interconnect protocol.

I assume you mean the Cirklon? I didn’t know it had SYSEX learning.
Are you sure a PicAxe could manage 128 rotary encoders/pots (8 banks of 16) that need to be assigned SYSEX data from a synthesizer and also manage USB loading/storing of SYSEX assignments for the pots to and from a computer?
I think the hardware necessary for that would be about the price of a used BCR2000 to begin with.

@shiftr: I agree too. It was great while it lasted, and a newer version would be cool.

Oh, a BCR has 128 Encoders? :wink:
The PicAxe has enough Power to route MIDI through it an merge the Information from pretty much enough Pots/Buttons for the Ambika Synthesis Engine (without ModMatrix) in less than a mS Latency + you can have a nice dedicated Layout.
By no means i meant the BCR is a bad piece of gear - you only have to take in account the money it costs (actually 149€), an amount other companies just give you a 5U passive Multiple :wink:

Oh, and i didn’t try SYSEX on the Big C but for CCs and NRPNs its dead easy and in fact i used it as a simple controller for Anushri Drum Synthesis :wink:

I meant 16 physical encoders with 8 banks of SYSEX values for each one. That is much less than the BCR2000. Sorry if you thought that I meant 128 separate encoders. That is just ridiculous; imagine all the multiplexing alone.

I looked at the Cirklon page and didn’t see anything about SYSEX, but it does have solid CC/NRPN. That is something I can do with my computer though. Or the Beatstep if I want to leave the studio. I definitely wouldn’t take my Cirklon on the road with me if I had one.
However, it still seems that the only hardware SYSEX learning device is the Berhinger BCR2000. And I haven’t had good luck with them. :frowning: