Why not...?

Hi everybody!

I’ve been reading you for quite a long time, and I find that this is probable the most awesome synth ever made. Big corporations and brands should learn a bit from all this… with a reduced bugdet and just a little number of talented persons (and their effort too, obviously) you’ve made a complete open platform for making music and sounds, and what’s more exciting… it’s expandable and hackable!

First of all I wanted to discuss/suggest about some possible hackings or “revisions to the control board”, to see which one could be more likely to see “in action”.

Of course, I want to see what’s your opinion and above all I would like to mantain backward compatibility with all the existing Shruthi1s. Obviously riskier and greater evolutions could be made (poly-Shruthi, DSP effects, …) but that will mean another different generation (like the step done from Shruti to Shruthi) and, in my humble opinion, it’s too early to discontinue the Shruthi1 as still has so much to offer.

1- (This was already discussed in the Shruti1 era http://mutable-instruments.net/forum/comments.php?DiscussionID=8)
Why don’t upgrade to a ATMega1284p or maybe other superior, with more flash memory, 12bit ADC and other features? That or making a dual AVR board as you suggested (one for the oscillators, and other for MIDI, interface…).
Maybe computational power isn’t the problem right now, but what about memory? 64+16 presets is still a reduced number. Arrived to this point, every time a new improvement comes it’s in spite of removing another feature and I really admire your hardwork as a programmer (bravo). Maybe just putting a bigger EEPROM chip? That could mantain backwards compatibility (as long as two sets of firmware are prepared, one for the 64kb units and other for the newer ones) You even suggested the AT24C128B.

What about an SD or microSD card slot? Those prepared for Arduino boards are really cheap, and provide a bazillion times the flash memory that we’ve got already. Obviously, nobody is going to store 1 million of patches, but… it’s still cheap and maybe you find other ways of using that free space (additional oscillator waves, formants, wavetables, sequences, samples?, …) :slight_smile:

2- Bigger LCD. I know that you want to keep the Shruthi a easy yet powerful synth, but that hasn’t to do with LCD size after all. I know how tedious could be reading tiny LCDs (Yamaha SY22, DX7, Nordlead, JD800 and lot more). Probably when lot’s of physical controllers are available (knobs, sliders, … such in the case of the JD800… wow!) the LCD size doesn’t matter so much, but still I prefer not to see abbreviations and cryptic language, having into account that the different of price of one small LCD to a medium sized one is no more than a few bucks.

Here I think of three different possibilites:

a) 20ch x 2 lines. ($10 i. shipping) Just a little improvement in screen size, but it still “fits in the hand” :wink:
Menu layout could remain more or less the same (just adding one blank space more between every parameter), but the knobs will be right under the parameter in the screen and there will be 8 ch. more for other messages that could take full screen.
b) 16ch x 4 lines. This one is not so common (I don’t know why). Two entire sets of parameters are visible with one glance. Even, a selector button (A/B) could be available on the left side of the screen to quickly switch between which one of the sets it’s being tweaked by the knobs.
c) 20ch x 4 lines ($28 including shipping in eBay, and obviously cheaper options are available)
Some kind of hybrid between the two former options… I’m not so sure about this one as it will look as some kind of Frankestein.

3- Voicecards and voicefarms: Polychaining ability is one of the most exciting features of this machine, but why having to build another entire Shruthi1 only for using some of the components? Maybe a simple voicecard could be designed, as well as a voice farm with at last 3 voices (so that the the whole system Shruthi1 + voicefarm gets total 4 voices… somebody said Tetra?). I’ve read that there is a 4ms delay between polychained units, so that long chains are not recommended, but what about one single board with the components of 3 voices but just one MIDI and audio settings? Maybe that could avoid to some extent the increasing delay. Also, with a voicecard, some kind of fake-delay effect could be achieved without any DSP, but as a MIDI effect.

4- iOS integration and physical programmer. You’ve a lot of work made in this respect (fcd72, and phm78, thanks), and I find all this a really intriguing and interesting proposal.

