Feature Request: Envelope Decay as a Modulation Destination

Hi Oliver,

Any chance that you can add Envelope Decay as a modulation destination in the next version of the Shruthi firmware? Attack is already an option (and a useful one at that!). But adding Decay as a modulation destination would allow you to do things like make the sound more “plucky” at lower velocities and then more open at higher velocities or to become shorter as you move up the keyboard (by using Note as the modulation source).

On some synths, the Decay and Release parameters are included as a single modulation destination (as Decay/Release). My personal preference is to keep them separate. But if it’s easier to code them as a single modulation destination, that would be okay.

Thoughts?

P.S. I know you just added my earlier LFO “one shot” suggestion as a new option in the upcoming firmware update. (Thanks!) I don’t want to come across as a total ingrate by asking for another new feature just after you implemented my last request. But including Decay as a modulation destination would be another cool addition to the Shruthi’s impressive feature set. :slight_smile:

It’ll be messy - not the feature in itself, but adding an extra layer of indirection between the UI and memory so that this new destination does not appear at the end of the list but somewhere more logical.

Hey, then I’ll get both my feature requests for the price of one! LOL. (If you recall, I had previously requested that the modulation source and destination options be listed alphabetically to make it easier to find the particular source/destination you want to assign.)

No, I won’t change the modulation display order to alphabetical, but you’ll be able to do it by messing with the code, right?

>No, I won’t change the modulation display order to alphabetical, but you’ll be able to do it by messing with the code, right?

My day job is as a Product Manager. I just write the requirements and leave the heavy lifting to our developers. :wink:

So if you didn’t make the modulation display order alphabetical, I’m assuming you would list Attack and Decay as a group somewhere in the list, right? If so, would you also group things like Cutoff and Resonance (which are currently not adjacent in the list of modulation destinations)?

I don’t plan to reorder the existing list - just insert the new items at the most appropriate place into the list.

If you don’t plan to reorder the list alphabetically, then may I respectfully suggest grouping the various sources and destinations by related functions. Consider the following ordering of modulation sources:

Internal Sources (Synthesis Controls)

  • env1
  • env2
  • lfo1
  • lfo2

Internal Sources (Arpeggiator/Sequencer)

  • arp
  • stpseq
  • stpsq1
  • stpsq2

External Sources (Physical Controls)

  • bender
  • mwheel

External Sources (Keyboard Controls)

  • afttch
  • gate
  • note
  • velo

External Sources (CV Controls)

  • cv1
  • cv2
  • cv3
  • cv4

Audio Sources

  • audio
  • noise

Mathematical Operators

  • offset
  • random
  • op.1
  • op.2

So the revised ordering would be**:

env1
env2
lfo1
lfo2
arp
stpseq
stpsq1
stpsq2
bender
mwheel
afttch
gate
note
velo
cv1
cv2
cv3
cv4
audio
noise
offset
random
op.1
op.2

**Note that I have left off the “trg” sources because I believe you mentioned that these will be removed in the next firmware release.

Although I still feel that listing sources and destinations in alphabetical order will be more immediately understandable by most people, at least the above ordering groups items by related function.

Thoughts?

That’s a matter of personal preference. I don’t see this as an improvement that would benefit the community at large. How much would you pay for a custom firmware with this change?

I was just thinking that if you are going to go to the trouble of coding the logic to abstract the presentation of the list from the underlying parameter set, why not group the options more logically? Or did I misunderstand that you were planning to separate the presentation layer from the data layer?

I agree that the revised order might not be a whole lot more understandable to the average user (who may not appreciate the distinction between “internal” and “external” control sources). But surely the following list of modulation destinations makes more sense than the current ordering (by following the standard signal flow through the a synth’s architecture) :

Oscillators (Pitch/Shape)

  • osc1
  • osc2
  • osc1+osc2
  • pwm1
  • pwm2
  • fine

Filter

  • cutoff
  • reso

Amp

  • vca

Mixer

  • mix
  • subosc
  • noise

Envelopes

  • env1 attack
  • env1 decay
  • env1 release
  • env1 level
  • env2 attack
  • env2 decay
  • env2 release
  • env2 level

Control Voltage

  • cv1
  • cv2

Incidentally, if you are planning to add Envelope decay as a modulation destination, why not go all the way and add all the envelope stages as well as the envelope level (for each envelope independently)?

Envelope Level in particular would be a very useful modulation destination. Right now you can assign velocity directly to filter cutoff to control the brightness of the sound. However, this doesn’t yield quite the same effect as assigning velocity to Envelope 1 level. This latter routing is how the filters on most synths are controlled via velocity.

