From the original SynthMaker forum (2004–2014), with its members’ names and dates.
aliasant ·
I need a way to calculate how many samples my schematic uses. Something that counts at samplerate ( eg. 48000 / sec )
Place it in the beginning of the chain and when it reaches the end of the chain it should stop the counter. Then we can see how many samples it counted before it stopped. I guess you need 2 modules for it. One in the beginning that send out the counter and one in the end that stops it and saves the result.
Has anyone built something like that?
stefan ·
If you use it for pure analysis and the process doesn't create any audio on its own I guess you could do something like:
streamin end; streamout start; streamout result;
float trig = 1; float counter = 0; start = trig; trig = 0; result = result + (result == 0 & ((start > 0 & counter) + (start < 0 & counter))); counter = counter + 1;
Maybe. Haven't tested it, so it's heavily prone to errors! 😉
hook "start" up to the input of your signal chain and the output of your chain to the "end" input. if it works at all that is 🙂
TomC ·
aliasant wrote: I need a way to calculate how many samples my schematic uses. Something that counts at samplerate ( eg. 48000 / sec )
For effects, I route a click-track through my plug-in and record the output to an audio track at the same time and compare the position of the original track to the recorded one.
Not very elegant, but easy and fast to do.
Tom
aliasant ·
Well TomC. A small code like the one Stefan tried to do would be Much much faster and simpler then having to make a vst of the parts I want to check. Then load it into a host and all that.
Stefan. It didnt quite work. I didnt get anything from the readout.
Also maybe it should have a boolin to start the thing?
stefan ·
aliasant wrote: Well TomC. A small code like the one Stefan tried to do would be Much much faster and simpler then having to make a vst of the parts I want to check. Then load it into a host and all that.
Stefan. It didnt quite work. I didnt get anything from the readout.
Also maybe it should have a boolin to start the thing?
Maybe. It starts when the process starts. I'll have a look again if I have the time later 🙂
aliasant ·
stefan wrote: aliasant wrote: Well TomC. A small code like the one Stefan tried to do would be Much much faster and simpler then having to make a vst of the parts I want to check. Then load it into a host and all that.
Stefan. It didnt quite work. I didnt get anything from the readout.
Also maybe it should have a boolin to start the thing?
Maybe. It starts when the process starts. I'll have a look again if I have the time later 🙂
Cool. Please do. It could make a useful tool for us all.
infuzion ·
I like the idea! Isn't latency reporting part of the VST spec? Might have to be a primitive though.
stefan ·
infuzion wrote: I like the idea! Isn't latency reporting part of the VST spec? Might have to be a primitive though.
We already have that part covered with the Delay Compensation primtive (introduced in 0.9.5w). Calculating the actual delay is what is being discussed here, but the reporting is already taken care of 🙂
aliasant ·
stefan wrote: infuzion wrote: I like the idea! Isn't latency reporting part of the VST spec? Might have to be a primitive though.
We already have that part covered with the Delay Compensation primtive (introduced in 0.9.5w). Calculating the actual delay is what is being discussed here, but the reporting is already taken care of 🙂
Yes. 😉 Any progress Stefan?
stefan ·
aliasant wrote: stefan wrote: infuzion wrote: I like the idea! Isn't latency reporting part of the VST spec? Might have to be a primitive though.
We already have that part covered with the Delay Compensation primtive (introduced in 0.9.5w). Calculating the actual delay is what is being discussed here, but the reporting is already taken care of 🙂
Yes. 😉 Any progress Stefan?
Haven't looked into it yet. The code is fairly straight-forward though, so maybe someone else can have a looksie too? 🙂
aliasant ·
Bugger. Ok ok ok. I will try but this is hard for a noob like me.
Edit... I give up already. Someone else pleeeease ? 😊
vortexblue ·
HI i have a problem and cant seem to find an answer i need to no what to do to fix the delay that i have when using the vst i have created whti synthmaker i have heard that you can impliment a componenet calld delay compensation butbeing new to this i dont no much about it or where to put it or wether that is indeed what i need to fix this issue.
MyCo ·
The easiest way to count a delay is by using a ramp signal and comparing the incoming ramp to the output ramp. But this way you can't do any manipulation to the signal itself. See attachment.
Disco_Steve ·
another way which works for compressors as well, is to use a linearly frequency modulated sine wave as the input, then compare the output with the input by multiplying the two sine waves together, the result is one sine wave being the sum and the other the diference, then fft the signal (at the highest window length) and read off the bin that represents the diference. from this the delay can be calculated, by dividing by the modulation rate.
this is the techneque used in FM CW radar systems, and can be incredibably acurate. should give sample acuracy for all porcessors under test.
i doubt anyone will use this method as I myself just use my ears, and a rough guide from the maths within the scematic.
steve
Disco_Steve ·
UMM might not work for LFO's
Wont work for LFO's
sorry
aliasant ·
Disco_Steve wrote: another way which works for compressors as well, is to use a linearly frequency modulated sine wave as the input, then compare the output with the input by multiplying the two sine waves together, the result is one sine wave being the sum and the other the diference, then fft the signal (at the highest window length) and read off the bin that represents the diference. from this the delay can be calculated, by dividing by the modulation rate.
this is the techneque used in FM CW radar systems, and can be incredibably acurate. should give sample acuracy for all porcessors under test.
i doubt anyone will use this method as I myself just use my ears, and a rough guide from the maths within the scematic.
steve
That sounds very interesting. Is it possible for you to put up an example? In other words... create this magic for us....
I think this should be a standard tool just like a freq analyzer or level meter. Just as important. Sometimes at least. I too mostly use my ears but sometimes it would be nice to know the exact latency.
Disco_Steve ·
Here you go. enjoy
theun ·
Here is a simple working version based on Stefan's idea. I added a reset button, to enease the possibility of doing some repeated measurements e.g. during/after changing the module under test. Be aware that you only will get useful information if the module (or part of a schematic) is completely "at rest", rephrased: it's output should be 0 before starting the measurement. Here is the code:
streamin end; streamboolin getlatency; streamboolout start; streamout result;
float counter;
start= (getlatency&1); result = (end != 0) & counter; counter = counter + (start & (end==0)& 1);
counter = counter*(start&1);
here is the osm:
aliasant ·
Incredible. Excellent. Seems to work pretty well. It seems to differ around 2 samples but its pretty close.
I made some small changes and skinned it to look like the CPU Analyzer that Andrew made. In this process I decided to take out the Modulation Freq knob. I set it to a fixed rate instead and it seems to work all te way up to Nyquist. Above that it starts acting weird but I dont think we are calculating latencies that high, are we?
Oh.
THANK YOU Disco_Steve You the man!
aliasant ·
theun wrote: Here is a simple working version based on Stefan's idea. I added a reset button, to enease the possibility of doing some repeated measurements e.g. during/after changing the module under test. Be aware that you only will get useful information if the module (or part of a schematic) is completely "at rest", rephrased: it's output should be 0 before starting the measurement.
Incredible =) Even better. This is very exact. At least in my simple testing. Again I made some changes. I added a "Clear Audio" and replaced the selector with a trigger that trigs the Clear Audio first. This way there is no need to manually clear it first. Also skinned it. Forgot to credit Stefan for the original idea 😊
aliasant ·
Ok .. 😉
I had to fix the skin a bit. made it a little sharper. Completely not necessary I know..... but what the heck. Also made my Andrew CPU Analyzer look about the same.
aliasant ·
Feel like Im spamming a bit here. Sorry.
Just tested the two latency testers and Theuns is the one that seems to work the best. But. Most things I try to calculate doesnt give me anything. Only one of the codeblocks gave a 1 sample output but when I connected another piece of code infront of it the result was again 0....
So. maybe the latencies are sub samples? Could your ( Theun) code calculate subsamples? Interpolated maybe?
sunsynth ·
We know you cannot withstand skinning 😉
Thanks - will check this out...
Walter
bootsy ·
aliasant wrote: Feel like Im spamming a bit here. Sorry.
go ahead 😉
Thanks to all - really usefull!!!
Andrew J ·
Off topic - but Bootsy I noticed your Tessla SE got a mention in SoS Mix Rescue. Congrats!
theun ·
@aliasant I like the skinning you've done!
aliasant wrote: Just tested the two latency testers and Theuns is the one that seems to work the best.
Actually there are already three sofar! I feel a bit ashamed, as I seem to have missed MyCo's solution at the previous page. Only after submitting my osm I found MyCo's. And (of course) his code is also both straightforward and correct:
streamin end; streamin trigger; streamout start; streamout result;
float counter = 0; float lasttrigger = 0;
counter = counter + 1; counter = counter - (lasttrigger<trigger) & counter; start = counter; result = start-end-1; lasttrigger = trigger;
aliasant wrote: Most things I try to calculate doesnt give me anything. Only one of the codeblocks gave a 1 sample output but when I connected another piece of code infront of it the result was again 0....
Difficult to say what happens without the osm's... First of all you should be able to isolate a part of a schematic that has a defined in and output. When you take a piece of code you need to have some basic understanding about what it does/is supposed to do. Generally speaking it may be a bit more difficult to visualize what it actually does, that's why we SM users like the graphical way of programming used by SM ... But even with non-code examples it is not always easy to predict latency issues. E.g. personally I would have thought that if I would turn the mix knob of the stock echo delay to the ultimate right there would only be delayed signal left, but somewhere deep down in the schematic there is a simple connection between in and out so the latency time measured will always be 0 samples. See schematic:
I'll show one other example, not being a delay (delay's are a bit trivial...)
When using the look ahead function of a compressor (here the SM stock compressor), the complete signal will be delayed, and yes, that's shown in the osm above.
aliasant wrote: So. maybe the latencies are sub samples? Could your ( Theun) code calculate subsamples? Interpolated maybe?
Quick answers: no, no and no. If you sample at say 48000 Hz this means SM will create 48000 samples each second. There are no "subsamples" or whatever between the samples. Just the 48000. Though I can understand the confusion the term "interpolated delay" may give. In a digital environment delays can always be expressed in a (whole) number (e.g. "n") of samples. However in cases where the delay is constantly varying (e.g in a chorus or phaser effect) rounding the calculated delay (e.g. 3015.246 samples) to whole numbers (in this case 3015) does not give acceptable results. The quantization error created that way is quite audible and sounds terrible. In an "interpolated delay" in this case e.g. a weighted average of the values for sample 3015 and 3016 will be calculated. I hope this is clear enough, though.
Ok, enough for now!
Cheers, Theun
aliasant ·
Hey Theun Thanx for replying. Well.
First about your first picture. The mix knob is not fully wet so a dry signal is let thru. Thats why I think?
My code parts are homebrewed and there for mostly secret =( For example, 1 is a series of lopassed filters + some basic math after that. 1 in and 1 out. 9 floats and 3 lines of code after that + in & out. Still it reports no latency what so ever.
Another one is this par sat:
// Parabolic Shaper from Reaktor streamin In; // -1 to +1 streamin Knee; // -1 to +1 streamout out;
float rect; rect = In * (1 - In < 0 & 2);
out = In * ((Knee + 1) -(rect * Knee));
This one reports 1 sample latency.
Another one has about 40 lines of code and still reports 0 latency.
It looks like the signal sent out by the analyzer gets lost in these but not in the par sat knee thing.
Here is a testbed I made. It is very strange. Either they report 0 latency or 1 latency. Look at the ones with sign code. With one module it reports 1 sample latency and with two of that same it still reports 1. The scanner does not report any latency although it has one 1 and 1 out.
And here is the osm.
theun ·
Hi Martin,
it's becoming a bit late here (I guess in Sweden too), so it's time to call it a day .... I'll look into it tomorrow!
Cheers
Tzarls ·
I haven´t done any test - I haven´t even read the analyzer´s code. But since everything related to code in SM runs at sample rate, isn´t it obvious that any piece of code of the "out = in * (favorite algorithm here)" kind will have a latency of 0-1 samples?. (the difference might be because of some inaccuracies in the analyzer I guess). Even more, since anything related to streams runs at sample rate, any dsp block using just streams will have a latency of 0-1 samples (unless you are intentionally delaying something).
And now that I think of it, even when using greens and streams, I guess SM executes the whole schematic at samplerate, so any DSP processing not involving buffering techniques (that is, convolution, group delays and such) will have a latency of 0-1 samples.
And to answer the original question (about how to find latency): If you have an schematic which stores 100 samples before starting the processing, the it´s very safe to say that latency will be 100 samples. So, in the end, to find an schematics latency, assume SM´s components introduce no latency, then take into account any latency introduced intentionally by you, and that´s it.
My 2 cents. 🙂
aliasant ·
Tzarls wrote: I haven´t done any test - I haven´t even read the analyzer´s code. But since everything related to code in SM runs at sample rate, isn´t it obvious that any piece of code of the "out = in * (favorite algorithm here)" kind will have a latency of 0-1 samples?.
Hmm. I must have this all wrong... Do you mean that if I have a piece of code. Lets say 4000 lines of code. Lets say simple math calcs like in * float1 / 4.53568 + ................ This would still only delay the signal 0 or 1 sample? What if it is 1 million lines of codes? A never ending calculation 😉 Would it still be only 0 or 1 sample latency???
stefan ·
aliasant wrote: Tzarls wrote: I haven´t done any test - I haven´t even read the analyzer´s code. But since everything related to code in SM runs at sample rate, isn´t it obvious that any piece of code of the "out = in * (favorite algorithm here)" kind will have a latency of 0-1 samples?.
Hmm. I must have this all wrong... Do you mean that if I have a piece of code. Lets say 4000 lines of code. Lets say simple math calcs like in * float1 / 4.53568 + ................ This would still only delay the signal 0 or 1 sample? What if it is 1 million lines of codes? A never ending calculation 😉 Would it still be only 0 or 1 sample latency???
Yes. The amount of code executed has nothing to do with the latency.
aliasant ·
stefan wrote: aliasant wrote: Tzarls wrote: I haven´t done any test - I haven´t even read the analyzer´s code. But since everything related to code in SM runs at sample rate, isn´t it obvious that any piece of code of the "out = in * (favorite algorithm here)" kind will have a latency of 0-1 samples?.
Hmm. I must have this all wrong... Do you mean that if I have a piece of code. Lets say 4000 lines of code. Lets say simple math calcs like in * float1 / 4.53568 + ................ This would still only delay the signal 0 or 1 sample? What if it is 1 million lines of codes? A never ending calculation 😉 Would it still be only 0 or 1 sample latency???
Yes. The amount of code executed has nothing to do with the latency.
Lol. I still think analog.
So you guys are telling me that a computer can compute 10000000000 equations in no time at all? Wow.
But why is there a 1 sample latency reported in most modules / codes that I have tested but not all? For example my scanner code reports 0 latency. What is that 1 sample delay?
stefan ·
aliasant wrote: Lol. I still think analog.
No you don't 🙂 The amount analog processes has no direct impact on latency either (only the analog processes that introduce latency, which some do)
aliasant wrote: So you guys are telling me that a computer can compute 10000000000 equations in no time at all? Wow.
No 🙂 Each computation takes time, but if that total time per calculated sample exceeds the length of each sample then there's not enough CPU power to calculate each sample. Otherwise, all calculations gets done for that sample, with no delay of the signal.
aliasant wrote: But why is there a 1 sample latency reported in most modules / codes that I have tested but not all? For example my scanner code reports 0 latency. What is that 1 sample delay?
I'm not sure, depends on the implementation of each module/code. If you have some very short snippets of code to share where one introduces a one sample delay and the other does not I'm sure we could break it down 🙂
aliasant ·
I'm not sure, depends on the implementation of each module/code. If you have some very short snippets of code to share where one introduces a one sample delay and the other does not I'm sure we could break it down
Sorry. no short public codes 😉
In the testbed I uploaded there is the Scanner code that gives a 0 latency but its asm.
Tzarls ·
aliasant wrote: But why is there a 1 sample latency reported in most modules / codes that I have tested but not all? For example my scanner code reports 0 latency. What is that 1 sample delay?
Well, the analyzer works using a feedback, and feedbacks happen at the next sample, so the analyzer has an inherent latency of 1 sample. Any latency reported by it is 1 sample higher than it should be. So, reports of 1 sample are actually latencies of 0 samples.
Off course, 0 sample latency becomes -1. And that can´t be. 😕
Tzarls ·
What about a piece of code with 2 inputs, 1 for "dry" signal, and one to conect the output of your effect. Then ,as soon as dry input changes from 0 to anything, start counting, and stop when fx input changes from 0 to anything. That should be very accurate and could be useful if you want to test a delay or something.
aliasant ·
Tzarls wrote: aliasant wrote: But why is there a 1 sample latency reported in most modules / codes that I have tested but not all? For example my scanner code reports 0 latency. What is that 1 sample delay?
Well, the analyzer works using a feedback, and feedbacks happen at the next sample, so the analyzer has an inherent latency of 1 sample. Any latency reported by it is 1 sample higher than it should be. So, reports of 1 sample are actually latencies of 0 samples.
Off course, 0 sample latency becomes -1. And that can´t be. 😕
Well. That is odd. How do you explain this then?
Disco_Steve ·
just a bit simpler than mine 😊
both techniques are radar ones 🙂, the above one is pulsed radar, mine is FM CW radar 🙂, i wonder wether there is dopler in dsp?
🙂
hansdump ·
Hello,
do you expect the same results on nonlinear systems, like guitar distiortion amps ?
I mean there goes some kind of sine in and some kind of rectangle comes out...
Does this pose a problem?
Thanks,
H.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker