modulation table

[mickwest1]

can anybody tell me how to modulate decay - I only see options for attack in the destination table

otherwise how do I make a hi-hat longer according to velocity? - Am I the only person in the world (again) who wants to do this??

[elcallio]

There is no "decay" modulation dest, but there is an "AEG Time" that changes the overall length of the envelope. Though, when reading and checking this I just noticed a bug, namely that this actually changes the attack as well. That's not right.
I will fix the bug asap, but in the meanwhile you can work around this by modulation attack with a negative value, equal to the env time modulation to compensate.
Cheers
/C

[mickwest1]

Thanks for your quick reply

I've fiddled with it for a while and can't get it to do anything useful

Is there a reason why we can't just mod the decay - I use shortcircuit at the moment which works fine - would like to change to tx16w but it seems I keep having these sort of problems

[elcallio]

Thanks for your quick reply

I've fiddled with it for a while and can't get it to do anything useful

Is there a reason why we can't just mod the decay - I use shortcircuit at the moment which works fine - would like to change to tx16w but it seems I keep having these sort of problems

To be quite frank, the only real reason is that those where the original TX16W modulation dests for the AEG. But, really, the AEG Time should really _be_ what you call modulate decay, since it should (and does, though also attack - bug) change the overall env time. (Ok, it will increase release as well, but that should fit well into your hihat use case.

[EvilDragon]

Ideally each envelope time should be a separate destination, if possible.

[mickwest1]

I did manage to get it working ok - just seems a bit strange !

anyway I've had no response to my other post - ver 2.2.0 doesn't work at all - tried re-downloading and re-installing several times

back with ver 2.1.0 It now seems to have hung energy xt - phew this is hard work!

[elcallio]

I believe Alex, in another thread, managed to hit upon the issue you are having (if its on XP).
Expect a new build tomorrow.

[elcallio]

To return to the OP topic (bad bad thread hijackers!), I've updated the AEG/Time modulation to work as intended. You can now properly modulate the overall decay (AEG "length") of a sound, the attack is only affected by the AEG/attack mod dest.
I also tweaked the range of the modulation so you can get pretty big changes. Note that this is an exponential modulation with a multiplicative behaviour (the AEG rate will be multiplied by the modulation, which in turn is an exponential curve mapping of the input value). I.e in the upper ranges, it changes a lot.

[mickwest1]

aha - that's better - I've now got 2.2.1 and all seems to work fine

it's interesting that you mentioned the curve of the modulation - which leads me to my next query

I've found now that the dynamics are not very good (sorry) - shortcircuit let's you alter velocity sense by a db value - I find that a range of about 30-40db works best in general (for say a snare drum) - this seems to be roughly equivalent to the tx16w with 100% velocity setting

but the difference with the tx16w is the curve - it get's loud too quickly - so I assume it's linear whereas shortcircuit is probably logarithmic

(I can send examples if it helps)

I'm guessing all of this as no information is available anywhere - so what I'm asking is - Is the curve linear? - can it be changed to log?

all the best

[elcallio]

I was gonna answer "no, its an exponential curve", but then I took a look at the code, and weirdly enough, the template argument is indeed a linear curve for the velocity controlled MIDI velocity to volume mapping. (Though using modulation table will instead map using an exponential curve).

At first I thought this was a search-and-replace-bug, but I think this is due to a discussion that arose when the wave matrix was introduced, the argument being that its better to have this curve be canonical (linear) and let people fiddle with the velocity curves on their control keyboards instead (mine has a fine selection I rarely use...). But I obviously see your point.

What I would propose it this: I add an attribute to the program slot, "MIDI velocity curve", that controls how incoming velocity is mapped in the slots processing of notes. With something like "<default>", "linear (off)", "x2", "x3", "exp", "exp/log", "log", and "inverted exp". With a global default in settings.

(Since this is a performance aspect I am placing it on the perf level).

/C

[mickwest1]

many thanks for your reply

I have an old Roland PC-200 kbd with no curve settings so it's awkward using the tx16w - but I also sometimes use an Alesis Control Pad - I set this to linear when using shortcircuit but I can change to exponential to work for the tx16w


I suppose there are arguments for both types - but it's common to have a choice (eg: sfz+ has good options - also Addictive drums)

it's especially useful for matching up existing files programmed for other plugs/gear

so Yep it would be great to have the choices you mention per program - even global setting would be fine

Thankyou for listening

[mickwest1]

found this

http://code.google.com/p/midi-shape-shifter/

for anyone else interested - but it seems a bit bloated

[mickwest1]

this one maybe better

http://www.trombettworks.com/velocity.php

[IXIX]

What I would propose it this: I add an attribute to the program slot, "MIDI velocity curve", that controls how incoming velocity is mapped in the slots processing of notes. With something like "<default>", "linear (off)", "x2", "x3", "exp", "exp/log", "log", and "inverted exp". With a global default in settings.

(Since this is a performance aspect I am placing it on the perf level).

/C

Wouldn't it be better (more powerful/flexible) at Group level?

[mickwest1]

As it's really mainly for midi input - for me a global setting would be enough

- but I suppose logically it should sit next to the group velocity knob