Look, I fully appreciate you are a small company and have to prioritize features to provide the greatest value to the greatest number of users. I’m just saying that these features are useful to me. If other users disagree, that’s totally cool. Majority rules in this case. :slight_smile:

> why not group the options more logically?

Some users have expressed in another thread that they would be disturbed if they have to deal with a new ordering of the parameters.

> Envelope Level in particular would be a very useful modulation destination.

That’s what operators are for!

>> Envelope Level in particular would be a very useful modulation destination.

>That’s what operators are for!

Yeah, I do that all the time (using Velocity and Envelope 1 or 2 as the two inputs and “Multiply” as the operator) to control the level of an envelope via velocity. However, since there are only two operators, it might be nice to have Envelope Level as a dedicated modulation destination so you don’t have to use an operator for a standard routing. But you’re right, you can achieve this effect using the existing synth architecture. :slight_smile:

>> why not group the options more logically?

>Some users have expressed in another thread that they would be disturbed if they have to deal with a new ordering of the parameters.

No pain no gain. :slight_smile:

Seriously though, Apple does this ALL the time (even going so far as to completely drop support for various features in the name of progress). I suppose that’s why many people hate Apple so much. LOL. But if you never improve anything for fear of upsetting a few change-resistant users, you won’t be able to attract a whole generation of new users who will benefit from the changes.

End of sermon. :wink:

The difference is, Apple Software runs on 3GhZ+ 64 Bit i5 or better with at least 4 GB of RAM which means 97% of the Processing time its idle and you have lots of empty Memory to fill.

The Shruthi Firmware runs on a 20Mhz 8Bit AVR with 4K of RAM. Go get one and try to rearrange a grown (from 2 years of Evolution) list that size within your bounds of RAM, Memeory and leftover Processing time.

Personally - as i actually know what hassle it is to integrate an abstraction layer into existing software on an embedded system - i dont care if my modulation destinations are sorted by alphabet, grouped more or less logical (up to the viewers eye - i guess we could coume up with about 27 different equivalent important groupings) or by the developers choice driven by best and fastest/easiest/safest implementation. I can well turn the encoder a few more times and dont get huffy about it :wink:

Just to add a belated +1 for this feature. I don’t care too much where it appears in the list.

a|x

Flip the envelope up-side-down and use the variable attack as a variable decay. That is they easiest way to do it. The best part is that this technique works on tons of other synthesizers.

> I can well turn the encoder a few more times and dont get huffy about it

Nobody is getting “huffy” about anything. But to your point, if the processor in the Shruthi is so underpowered that it’s not even possible to follow universally accepted software practices (to separate the presentation and data layers,) then this indicates that the current processor was probably a poor choice. Unfortunately, there isn’t a lot that can be done about this now.

Regardless, as I understand it, Oliver IS planning to separate the ordering of the modulation lists as presented to the user from their order in the code. So the issue isn’t WHETHER to abstract the modulation list, but HOW to present the list in a logical, more readily understood manner (for the benefit of new users).

I originally suggested that alphabetical order would be the most widely understood ordering scheme (as it wouldn’t require users to understand the grouping logic of other schemes). But Oliver seems resistant to this standard approach. So I merely suggested an alternate ordering that seemed to make more sense.

Please try to follow along.

Hmm, there’s a difference between choosing an underpowered MCU in the design phase of a project vs hitting a brick-wall in terms of available CPU cycles and RAM in a mature product where the designer has been very nice and accommodating taking it far beyond what it could do when it was launched…

> it’s not even possible to follow universally accepted software practices (to separate the presentation and data layers,)

Universally accepted in the application software world, maybe. We’re talking about embedded systems here, where the shorter/smaller the better. From what I’ve seen from other manufacturers, the “universally accepted software practice” is usually a monolithic block of assembly code.

> then this indicates that the current processor was probably a poor choice.

As if there was a choice. I took the best microcontroller in a DIP package with well-maintained open-source development tools (as opposed to bootleg builds of gcc 3). I battled over the years to fit more and more user requests into it but we’re getting close to the limit.

I will modify the list to add the new entries, and that’s it. You’re not the first guy to complain about the lack of ADR modulations, so I see value in offering this new feature. You’re the first one to complain about the modulations order so I take that as a personal gripe - for which two solutions exist: you fix it yourself or you pay someone to fix it for you.

I don’t want my Shruthi to do anything like Apple would…and I must say I think that stating that the processor was poorly chose when you consider that hundreds of DIY units have been successfully built, very affordably, and Olivier has built a business out of his success with the Shruti/Shruthi.

I simply don’t think reaching the limits of a $8 MCU means it was a “poor” choice.

> hundreds of DIY units

Soon 3000 :slight_smile: