DSP Robotics Support

Adapted from one of my old Trogz-Toolz scalers...

[EDIT: Attachment removed: The latest version can be found HERE]

You can set any stream input range you want in the properties (so could use MIDI note number as the input). This range will then be mapped to the full span of the float array of control law data, whatever its size. The array is read with linear interpolation so that small arrays will be "smoothed" (a nicer form of interpolation would probably be better for audio transfer curves, but it should suffice for control signals). Note that there's no constraint on the output - it's assumed that the array only contains legal output values.

If I get a moment, I have a go at optimising the old DSP code later - I'm pretty sure that it could be made a lot more efficient in assembly.

That’s amazing trog!

We’re so lucky to have you around (again).

A fast version would be great for wave shaping and distortion but for envelope times I guess it could be hopped. Envelopes are typically hopped at 16 so the CPU should be fine for that purpose.

Cheers!

While it is a cool thing, may I just ask something? I don't understand the logic behind the request.

It started as a question if there is a way to adapt linear keytracking. "Operating at stream rate" doesn't make sense for me in this context. The "rate" at which such a mapper had to operate is certainly the speed at which midi notes are pressed. Which is far from stream rate, even far from Ruby's 100 Hz.

Or am I wrong?

tulamide wrote:Or am I wrong?

Not wrong at all - for key-tracking it certainly would be better to calculate the value only when a new key is pressed. However, it must still be done in DSP-code or Assembly, as the final modulation value needs to be per-voice (i.e. poly stream).

Spogg wrote:I guess it could be hopped

And that's the solution! The hop counter is always reset to zero at the start of a new voice, and the hopping value can be set big enough that the code only repeats once every few minutes - it's as close to "at note-on" as makes no difference*.

I'm nearly there with the ASM optimisation, and it's very little work to add that, so I'll put a hopped version in the next download.

(* NB: Contrary to what I always used to think, you can't use stage(0) for this. Stage(0) is only called when a new block of four SSE voices is required - i.e. it initialises a new "copy" of the whole poly section, not each new voice individually).

Since (as tulamide quite rightly pointed out) practical examples have moved beyond just key-tracking, I've posted new versions of the "control law" modules in their own thread - including an "at note on" version which might be useful for envelope scaling.

One other thing that occurred to me...

When modulating envelope times, it may be better if, rather than adding/subtracting a modulation amount, you use it to scale the values (i.e. as a multiplier/divider). This keeps the times of the various stages in proportion to each other - for example, you might have the ADR times at the bottom of the keyboard be double the nominal value, and the times at the top of the keyboard half the nominal value. If you do it by adding/subtracting, negative modulation of short ADR times might very easily get jammed at zero, and long ADR times might seem barely affected relative to short ones for the same modulation amount.

trogluddite wrote:... When modulating envelope times, it may be better if, rather than adding/subtracting a modulation amount, you use it to scale the values (i.e. as a multiplier/divider)...

Exactly so!

The actual values in the transfer table should not be used to add or subtract, but to halve or double (or whatever) values set as a base on the envelope generator. If the user isn't given access to these ADR settings, for example in a simulation of a single instrument, it won't matter how it's achieved. But scaling would always be my approach anyway. I would make the decay and release settings to be for the lowest notes and use the transfer function to reduce the times for higher notes, as per regular acoustic instruments.

Is this of any use? In my organ-centric world I'm constantly obsessed with keyboard scaling; low notes and high notes (= massive pipes and tiny pipes) are all physically related within a rank but sometimes in rather non-linear ways, so this is a tool I've been using of late to generate individual note-values for envelope speeds, pitch movements, modulations and so on.

Apologies & warning .. made in 64-bit Alpha ! I can re-work it for 3.0.6 later if needed ...

You can set the bass & treble end values with the two sliders (shift for s l o w), and then bend the curve in between them any way you want. The only limitation is that the array values can't backtrack at any point, it has to be a progression between bass and treble .. which is after all the way most instruments behave. Should suit most purposes.

Note that if you're accessing such an array using FA2P, or a DSP equivalent, then as Trogg rightly says for most parameters - envelope rates for instance - you generally only need to accessthe number once at note-on, not continuously at every sample. I have this all worked out in Assem which I can post later if wanted, including using the latest 64-bit Alpha 'memrefin' feature - very hi-tek!

H

First of all, sorry for the late reply. Been busy with some personal things lately. Second, @spogg i want to track the volume of an oscillator(s), or the overall amplitude. Third, thank you all for the replies and the schematics, much appreciated!