DSP Robotics Support

Hi. Is there a way to implement proper keytracking for adsr envelopes? Have tried various ways with 'pitch to freq' and the likes but i doesnt sound right to me. Is there a simple code perhaps?

Cheers.

I'm sure Spogg will have something for you - I imagine the envelopes in Razorblade could be adapted to do this, for example; it has a great keytrack CV source as well.

Halon wrote:Hi. Is there a way to implement proper keytracking for adsr envelopes? Have tried various ways with 'pitch to freq' and the likes but i doesnt sound right to me. Is there a simple code perhaps?

Cheers.

What parameter(s) do you want to track?

In my case I modified Martin’s exponential envelope generator so the decay and release times got shorter for higher notes to simulate a piano’s behaviour. But creating a suitable transfer function between key number and time reduction was really quite tricky to get it sounding anything like right. For a piano the change of decay and release is dependent on wire length and tension and also to some extent on the number of strings per note over the key span. Also there’s no agreed standard for pianos so in the end it was a compromise based on listening and tweaking accordingly.
If you look inside my Quilcom SIM-PF you’ll see what I did for the envelopes, but keep in mind this may not be suitable for all situations.

viewtopic.php?f=3&t=37789&hilit=SIM#p112509

I hope this helps…

I may have misunderstood, in which case I apologize. But it is much easier to work with normalized values instead of direct key number transfers.

MIDI protocol knows exactly 128 keys, and each incoming note carries its number in the midi message. Divide by 127 (indices are from 0 to 127) and you get a value between 0 and 1. Now you can multiply quite easily with either a fixed value, a formula or a table. And for reverse functionality just do 1 - x before the multiplication.

If I want to work with key ranges I find it easier to work with pitch/note values, then I work on those in a similar way. So for example for key range 36 to 60 I subtract 36 to give 24 then divide by 24 to give 0-1 for that key range.

What would be nice is a graphical method of creating a transfer curve. 0 to 1 in and 0 to 1 out. Maybe this exists but I don’t have it. Not that I’m hinting or anything...

Just a suggestion . . The Additive Osc prim outputs an array of 128 float values . . .which you can draw in yourself . . . also can be loaded with a saved array. Not it's intended purpose I know but looks to me like it could be re-purposed to do exactly what you want . . . just an idea!

DaveyBoy wrote:Just a suggestion . . The Additive Osc prim outputs an array of 128 float values . . .which you can draw in yourself . . . also can be loaded with a saved array. Not it's intended purpose I know but looks to me like it could be re-purposed to do exactly what you want . . . just an idea!

That's actually a cool idea. Just check if it's the 0-1 range per bin.

Spogg wrote:What would be nice is a graphical method of creating a transfer curve. 0 to 1 in and 0 to 1 out. Maybe this exists but I don’t have it. Not that I’m hinting or anything...

Yep, I took a big bite, and now I'm hooked. Oh my...

tulamide wrote:Just check if it's the 0-1 range

Yes it is . . I'm thinking you could draw in the curve of the cast iron piano frame . . . . . or maybe I'm getting carried away here

Guys, since posting my “wish” I realised that the transfer function really needs to operate at stream rates in order to control stream parameters like decay time.

If we had a graphically created float array it could be put into a mem reader where the reader's index was created by multiplying 0-1 by the array size, say 512. The output stream would then be a value based on the 0-1 value indexed by the 0-512. I think that’s what Davey was thinking.

One bonus of such a system is it could describe a distortion transfer curve, wave folding or even a compressor’s response curve. For this it would need to be quite high resolution to reduce quantisation noise, but for decay times it could be much lower resolution.

I know what I mean anyway.