KVR Audio

Taron · Post by **Taron** » Tue Jul 18, 2017 3:48 pm

UH, Asio, hah, yeah... what's your buffer size?
Because this sounds to me like you might have a very large buffer size, way about 300ms, no?
This would explain a lot and could give you grief on a number of synths out there, while you may not even know it?!

Anyway, I must really tell you that I was very worried that this theremin type stuff would work at all, because it really can only update the tuning between buffer runs. This creates the appearance of glissando for you. On anything below 400 this would not be much trouble and still sound fairly smooth except at really quick, large slides.
What I thought about, was some sort of "render mode" OR a "theremin mode", that would be- hmmm- actually just like a mono mode, hehehe (

).

But, yeah, let me know about your buffer size, because I"m really curious! Also, you may experiment with small buffers, especially for rendering out!

AND PLEASE, check the version I just gave you with your noise filter frequencies automation. Those should really work well now!

nordickvr · Post by **nordickvr** » Tue Jul 18, 2017 3:59 pm

Is OS X still in your plan?
At least, IIRC, I read somewhere that you were thinking about porting it?
Anyway, that'd be amazing to be able to use it on Mac.
It really sounds good and looks very interesting to program.

RichardSemper · Post by **RichardSemper** » Tue Jul 18, 2017 4:26 pm

ASIO buffer settings can be a PITA! - Just been trying these out.
normally I set it to 50ms, seems to be fine for most stuff. With some vst's eg tunefish, vst2413 I had timing issues which needed it to be lowered to 10ms or lower, with others e.g. Synthmaster anything lower than 50ms causes glitches and/or distortion.
With yours I kept it to 50ms as had no latency problems, and CPU use is fine.
Just tried it again now on 10ms and its is much better for theremin effect, tried at 100ms and is much worse!
Who knew?

Taron · Post by **Taron** » Tue Jul 18, 2017 4:38 pm

Hmmm...I honestly don't quite know how Asio deals with buffers and what the ms really mean in that context, considering buffer sizes. From my perspective it's puzzling, because I can only use MME drivers for my crappy onboard soundcard (Realtek), which however works well at around 300ms. I really don't quite know nor fully understand, but the logic is correct that the glissando comes from large buffer sizes or intervals of changes coming from midi inputs.

As for OS X, yes, "El Capitan", but I still have to learn a lot about the mac, especially graphics and file I/O. I know nothing, yet. But I have everything here to go for it and already did compile that vst2413 on it successfully, because it had no GUI, haha!

But, yes, most certainly part of the plan and most certainly because of bjporter, who basically made it possible that I have a mac.

RichardSemper · Post by **RichardSemper** » Tue Jul 18, 2017 7:38 pm

Checked the new version:
Filter frequency automation works great

the other two issues I mentioned in the other thread remain:

1. [Saving a noise based patch with pitchbend set to 0 causes loss of sound from that instance - , reload needed to fix but happened again unless patch resaved with pitchbend >0]
testing this issue just now caused no problem when saving the patch, but when reloading the project that instance maxed the channel with total loss of the sound again, same with loading the patch. needed to resave the patch with pitchbend >0 to recover the patch.
I realise its a minor and easily avoidable issue, 99.9% of people will probably never notice

2. [Delay times sound wrong when reloading a project. Reloading each patch using delays fixes it, and moving the delay parameters or clicking the SYNC off then back on does too.]
looked more deeply at this, and seems to apply mainly when Sync is set to On, with one of the 'T' delay times.

Taron · Post by **Taron** » Tue Jul 18, 2017 7:50 pm

Ah, good, I'll look into those! THANK YOU!

Taron · Post by **Taron** » Tue Jul 18, 2017 8:18 pm

Try this one:
www.taron.de/Storage/vst/LotS_prerelease.rar

I've fixed both issues, I believe! Seems to work fine now. But it also fixes every sync related issue...funny I never noticed. :shug:

Awesome!!!

RichardSemper · Post by **RichardSemper** » Tue Jul 18, 2017 9:12 pm

Thank you Taron, a quick test seems to show both issues now history

aciddose · Post by **aciddose** » Wed Jul 19, 2017 8:22 pm

300ms refers to total buffer size in many cases (MME, DS, etc) which is then further divided into "chunks". So 16x 240ms = 15ms per chunk, minimum latency = 15ms; maximum latency = 240ms depending upon how far ahead the write pointer can get. (There is additional latency added by further stages; the audio buffer managed by the application is almost never the true primary buffer.)

In ASIO only single "whole" buffers are used so a similar timing for ASIO would be 16ms at 48k = 768 samples. It must take less than 16ms to generate including any variability in processing or overhead (includes PCIe communication!) which is why having a network card on the same bus or shared interrupts can cause major issues. ASIO does not provide the "maximum latency" end of the scale; min and max are equal.

This variable sync to visuals can make using such systems not just a pain due high latency but also due to increasing "jitter" as CPU load increases. The benefit is of course that the algorithms used to process the audio can include very expensive rare processing spikes (up to 224ms in my example case) and still avoid buffer underruns. Such algorithms are not suitable for ASIO buffering and so such an application would need to implement additional buffering on its own.

Taron · Post by **Taron** » Wed Jul 19, 2017 8:31 pm

And there you go again, aciddose, making my day with perfect information!

So the ms in Asio refer to chunk size, while other drivers look at the collected chunks, quasi. Very cool!

All this stuff can get somewhat confusing. The Audio Settings in MuLab, for example, speak of blocks, block size and threads.
For my current setup (MME) I'm using 8 blocks, with a block size of 375 and- well- auto(12) threads (Got a 12 core Xeon, assuming that that's about multithreading?!). All at 48khz.

What ever these settings mean, they make for a fairly smooth Theremin.

aciddose · Post by **aciddose** » Wed Jul 19, 2017 10:50 pm

Well since 8*375 = 3000 (62.5 ms) it's entirely possible they are using 375 samples as the block size. Generally you'd probably want to use powers of two there or at least multiples of 16 or 32; 384 would be very close (3*128).

It's very unlikely they can pull off 375 samples latency using MME/waveOutOpen and it definitely doesn't provide a reasonable block size when divided (47) as it's far too small. 375/48k = 7.8125 ms where <10 ms is usually considered a reasonable automation rate although <1 ms is preferred for direct modulation.

Taron · Post by **Taron** » Wed Jul 19, 2017 11:19 pm

Very interesting. I haven't ever really thought about this stuff much, simply because I used to just pick a given latency rather than entering block sizes and such. This is very good to know, thanks a lot!

Taron · Post by **Taron** » Mon Oct 02, 2017 8:56 am

Version 2.0.5 is up with a brand new website:
Lord of the Springs

You'll also find a selection of songs from the OSC#100, which featured LOTS.
The update has a new delay routine, which is somewhat unusual as you can automate the delay rate to create a number of classic, but also fascinating effects from ensemble like chorus to interesting harmonic type arpeggios, when in sync mode and more...
The noise filter now can also be smoothly automated.

wakax · Post by **wakax** » Wed Oct 18, 2017 12:01 pm

thank you:)
looking for the Mac port.

Taron · Post by **Taron** » Wed Oct 18, 2017 12:37 pm

AH! Yes, it's part of the plan. Some more things to learn for me, but I've got everything here to go for it!

Lord of the Springs v2- The New Powers