kokoon

would it be possible to get a better resolution for kX automation. by "better" i mean more than 0-127 (7 bits).
if the algorithms arent limited in this way, then i suggest the use of 2 midi controllers in combination, to get 14 bit resolution.

the effects are nice and all, but arent that usable with this kinda value jumps (im talking especialy about the decimator and some sweeping filters).

if nothing else, then just say the effects are coded in a way that doesnt allow better control resolution.

thanks in advance.

ps. i know im being bitchy about it, but - you know - when you bring the drivers this far, people will always want more.

__________________
[kokoon]

kokoon

what? oh, sorry, wrong thread.

__________________
[kokoon]

Eugene Gavrilov

perhaps a better way is to follow the MIDI specification
any MIDI controller can have two 'parts': 'coarse' and 'fine'
probably, adding such support for kX Automation would be a good idea

any comments? [before I start to code anything ]

/Eugene

dungle

I have an idea for this Eugene,
How a about an automation mode where the DSP variable (e.g. "Freq") is controlled by the 7bit midi data as it currently is, and is interpolated to a higher resolution .
Some time constant would be applied so that as the user sweeps the "Freq", the response of "Freq" is silky smooth. Perhaps a time constant of "fast" or "slow" or "none" could be assigned by the user to a particular automated parameter in the KX automation setup page(s).
When the controller stops changing, "Freq" would land on a 7bit derived value as it does now.
I suggest this feature for the following reasons:
- For many realtime midi controllers the absolute value is not that important but the smoothness of relative changes can be very audible.
- 7bit controller data is the native language of so many sequencers and control surfaces etc.
- performing a smooth realtime sweep by changing both "course" and "smooth" midi controllers may be difficult for users .

thanks

sleamey

Yeah, I think coarse/fine double controller isn't a good idea by means of realtime perfomance. (I plan to perform live onstage with midi controller)

I've got another suggestion (i don't know which is better: mine or the previuos one):
maybe it would be better to implement some 'inertia' parameter on the DSP side instead of rewriting kx Automation code. (Only few DSPs need this feature such as gain controls and filters)

dungle

