Changes between AudioAnalyzer v1.1.5 to v2.0 discussion

[d-uzlov]

Next release version of the plugin is planned to break compatibility. As plugin contains a lot of options that aren't convenient to use but were preserved for the sake of compatibility, this next version will bring a lot of changes. I believe it would be best to isolate information of these changes in one issue. After next public release this issue should be closed, all further changes will have separate discussion threads.

I will post new comments here when I change anything. Also I will post my thoughts on possible changes. Everyone interested are welcome to make suggestions for what should be changed.

[d-uzlov]

Fixed in new release

[d-uzlov]

Honestly, one thing I regret is not using {} for sub-sub-options for 2.0 release.

[d-uzlov]

Oh. UpdateRate for images now have high bound 20000 UpdateRate in TimeResampler now have high bound 2000

[LI7XI]

>resolution 0.6 correspond to updaterate 1000/0.6 == 1666.666. But highest allowed value is 200, 1666 is out of range. P.S oh, it's fixed! :D >Update rate in threading determines how often plugin tries to update its values. In threading is force update or something similar, and in handlers is normal update? >There certainly shouldn't be such limitations on handler update rate. Threading has this limitation because it doesn't make sense to update faster, but handlers operate on different data. Why not just match it with the skin `Update`? I mean even for separate thread, actually, why not always make it separate thread (no ui thread available) and make UpdateRate always equal to skin `Update`? This almost means Threading option is removed :| >Honestly, one thing I regret is not using {} for sub-sub-options for 2.0 release. hmm... i guess it's better to do it now before we post the plugin in the forum. Go for it 👍 >UpdateRate for images now have high bound 20000 UpdateRate in TimeResampler now have high bound 2000 I'm really sorry about the amount of complains, bbbut.. how can this be documented? don't you think it's ultra confusing? Also i don't always understand the word "bound", how about limit? vwv

[d-uzlov]

Update rate in threading determines how often plugin tries to update its values.

In threading is force update or something similar, and in handlers is normal update?

UpdateRate 60 in threading means that 60 times per second plugin will try to fetch new data from windows and then transfer that data to handlers for them to update. Handlers can be updated several times per one update request, and they will keep their data as if there were more updates. Effectively handlers update at infinite speed, because they don't lose any intermediate values when you update them rarely, you just sample their values at your own not-so-high rate (determined by update rate in threading and update rate of the skin). UpdataRate 1000 in a handler (for example, in waveform) will mean that 1000 times per second handler will draw a new line on the image. If threading have UpdateRate 60, then there will be 60 requests for update, during most of which handler will draw 17 lines.

By the way, changing resolution to updaterate is really just a name change. The mechanism of how handlers update didn't change, I just thought that it would be more convenient to use updates per second instead of resolution as 1000 ms / updates per second.

Why not just match it with the skin Update? I mean even for separate thread, actually, why not always make it separate thread (no ui thread available) and make UpdateRate always equal to skin Update?

I don't think a plugin can get update rate of a skin. If you know of some method to obtain it (like, maybe with some built-in variables or section variables), tell me, I will make default value match update rate of the skin the measure is used in.

I'm really sorry about the amount of complains, bbbut.. how can this be documented? don't you think it's ultra confusing?

"Image will have UpdateRate new lines each second". "TimeResampler will generate UpdateRate new values each second". Something like this. Much less confusing than resolution or granularity, I believe.

Also i don't always understand the word "bound", how about limit? vwv

It's not like this is different from other options. "Value of UpdateRate must be in range [1, 20000]".

[d-uzlov]

hmm... i guess it's better to do it now before we post the plugin in the forum. Go for it 👍

I feel like the "release" label has already cemented it.

[LI7XI]

UpdateRate 60 in threading means that 60 times per second plugin will try to fetch new data from windows and then transfer that data to handlers for them to update. If threading have UpdateRate 60, then there will be 60 requests for update, during most of which handler will draw 17 lines.

Oh, now it makes sense :D I should mention that somewhere in parent page, and maybe in tips discussion as well.

One last thing, updateRate in threading only determines how often the plugin get's audio data from windows (from audio device?), and the handlers are free to calculate it whenever they want(they are not forced to do it based on threading updateRate), and child measures will just retrieve it from handlers based on skin Update.

Is that how it is?

I don't think a plugin can get update rate of a skin.

Hmm, i thought it's exposed in the Api. I don't think it's possible.

By the way, changing resolution to updaterate is really just a name change. Much less confusing than resolution or granularity, I believe.

At first i thought there was an internal difference between res and updateRate, now it makes sense since it's just calculation difference (how handler update rate is calculated). The word "granularity" confused me a bit at first, UpdateRate sounds better in that regard.

I feel like the "release" label has already cemented it.

AudioAnalyzer v2.1.0 maybe?🌚 or let's call it a bug and post v2.0.6 🌚🌚

[d-uzlov]

One last thing, updateRate in threading only determines how often the plugin get's audio data from windows (from audio device?), and the handlers are free to calculate it whenever they want(they are not forced to do it based on threading updateRate), and child measures will just retrieve it from handlers based on skin Update.

Is that how it is?

No. Handlers only update when they are requested to (and rate of how often they are requested is determined by update rate in threading), and when they are requested, they process all of the data fetched from windows. In fact, handlers count time based on how much data they receive, because on normal conditions data rate is constant, and this allows for pretty precise (and universal across handlers) time tracking.

Though, for a plugin user this doesn't make any difference.

I feel like the "release" label has already cemented it.

AudioAnalyzer v2.1.0 maybe?🌚 or let's call it a bug and post v2.0.6 🌚🌚

Well, v2.1 won't help unless the plugin name is changed. And I don't really sure if it would be ethical to call this a bug as some users could already downloaded and used the v2.0, and they certainly wouldn't want to rewrite their skins.

[LI7XI]

Hey, in this issue you mentioned that setting radius to 1 won't actually disable blur.

But in the docs we said:

Radius: A float number that is bigger or equal to 0.

Should that be changed to 1? i mean what's the minimum value?

[d-uzlov]

Should that be changed to 1? i mean what's the minimum value?

That's an interesting question. I don't know. I added a check that if some value produces blur coefficients array of size 1, so blur doesn't work, then error is raised. I don't know which value is a minimum to make it not happen. You can experiment and see for yourself which minimum value works. If you are feeling lazy, write that the minimum value is 1. Or 0.5, if it works. It won't change much either way.

[LI7XI]

If you are feeling lazy, write that the minimum value is 1. Or 0.5, if it works. It won't change much either way.

I'll use 1.

---

What about this? still from 0.01 to 60 or it's also from 1 to 2000?

[d-uzlov]

What about this? still from 0.01 to 60 or it's also from 1 to 2000?

Still 60. I don't think higher values make sense for loudness.

[LI7XI]

UpdateRate for images now have high bound 20000 UpdateRate in TimeResampler now have high bound 2000

UpdateRate in Threading still from 1 to 200?

[d-uzlov]

UpdateRate in Threading still from 1 to 200?

Yes, still 200.

Actually, as far as I know, Windows only generates new audio data packets 100 times per second, so maybe max value should be reduced. On the other hand, ideally we would want to implement an even-based approach, so we don't "try to update X times per second" and instead "update as soon as there is new data", but this requires research on WASAPI, and I don't really feel like doing this. Maybe I should add this to a todo list when plugin get a formal one, or something.