These are all interesting suggestions. Do they fit in the “revision” category? I don’t think so.

  • I originally intended to use the ATMega1284p. At the time I developed the project (april) the supply of this chip was still chaotic - 644p were and are still more widely available. The ATMega1284p incurs a slight performance cost (it needs to save the RAMPZ register at every interrupt ; and RAMPZ needs to be toggled before and after each operation reading the wavetables since they reside in the upper 64k area). This was enough to cause glitches on some patches. Regarding the ADC, the 1284p is also 10 bits (ahem 8 bits if you take into account the noise), and I don’t see any place in the OS where it would really help, since a lot of pots/modulation computations are done on 7 bits internally (a 15bits accumulator with clipping is used for computing the modulations). Add poor compiler support for the 64kb-128kb and this is pretty much why I stuck with the 644p. Should I change now? A part of me believe that the cost of forking the firmware is not worth it. If I had to fork, I’d probably do it for a radically different platform.
  • The upgrade to a larger eeprom space is planned for a future OS update. All the new kits come with the 128kb part anyway as the 64k part is now obsolete. I can support arbitrary larger sizes with one caveat: the current SysEx bulk dump protocol will have to be changed (thus, rending useless the back-up .mid/.syx some people might have made) – or the area above 128kb won’t be backed up/dumped by MIDI.
  • The Shruthi is pretty tight in terms of I/O pins. Adding a SD-card would take out 4 pins, which means removing a feature to move to another port the LEDs/switches. Also, if FAT has to be supported for the SD-card, a FAT driver takes quite some space in program memory!

A wider LCD would be helpful, but the encoder would have to be moved a bit. If you have some ideas of better UI designs, send drawings/mockups (or better: edit the board files in Eagle to show how the change would work out)! I think a taller LCD (more lines) would cause some problems as the fingers of the player will obscure the controls on screen.

The idea of a “slave” Shruthi with no knobs, no LCD, no switches ; but just DIP selectors to select MIDI channel and polychaining order has popped up a few times. What would be the point of such a unit?

  • Economically speaking, it doesn’t make a lot of sense – if you take into account the additional development costs, the fact that the PCBs will be produced in a smaller quantity, the small number of people using the Shruthi in a polychain vs as a monosynth, and the fact that 80% of the kit preparation labor is spent on the filter board kit.
  • You won’t overcome latency if the voices are still communicating through the “polychaining protocol”. Changing this protocol would be akin to do 75% of the design for… a polysynth.

If I have to bear the costs of doing new developments, prototyping new boards, writing a new OS and a new protocol for board-board communication… this is not worth doing in the context of a “Shruthi update” - it clearly becomes a new polysynth project!

This is the whole point of this community-driven development. People like fcd72 and phm78 are taking the project to directions where I would not have taken it personally (because I’m not a big fan of iP* and because I don’t have much space at home to keep large synths).

Thank you for such a detailed and fast reply!

Obviously the point of my whole previous comment was to emphasize the fact that for me the surplus of the more powerful or expensive components is insignificant versus their advantages. But, as you’ve told me with lots of reasons and facts, sometimes it’s more a matter of design, availability and losing certain things to gain others (opportunity cost) than a monetary thing.

I’m glad to read that the EEPROM size is going to be increased.

I just wanted to know if there could be some kind of easy upgrade within going out of the present platform.

About the bigger LCD thing, I’m trying to make some mockups with Google Sketchup, to see which one is more suitable and useful. As soon as they’re ready, I’ll post them here. Maybe the improvement is not a big deal, but it’s still an improvement.

I’m really excited about how everybody’s helping to improve and sustain this community, that’s why I really love DIY projects.

And… finally… why don’t you enable some kind of Paypal donate button, to help you achieve more funds for all these lovely projects?

Do you know this http://www.sonoio.org/#shop ?

It’s a simple sampler + patchable + delay. Maybe the sound quality isn’t pristine and nice, but, it could be improved.

the sonoio doesn’t sample, it romples :slight_smile: kickass sampler will be from here

You’re right. Its one bazillion times better!

More interesting stuff:


And… I’ve been thinking about… for all those who already have the 64kb EEPROM, are you going to sell the upgrade to the 128kb one (preloaded with the presets)?

I mean… is it possible to desolder from the PCB the 64kb one, and to replace it with the new one? Or some alternative method to offer upgrade?

The eeprom is mounted on a socket!

I don’t know why I thought it could not be replaced or something.

I’m really happy to read that


While talking about eeproms, will a 512k type work also?

edit: read “work” as in “uses the usual lowest 64/128k and ignores the rest”

I will check how much space a routine for auto-detecting the eeprom size takes. I will have to check the datasheet again, but I’m not sure the size can be determined by sending a magic command to the device, so you have to do read/write at increasing address until you see garbage to determine the size.

More interesting stuff…

A Juno-like chorus would be great…


Definitely interested in upgrading the eeprom on my shruthi-1 :slight_smile: