Hfo - High Frequency Oscillator

[jk123]

Just one thing:

If the Key-Tracking Device had a “Frequency Scaling” option outputting the frequency for the note played, you could actually control any LADSPA, VST synth, or filter device with it. This would achieve mostly the same thing, without the need to control parameters at the rate of the sampling frequency.

Small change -> big effect.

And I like the idea of Renoise becoming more of a modular synth!

[BYTE-Smasher]

@Phate

Just an FYI, at ridiculously high BPMs, the LFOs work like HFOs. (since the speed settings are line-based)

I’ve done FM in Renoise by creating a sample where the amplitude is maxed all the time, putting it on loop, setting the BPM to 500ish and the LPB really high, and controlling a ringmod with an LFO on the track where the sample is playing. From what I understand of Renoise’s timing system, this works because the LFO speeds are based on the subtick system, which is Renoise’s replacement for the original tick-based timing system. There are 256 subticks per line, so theoretically you could set the LPB and BPM high enough that the number of ticks per second approaches the number of samples per second.

At 450BPM with 36 LPB, you have 25636 subticks per beat. At 450 BPM, you have 7.5 beats per second, and so 7.536*256 gives you the subtick rate, which could be considered the [fingerquotes]sample rate[/fingerquotes] of Renoise’s timing system and the LFOs. This comes out to…uhh…69,120TPS, (ticks per second) or Hz. A sample rate of approx 69 KHz (according to the Nyquist/Shannon theorem) can accurately represent frequencies up to 34KHz. That’s higher than you or I are physically capable of hearing.

I realize that this would only be useful for sample-based synthesis within Renoise, but my point is that it is possible to achieve these sorts of results with the current system. It’s just not practical for real-time processing. However, give it a shot and see how your machine handles it. It (might) give you a vague idea of how Renoise would run if the timing system was synced to the sample rate.

Dunno if that makes sense. Maybe I’ll make a video. Might be fun.

Did it chew up your CPU like mad? 'Cause apparently HFO should do such things

[almosthuman (Phate)]

@BYTE-Smasher

Did it chew up your CPU like mad? 'Cause apparently HFO should do such things

I believe that I was using my old iMac when I tried it. Not sure on the CPU usage, but it did work. That means somewhere under 400MHz.

I haven’t done any VST development as of yet, so I can’t accurately say whether or not this is entirely practical from a technical standpoint. It does seem to work, though I’m fairly certain that VST parameters were never meant to be used in quite this way.

Then again, this was only tested with Renoise’s built-in effects. I’m not sure how similar they are to their standard VST brethren anyway.

[jk123]

I’m pretty sure that most (if not all) VSTs cache their parameters. It works like

1. Get parameters
2. Do stuff with the current sample block (like 512 samples)
3. Goto 1. (after everything else has been done for the current block)

So this would only work if you reduce the block size to 1… I. e., not.

But like I said… Making a “Frequency Scaling” option for the Key-Tracking device would achieve much the same thing

[almosthuman (Phate)]

@jk123

But like I said… Making a “Frequency Scaling” option for the Key-Tracking device would achieve much the same thing

Please explain how this is any different than making an HFO metadevice. Both would have to modulate parameters at the sample rate instead of the rate of the timing system. In fact, what you seem to be talking about is essentially a note-controlled HFO.

I believe that the issue is that the VST parameters don’t support the resolution required for HFO modulation. Of course, I don’t understand why buffering is a problem. The rate at which the buffer is filled ought to be the issue, but I’m not going to argue that because I have no experience writing VST plugins.

In fact, if somebody could explain why an HFO couldn’t just fill the parameter input buffer with a segment of the oscillation(s), I would be greatly appreciative. This is how most audio streams work, so it seems strange that this would only be a problem with VST input.

[edit] Wait, are you saying that the VST only polls the parameters once for each buffer refill? In that case, ignore everything I just said past the first paragraph. I still don’t understand how frequency scaling for the key-tracking device would solve this problem, though. [/edit]

[jk123]

@Phate

[edit] Wait, are you saying that the VST only polls the parameters once for each buffer refill? In that case, ignore everything I just said past the first paragraph. [/edit]

Yes, that’s exactly how it works for VST plugins as well as LADSPA plugins. I have some (limited) experience writing both. Audio is processed per-sample. Parameters are processed per-buffer.

So, even if you would change the parameters at the sample rate, the plugins would still only see the changes once per buffer.

I still don’t understand how frequency scaling for the key-tracking device would solve this problem, though.

You could, for example, control a filter frequency or a generator plugin frequency with the exact frequency of the note played. This is not the same as the original HFO suggestion of course, but it’s as close as you can get on a computer in real time. (“Things computers are good at”, etc, like taktik explained…)

Once you have the audio generated from the plugin chain, with the correct frequency and all, you CAN process it per-sample. So this would get relatively close to the HFO thing.

If you want true modular routing, check out AMS for example. It is controllable via MIDI, too. (IMHO, a bit more modular routing in Renoise would be cool…!)

[taktik]

@jk123

Yes, that’s exactly how it works for VST plugins as well as LADSPA plugins. I have some (limited) experience writing both. Audio is processed per-sample. Parameters are processed per-buffer.

So, even if you would change the parameters at the sample rate, the plugins would still only see the changes once per buffer.
You could, for example, control a filter frequency or a generator plugin frequency with the exact frequency of the note played. This is not the same as the original HFO suggestion of course, but it’s as close as you can get on a computer in real time. (“Things computers are good at”, etc, like taktik explained…)

No, most hosts, as we do, will then split the buffers at times where the parameter automation should happen. So in the worst case you would end up in processing (using the example above) 256 calls to calc buffers of 1 sample. This is exactly what I meant with the “massive overhead” you do get when doing this…

This means, a HFO is of course possible, it even is right now when using high LPBs as Phate pointed out, but we would have to live with that massive overhead. Thats the most inefficent way of doing synthesis. Should we really allow & push this?

[BYTE-Smasher]

I tried out the “using the lfo as an hfo with a really high tickrate” trick and it maxed out my CPU. Damn!

Oh well, I’ll just have to render to sample

[Johann]

@taktik

Should we really allow & push this?

Well hmm… doesn’t sound that hot for VST’s really… but if it’s possible to allow it without too much headache, may vote would be +1 for allowing and -1 for pushing it.

[taktik]

@Johann

Well hmm… doesn’t sound that hot for VST’s really… but if it’s possible to allow it without too much headache, may vote would be +1 for allowing and -1 for pushing it.

Perfect. This means you can simply do so now by using the high LPB workaround

[Johann]

yay! tag this [already implemented] then

[jk123]

@taktik

No, most hosts, as we do, will then split the buffers at times where the parameter automation should happen. So in the worst case you would end up in processing (using the example above) 256 calls to calc buffers of 1 sample. This is exactly what I meant with the “massive overhead” you do get when doing this…

This means, a HFO is of course possible, it even is right now when using high LPBs as Phate pointed out, but we would have to live with that massive overhead. Thats the most inefficent way of doing synthesis. Should we really allow & push this?

IMHO, no… Time is better spent on implementing a way to do modular routing!! And a frequency scaling option for the key tracking device to be used with it.

If Renoise had modular routing, we could do stuff like an HFO and other things, much more efficiently.

(BTW, you quoted me a little out of context… “You could, for example, control a filter frequency” etc. was related to the frequency scaling, not to the HFO.)