hi sleamy,
my understanding of the software architecture is this: (others will correct me if I'm off target):-
the KXAutomation functionality of KX drivers is responsible for taking midi data recieved by "KXcontrol" virtual midi port and (after appropriate scaling the 7bit control value into a 16/32 bit number that the plugin DSP algorithm uses) puts it into the appropriate register in the EMU10kX chip.
The DSP uses a sophisticated,powerful instruction set, however it can only ever process precisely 512 of these instructions per sample @48kHz.
It there for only makes sense to have reletively slowly changing data processing to be handled by the host.

The idea of "inertia" sounds like an interpolation time constant.

here is an example of how it might work.
1. Say you have a resonant filter cutoff of 1kHz which happens to be obtained by inputing a control data value of 64.
2. Then say you sweep the midicontroller slowly up to 67.
3. (without interpolation) If the filter was scaled to operate over several octaves you may hear 3 steps as the filter frequency is changed.
4. (with interpolation) The filter freq would be updated more frequently with inbetween values over the same range resulting in a smoother sweep.

regards

sleamey

Yeah, you're right! I forgot 'bout that!
So, it looks like the best way is to implement 'inertia' (yes, we're talking about same thing) in the kx Automation.

kokoon

great! i didnt know about the coarse/fine. that would be just perfect.

and after implementing that you can add interpolation too.

and to all of you coarse/fine haters - if you have a midi controller that sends relative controller value (endless knobs eg) then im sure the coarse/fine can both be used (combined) on one knob. i will mostly use it from reaktor where i will create a small module, calculating the coarse/fine values from one knob with greater resolution than 7bit.

Eugene - coarse/fine would really be great and you know it!

__________________
[kokoon]

sleamey

So, why don't just implement both coarse/fine and inertia?

kokoon

inertia/interpolation is more processor expensive, im sure.

__________________
[kokoon]

HarmLammers

Perhaps it could be made possible to switch interpollation on or off so the user can dicide if he wants the drivers to consume some CPU time...

Eugene Gavrilov

interpolation is not simply CPU-expensive
it might require a special high-resolution timer ...
I will have a closer look at this topic

so, we have three basic approaches:
1. 'fine/coarse' -- simply increase dynamic range to 14 bit
2. 'interpolation' -- provide interpolated values (60,64 -> 60,61,62,63,64)
3. 'dynamic sensivity' -- slower moves give more precise results

interpolation will require a special timer-based code
moreover, the interpolation quality should be tweakable (for instance, maximum time for the value t1 to reach the desired t2 state)

/Eugene

kokoon

Eugene, im really glad you're appreciating our opinions. we really need to make the automation supergood, cause with it, you can wire all the midi gadgets to the emu soundcard and make it a killer.

im not an expert or anything, but as far as i understand the whole programming side of the problem:
- the fine/coarse approach is an easy and resource-cheap.
- interpolation approach will require some new program threads, which is probably a bad thing.
- dynamic sensitivity - im not sure if i get it right, but the way i understood it, the 7bit range would actually translate to different ranges, depending on the averege value change in a time interval. wouldnt that request additional program threads too? and to have a dynamic/nonpredictable range of a controller - im not sure if its a good idea - sometimes it would be impossible to reach the max. or min. value. am i getting this right?

however, its really good to see this going somewhere.

__________________
[kokoon]

dungle

It would seem that the 3 options have advantages in different situations.
1. course/fine, dynamic (e.g. a parameter which effects the pitch requires absolute accuracy!)
2. interpolate (e.g filter sweep, volume fade-> smoothness is more important than absolute value)

As the developers would agree, the easy options should be implemented first.
It would be great to be able to mix and match control methods depending on the parameter!
Although timer activated code would be necessary for interpolation, presumably the code to interpolate a variable would not be more than a few machine instructions and would occur in the milliseconds (or even 10mS?) timeframe.
In other words should not be resource intensive.
Also if the feature is not used by the user then there is no resource used.
best regards

kokoon

just dont make it ONLY interpolated and no coarse/fine controllable.

__________________
[kokoon]

Eugene Gavrilov

ok, I'll add coarse/fine control (yep, it shouldn't be too difficult)
according to the MIDI specs the controllers are numbered in the following way: Fine = Coarse + 32
that is, 'vol coarse=7; vol fine=39'
we probably need to make this tweakable via kX Automation window

as for the interpolation stuff:
here's the situation: the plugin receives a message from the mixer (which receives it from the kernel-level driver) -- MIDI controller change... it translates the logical value (0..127) into a set of hardware-dependent values (as a rule, any 'high-level' parameter is represented by a number of DSP registers); it then sets the corresponding hardware registers (GPRs)

now, a second message arrives, which differs from the previous one significantly (e.g. 32 -> 46)
either the mixer, or the plugin code should create a special timer which will translate one event into a serie of events (32,33,34,35...46). these events aren't synchroneous to the rest of the mixer/plugin operations (that is, during them a new MIDI event can happen) -- this will require a special queue

also, the 1ms delay isn't very efficient under Windows (10ms is much more better)
what latency do we expect to be acceptable?.. (for instance, interpolating from 0 to 127 will take 127*10ms=1270ms!)

/Eugene

dungle

hi eugene,
my vision of useful interpolation differs in function from what you have explained,
so here goes...
Say the user selects a 10mS "time constant".
This represents the time it takes for the output to achieve a certain proportion of the input.
In this example that proportion is 50%.(It could be something else..)
The "resolution" is how frequently outputs are made (as you point out 10mS is probably max).
I show tables to illustrate: (output is "hardware dependent value" rounded to 2 dp)
To use your example a 0 to 127 jump in control data would result in the following
time (mS)0 10 20 30 40 50
input 0 127 - - - -
output 0 63.5 95.25 111.13 119.06 123.03

same example With proportion 75%

time (mS)0 10 20 30 40 50
input 0 127 - - - -
output 0 95.25 119.06 125.02 126.5 126.9

A more typical example where it would be useful is a highly resonant filter sweep

time (mS)0 10 20 30 40 50
input 32 33 - - 34 -
output 32 32.25 32.94 32.98 33.75 33.94

formula:

x(n+1)=x(n)+P*(C-x(n))

where
P: proportion
C: new control value
x(n+1) is calculated every say 10mS

There are many ways of interpolating but the main points are:-
They geneterate extra inbetween values
There is a small delay in response due to smoothing effect
best regards
PS the messageboard does not recognize TAB so the columns of the data tables above do not line up however, it should be clear what numbers are in what columns

EDIT:
no queue is required because any new controller value for a given parameter simply updates the "C" term in the interpolation filter. This causes the output to track to the new target.

Eugene Gavrilov

ok, looks nice

so, the final implementation [RFC]:

1. add a new '14 bit' mode in the kX Automation (with two MIDI CC assignable)
2. add a new '7 bit (interpolated)' mode [unrelated to prev. mode]

interpolated mode:
two additional settings
* time resolution -- global setting -- (10 ms default)
* sensivity -- ("proportion" ) -- per-parameter setting (50% default; when set to 100%,
interpolation is OFF)

the formula is:
x(n+1)=x(n)+S*(T-x(n))

x(n)=present CC value
x(n+1)=next interpolated CC value
T=target CC value
S=sensivity (or approximation speed)

the x(n+1) value is calculated every 'time resolution' period
if x(n+1) == T -> stop timer

-=-=-=-=

the present method has one issue: a few initial CC changes won't be smooth
(that is, 0, 64, 95, 111...)

NOTE: similar code might be necessary for MIDI CC Pan simply because the hardware doesn't manage realtime pan changes w/o clicks... (so, the same code will be added to kernel-level driver, too, thus fixing MIDI CC Pan and DirectSound3D Pan clicking...)

-=-=-=-=-

any comments are welcome

/Eugene

dungle

"the present method has one issue: a few initial CC changes won't be smooth
(that is, 0, 64, 95, 111...)"

I'm not sure what you mean here, Eugene?

An issue may be that when the user loads a new song or begins playback they may not want the controller to slew to the first control value.

This suggests some kind of reset to the interpolation filter.

One simple strategy would be: if in condition"if x(n+1) == T -> stop timer" then the next CC for this parameter results in instant change with interpolation on subsequent CC's.

The main reason for interpolation outlined is to reduce the audible effects of Changing parameters A step change probably means the user wants instant response.

[crazy idea]
Allow the user to setup more than one Controller source for each DSP paramter. (e.g. User may want one with fast and also one with slower "sensitivity" settings OR say one with interpolation and also with course/fine so that the final state of the paramter is defined with absolute accuracy)
[end crazy idea]

Anyhow RFC proposal 1. and 2. look great.
best regards

kokoon

hooray!

__________________
[kokoon]

Eugene Gavrilov

>> the present method has one issue: a few initial CC changes won't be smooth
>> (that is, 0, 64, 95, 111...)"

that is, 0, 64, 95, 111

if the driver gets two MIDI messages: CC 0, CC 127, it will tweak the parameters in the following way:

0 ms: 0 [got CC 0 message; previous value was '0']
[got CC 127 message]
10 ms: 64
20 ms: 95
30 ms: 111
40 ms: 119
50 ms: 123
60 ms: 125
70 ms: 126
80 ms: 127

the first 3-4 changes aren't smooth

>> One simple strategy would be: if in condition"if x(n+1) == T -> stop timer" then the next
>> CC for this parameter results in instant change with interpolation on subsequent CC's

sounds logical
that is: if(timer was stopped) { instant change; } else { new target = CC Value; continue per-timer calculations... };
however, this behaviour should be selectable via kX Automation window
(some effects might cause clicks)

[crazy idea]
not so crazy -- might require more code changes, however... -- I'll keep this idea in mind

so, RFCv2:
* optional 'instant controller change' (which depends on the timer) -- we need a good and short term for this
* multiple ways of tweaking the same parameter (that is, not 'radio buttons', but a set of tabs)

/Eugene

dungle

yes, "interpolation reset" is not short, and not intuitive, but perhaps describes the behaviour in a technical way.

In the examples you give, Eugene, the output of interpolation is expressed as 7bit integers.
It is my understanding that the "hardware dependent" register values ("DSP inputs") are a greater than 7bit resolution (16/32bit ?). The drivers take the 7bit midi CC value and convert it into the "DSP inputs".

My understanding is that the interpolation output is a 7bit integer and a fraction part as well . This means that a change from say 64 to 65 and a small sensitivity (e.g. 20%) results in outputs:-
64. 2
64.36
64.488
64.5904
64.67232
.....etc
In this way the increased resolution affects the "DSP inputs" and hence plugin behaviour.
I just want make sure we're discussing the same concept sorry if I have repeated myself (from earlier posts).
regards

dungle

linear interpolation would produce a fixed number of evenly spaced values between previous and new CC's.

This would avoid/reduce the sudden changes that result from large change in CC data.

It would also provide a fixed tracking time to reach target value.

X=X+(newCC-prevCC)/Nsteps; {compute interpolation}
++count;
if count==Nsteps the stoptimer(); {have reached target value (X==newCC)}

where X is interpolated value (float)
newCC is most recently recieved CC data (7bit int)
prevCC is the previously recieved CC data (7bit int)
Nsteps is the number of steps (int)

I dont know which interpolation algorithm is best (proportional or linear or someother)
I guess if the framework is in the code to provide interpolation then the algorithm colud be selectable without a huge amount of extra coding.
regards

Daniel Drummond

Guys, I don't know a thing about programming, but I followed a discussion similar to this at the http://www.ucapps.de forum, where there's a DIY midibox. I don't remember the good solution, but they found one... Might be worth checking by someone who understands about programming...

__________________
www.palcomp3.com.br/ed

dungle

Daniel, could you post a direct link to the thread you saw?
(midibox only sends/receives/generates midi data whereas the kx automation uses midi data) However, with more info I may be able to comment.
thanks

Eugene Gavrilov

it would be rather difficult to interpolate -hardware- registers (32bit) simply because some of them might be non-linear
so, I suggest we do the following:

if interpolation is ON the driver will use 14bit, not 7-bit MIDI CCs, that is, it will use 14bit precision internally
this way the fraction part will be interpolated, too

so, we actually have a lot of possibilities
1. generic 7-bit
2. enhanced 14-bit (with two MIDI CCs assigned)
3. interpolated 7-bit which gets translated into 14bit
4. interpolated 14-bit (with two MIDI CCs assigned)

the difference between 1+3 and 2+4 is an additional MIDI CC

concerning the interpolation algorithms -- probably, this should be up-to-user
(linear, proportional, etc...)

/E

kokoon

any report possible on this? i just got m-audio radium49 yesterday and i found out i cant use it with kx automation very well...

__________________
[kokoon]

kokoon

i got another idea - how the midi could control the kx:

the midi controller value could mean the linear incrementation of the kx parameter - for example
- the value 63 would mean no change,
- the value 61 would mean slow linear decrementation of the assigned kx parameter,
- the value 0 would man the fastest linear decrementation,
- the valie 127 would mean the fastest linear incrementation.

this could really be useful, but it would again need a high-resolution timer.

now on this timer issue: is it possible to use only one timer with a combination of a queuing system for all the kx automation needs (interpolations, ...)?

could any non-cpu hardware be used for this? (midi interface?)

__________________
[kokoon]

Eugene Gavrilov

no, there's currently no progress in this direction
probably, later

/E

kokoon

uhh... ok. but it would be really useful. really. what about my idea about the alternate controller aplication?

__________________
[kokoon]