Maddogg6

I have trying my damnedest to get a grip on DSP programming and one thing that I was hoping for is a LFO.

Basically I'm hoping maybe some kind sole could possibly make a plugin that was like wave generator (By Eugene Gavrilov and eYagos, according to the source file credits) but had fractional increments for its frequency and possibly a 'bias' control that would be the equivelent to adding a +/- DC bias to the outputs.
I could make a OFFSET plugin alone in dane - but was ALSO hoping that this new wave gen plugin would also limit the ammount of available bias depending on the level of the generated wave (or vise - versa ie: limit level based on bias setting to avoid saturation).
So, it would never saturate the outputs.

This would only have to be applied to SIN/TRI/SAW outputs and NOT noise.

Here is a pic of how wavgen is with NO BIAS

Here is a pic that shows how the bias (or level) would be limited.

Here is a pic that shows, without limiting - would give undesired output.


Additioanlly - if the noise output was changed to more of a 'sample and hold' function, wihich maybe is just more limited noise output. But I dont know enough about it to be sure.

I hope I am clear enough of my desires.

Why do I want this. Well, it would be like a 'BUILDING BLOCK' I hope could lead to a set of 'BUILD BLOKX' set of plugins that one (or maybe just me - if its a dumb idea) could connect together and make dane only plugins in a modular way.

For instance - I made a flanger and used a modulation input - but wave gen unfortunately had too coarse of freq control. I did make a bias to change the RANGE of the modulation - but it would be best to have the LFO's BIAS/LEVEL be limited and part of the LFO itself.

I understand it may be asking too much... but I'm hoping.

Thanks in advance.

Edit.

Additionally - I hope Eugene will see this..

It would REALLY cool, that along with this LFO - that ALL KX Plugins would have a MOD input for each slider associated with that plugin. Thus, easy ability to have a sort of'time based automation' for anything adjustable within any plugin.
But I KNOW that thats a big request - so I wont even embarrase my self with an official request thread entry.

Russ

That is not really practicle. The modulation would have to be done in microcode, thus every plugin (along with the additional inputs), would need to have the code to implement the modulation, for every control it has. That would increase the size of every plugin (and thus decrease available DSP resources). It would be better to just create your own version of any plugins that you want to modulate this way.

BTW: In case you were wondering about doing it from outside of the microcode. That can be done now, using C++, but, Win32 Timers are not all that accurate to being with, and you add in the latency involved with reading and writing DSP registers (externally), it would not work very well.

Maddogg6

Hmm, I actually thought it would need to be done in C++ - for those cases that the slider *may* not be only 0-1 - I'd think a conversion would need to be implemented to cover all cases. But, ME IS A NOOB - so... Like I said - I won't embarass my self with any official request. But I do see that there would definitly be an increase in a plugins resource usage.
I also guess, I was assuming that - if that input is connected - dynamic dane code change could implant the 'dynamically controlled' sliders - other wise, if not connected - normal resource usage would then be the case.

Like I said - Im TRYING.. hehe

Russ

Hehe
You brought up another potential problem about using some kind of automatic modulation mechanism such as this. Mainly, how should it decide how to modulate sliders that can basically cover any range?

In any case, for the rest, eyagos is probably the person to talk to. You may want to send him a PM, as I am not sure how often he checks in on the forum these days.

Russ

BTW: What would be the purpose of adding a DC Bias to a LFO?

i.e.
I understand adding a DC Bias to the signal (for non-linear distortion, etc), but why to a LFO?

Maddogg6

Well, between a level, a bias & phase inversion - could be translated to the target range. Thus, why I figured C++ would be needed.

I imagined - upon translating the modulation input (upon connection??) - the C++ would translate the modulation range to match the sliders range (which i assume is actually already happening - as it appears that the GUI is just translating the sliders inherant -1 to 1 range into something that makes 'real world sense' or easier to understand its value and intent.

So in DANE i guess I imagined it looking like

macints sliderControl, 0, modulationInput, rangeFactor_i

- 'rangeFactor' would be determined by the C++ routine that translates the mod range (always -1 to 1) into the slders working range.
Now I know its not currently possible to 'control' a slider as they are read only - but I guess I imagined an alias that would NOT be read only and could internally change the slader much like KX automation does..

Now, one may wonder 'Why not just use KX automation to do this'
And yes - I can - BUT with some limitations, such as - MIDI PPQN & TEMPO interaction - at low PPQN & TEMPO, the CC output would leave a more noticable 'aliasing' affect - aka 'Zipper Noise/Artifacts' But - would also be MIDI tempo 'synced'

The LFO plugin - while loosing MIDI TEMPO sync - would avoid ZIPPER NOISE also.


Will do, thanks for the reply...