(mostly) successful shruthi (cem version) build: comments & questions

i finished my first shruthi-1 last night. instead of getting a kit i opted to source my own parts and build the cem3379 version. olivier was kind enough to help me out with some odd parts i couldn’t get at reichelt or farnell - thanks once more for that! some thoughts after playing around a little:

  • first of all, i can confirm what everybody else is saying: the shruthi is indeed a very good-sounding synth! i love all those yummy waveforms! i’ll probably get a second one for some duophonic fun.

  • it is also a very good-looking synth with those black pcb’s and that cute godess and all! (gotta hand it to those hindus, they sure have the prettiest deities)

  • menu navigation is much more intuitive and straightforward than what i expected from such a complex synth with so few knobs and buttons. excellent design there, olivier!

  • unfortunately, the encoder on mine is defective. it works fine for a few clicks, then goes haywire for a few more and so on. i hope i can get a replacement from farnell or rather from their german stand-in.

  • one quirky thing i noticed: there is a rather unpleasant clicking noise whenever the envelopes are reset by the next note. i tried two cem3379 chips, it’s the same with either. not sure if this is a vca or a vcf problem. is this typical behaviour for the cem board? or is there something wrong with mine? anything i can do about it?

  • another thing i find a bit quirky: sometimes the display shows a little eighth note symbol when there is a midi note coming in - but not always. so far i haven’t found any regularity as to when this shows up. what does it mean - if anything?

I also built the CEM version (built the filter board on perfboard without a pcb) but I’ve never had the clicking problem you described here, so I’m not sure where it’s coming from. Are you saying every time you hit or retrigger a note it has a short clicking sound at the beginning before the actual synth tone starts? Have you tried tweaking the envelope to see if you can eliminate it?

  • What is the reference of the encoder you bought? It might be a software/hardware combination problem - the code that does the debouncing is slow and might not work for encoders which generate short pulses - for example an encoder with 36 clicks. No problem observed so far (on my protos and custom builds) with the 24 clicks part from Farnell and for an equivalent from Alpha and from Polyshine.
  • Regarding the click: when you retrigger a note, the envelope quickly goes to zero and then restart the whole attack phase - which might explain the click. This can be smoothed by increasing the value of C5 or the 2.2k nearby resistor. A software fix could consist in programming the envelope generators so that the attack phase does not restart from 0 - indeed this is originally how I programmed it but sounds with slow attacks always sounded weird.
  • The “status icons” are cleared every time a new refresh cycle of the display is started. If you start a note just before a refresh cycle it will show up for only a few ms.

For the click, read here: http://mutable-instruments.net/forum/comments.php?DiscussionID=5&page=1#Item_18

Check all parts around the encoder. Encoders are very simple devices and there is very little that can go bad on them. Chances are something else is in play

encoder: i got the farnell #1520813 24 step encoder recommended in the bom. i’m pretty sure there is something mechanically wrong with the encoder itself. in some positions, it changes values even when only very gently touching the shaft. in others, everything works just fine for a number of clicks, then at one click leaves out a value and then jumps two values ahead with the next click. ironically, i had the same kind of problem when i built my sammich sid kit. wilba sent me a replacement encoder and everything was just fine. maybe it’s a karmic thing i have with encoders. next time i buy any shruthi parts, i’ll add a karmic boost to my shopping cart to prevent this from happening again. :slight_smile:

clicks: thanks for the tips! the 4.7uF trick from altitude’s link looks promising. does this have the same effect as tinkering with c5 or r6?

I’ve just finished building my CEM3379 Shruthi (I bought the full kit and built the SMR-4 board as well, and sourced my own parts for the CEM board), and I think I have a similar problem with the encoder. It plays nicely for a little bit, then seems to jump up and down for a little bit, quickly jumping to a bunch of nearby values before settling down again. The most noticeable thing is when I’m turning it “down” - so for instance if I’m going through the preset list, turning it to go 1, 2, 3, 4 etc is fine, but when I turn it to go in the other direction it sometimes seems to go down one but then quickly set the option back to what I just turned from. I try to go from 4 to 3, and it selects 3 but then instantly jumps back to 4.

@WillyyDavidK: yes, it’s always there when the vca envelope is retriggered. but it’s really only audible if the filter is turned down somewhat. in sounds with lots of harmonics, the click is just drowned in the higher frequencies. if you follow the link above given by altidude, you’ll find that apparently this is a common trait of synths with very fast envelopes. in the thread linked to by altidude, someone linked to this entry in the waldorf microwave faq:
http://faq.waldorfian.info/faq-browse.php?product=mw#114
this seems to explain the phenomenon rather well - and also makes you think the click is acutally a feature, not a bug. :wink:
so, if yours doesn’t have it, there must be something wrong with it. :slight_smile:

@ElectroDruid: are you saying that this encoder problem only occurs when using the cem3379 board, not with the smr-4 board?

@Electrodruid: It’s unlikely that the encoder problem occurs only with a particular filter board. I sometimes get the "1 then jump back to +1" but it has never been a problem to me I think this somehow happens because the encoder hasn’t reached a stable position when you release it (it’s sitting between two “clicks”) and move back to a different value. I’ll see if there is a software fix that improves things - maybe by using a different speed for debouncing the two switches the encoder is made of.

@mic.w: what you describe really does look like a different problem.

i just found out that they have the alternative alps encoder at an electronics store near here. they are a bit overpriced, but rather than arguing around with farnell, i guess it will be easier just to buy a replacement there and see if that solves the problem. i’ll let you know what comes out of it.

I don’t remember seeing the encoder problem with the SMR-4 board, but that’s not to say that it doesn’t happen - I only gave it a pretty rudimentary test after tuning the filter before moving onto the CEM3379 board so it’s entirely possible the encoder is twitchy with the SMR board and I just didn’t notice. I’d be quite surprised the encoder problem was anything to do with the CEM board, unless I’m mistaken the filter board just can’t affect anything on the control board in that way without some pretty serious wrongness. I just mentioned it here because mic seems to have had a similar problem but concluded that the part was faulty - if I’m getting the problem too then it’s less likely to be the part and more likely to be something else.

I’ve played with the Shruthi-1 some more, and my encoder problem definitely seems to be a problem with turning it downwards (anticlockwise). The mode it’s being used in doesn’t seem to matter: turning it clockwise works just fine, but turning it anticlockwise often results in it jumping back to the value it was at before you turned it. It happens often - I can make it happen within the first 10 seconds of powering up the synth, and every few turns after that. I don’t know if this is the same problem mic.w is seeing or not.

I’ll have a second look at the encoder code to see if there might be a software bug lurking around. I remember that there are some refresh rate timings I had to adjust to get a good balance between sensitivity and reactivity to fast changes - this might be worth tweaking again.

If there’s a software bug, there’ll be a fix in the next OS revision - even if the fix is likely to come with a trade-off vs another metric, eg % of skipped pulses when the encoder is rotated very fast.

well, for me this encoder business is getting stranger and stranger:

i just replaced the old encoder on my shruthi. now everything’s working just fine while turning the encoder clockwise. so that’s definitely an improvement.

but when turning it counter-clockwise, at some positions, the value will remain unchanged or sometimes even jump up by several steps instead of decreasing by one. again, in some positions the whole thing is extremely unstable and values will jump up by several steps even when only gently touching the encoder shaft, while at other positions, the value will decrease by one per click like it should.

now, it seems unlikely that i just got a second defective encoder in a row. would you say that this is another symptom of the same possible software bug? or should i look for a hardware problem? where would i start to look and how? the soldering joints around the encoder all seem ok, as far as i can tell by just looking at them.

Unlikely to be a hardware bug - as altitude said, encoders are fancy pairs of switches. What I suspect is that some parts might generate more spurious noise at edge transitions than other, which prevent the state change on one of the switches the encoder is made of to be accurately detected. It just needs a longer debouncing sampling time.

Whatever it is, it is fixable by software.

Now the question is: I am in the middle of a firmware upgrade which includes several new features and several fundamental changes in the synthesis code that have not been tested enough for release. Would you want me to prepare an “emergency release” with the fix, or could you live with it and wait for the official release of the new firmware in 4 or 5 weeks?

well it’s good to hear that this is a software issue.

frankly, i wouldn’t mind a quick fix, if you can manage. i think shruthi 0.9 already is a very powerful synth in its own right, so i guess it kind of deserves a bugfix release if that’s not too much hassle. i don’t know what all those new features and fundamental changes in the synthesis code of the next veraion are, but some people might even decide they are happy with the features of 0.9 and stick with that version.

but then again, now that the encoder on my box at least works ok in one direction, the problem has definitely become more manageable and i guess i could wait for a couple of weeks, if you think that fixing 0.9 would be wasting too much time or resources.

I think I have found a fix. As planned, this causes a few number of skips when the encoder is rotated very fastly (ie, if you rotate the encoder really fast, it won’t go faster than when rotated more slowly), but there’s no instability when it is rotated at a slow or moderate speed. The problem was related to the way the debouncing is done - the code was based on the assumption that both switches would stabilize around the same time, while it seems that for some encoders one of switches can be significantly more bouncy than the other (which explains why the problem occurred only in one direction). I’ll post a .mid and .hex soon - I need to validate a few other things now.

Tried a couple of encoders until I got one that clearly caused the problem. Nothing wrong observed with the software revision:

.mid and .hex files (v0.91) available from:
http://mutable-instruments.net/static/firmware/

wow, that was fast, thank you!

unfortunately i somehow can’t install the update.

[edit:] i moved my description of what went wrong while trying to update to a new thread:

so, has anybody else successfully installed this update?

ElectroDruid: did it solve the encoder problem for you?

I haven’t tried yet - partly because I haven’t had a lot of time since building the kit, and partly because I’m a bit hesitant given the problems you’ve had. I wasn’t clear from your post if you were able to successfully revert back to v0.9 or if the update process basically killed your Shruthi completely…

If it’s possible to revert back if I run into the same problem when updating, I’m happy to give it a go, particularly if it will provide useful knowledge to other people. If there’s a chance v0.91 will break and then not let me go back to a working v0.9 synth, I guess it seems wise for me to wait until Olivier can work out where things went wrong for you.

I’m still curious if you and I are the only ones who have had this issue. How many fully built Shruthis are in the wild now?