About CAT

[camsr]

It looks as the rate of smoothing would change based on how deltaTime changes. That's not entirely true though, because the smoothing filter could be only sensitive to changes in amplitude (slew rate limiting) and not the current amplitude.

The goal of deltaTime looks to be that the signal reaches some defined value at that point (whether generated heuristically or not). How it gets there is open to interpretation. It may even only be near the target value at that time.

[beginzone]

Is it a problem that for "starting a envelope segment", you need two events?

You don't. You start from whatever there previous value in the plugin was.

If the host wants to be sure about a certain "start" (of a segment):

Would it try to keep track of the parameter value inside of the plugin?
Or would it ask the plugin for the current parameter value via an opcode?

Or would it try to set the parameter value to X (to reach Y approximately at 50)? Like this:
1) event 1 with delta 0: targetValue=x; smoothFrames=0;
2) event 2 with delta 0: targetValue=y; smoothFrames=50;

I'm not sure what the host is able to control or determine.

Sorry, I wanted to say: I'm curious if this would be encouraged host behaviour, because it looks like I could try to let my host always be sure about segment points by just snapping there. And this would need two events for each of these points.

So I guess that, the system should simply "not be abused" for segments in that sense. It's complicated for me to think about it. Not that I dislike the event structure.

I was just thinking of a theoretical event.smoothFramesMustLinear which just would force the plugin to reach the targetValue. But I have a feeling that this isn't what mystran you tried to achieve with his your structure members. Edit: Was reading it again, and realized that I drifted away and thought I would speak to camsr, sorry! Didn't intend to sound impolite.

Maybe, I should simply not view it as a segments list. Though, I'm under the impression that control isn't easy, but could in theory be. But, to be honest, I don't want to suggest to add any linear thing for a purpose that only I thought of most of the time.

That is why I tried to separate the topics "live" and "planned", although that wording is probably not good.

[mystran]

The goal of deltaTime looks to be that the signal reaches some defined value at that point (whether generated heuristically or not). How it gets there is open to interpretation. It may even only be near the target value at that time.

My intention was actually that the deltaTime is the time at which the plugin should process the event (ie. start smoothing). Otherwise you need to process the events in a non-linear order, which kinda defeats the whole purpose of having a simple event list.

[camsr]

Okay I have confusion on this event idea then. I thought deltaTime was the thing that determined when a new input has occured? I have not used events in VST2 before (most my plugins are simple audio effect processors), I am not even familiar with how it works.

[camsr]

Streaming a buffer of control signal values at audio rate or below is my main concern. If we wish to downsample these signals, we could simply use a buffer of values, that are located in time by a second buffer with offsets, which are either relative to the last offset or absolute from the start of the buffer. Things being out-of-order are disconcerting

[mystran]

Okay I have confusion on this event idea then. I thought deltaTime was the thing that determined when a new input has occured? I have not used events in VST2 before (most my plugins are simple audio effect processors), I am not even familiar with how it works.

So deltaTime is the offset from the beginning of the current block. For example, if you have a block of 256 samples and one of the events has a deltaTime of 128 then the event happens halfway through the block. This is the same as how they work in VST2 as well, except as far as only MIDI events are commonly in use.

[Vokbuz]

May I ask, do you know what events to generate to transmit a signal like pitch or cutoff, or something like this, with high precision to the plugin?

32-bit float precision is not enough?

[S0lo]

I think offering many optional features in an API is no problem as long as every such feature has a default behavior that is sensibly chosen to offer 80%+ of developers what they most likely want. Notice that developers themselves don't always know what they want or what they should want to satisfy their user base.

These chosen default behaviors would relief advanced developers from having to decide and implement each and every option. And would be easier for beginners who are still taking baby steps into plugin development.

The ideal way to choose these defaults is probably to conduct surveys and collect statistics. But I understand that this may not always be easy. So some educated guesses might serve well.

[mystran]

You can't really have "default behaviour" in an ABI, because an ABI is a contract on how to communicate, not an actual piece of code. With every "optional" feature you also risk the potential explosion of permutations on what does and doesn't work and while this makes sense for certain features, in other cases it just ends up being more complicated than forcing everyone to implement the whole thing.

As far as beginners are concerned, I don't think they should be working on a raw ABI level. They should be using some high-level framework that deals with the low-level ABI details, or at least some high-level wrapper that provides those "sensible defaults" for them. That said, there isn't much point in trying to actually write such a high-level wrapper before you first know what the raw beginner-hostile ABI is going to look like.

[Guillaume Piolat]

What's wrong with LV2?
We've implemented it in Dplug, it has a variety of existing hosts, and it already exists. If anything the plugin client code is shorter than the one for AAX or VST3. It was the easiest of all plugin formats.
LV2 is (to a fault?) twisted towards extensibility, and has a very "designed" feel to it. And indeed, the design of this format took a lot of time.

I fear this format has been underservedly treated due to being a bit different than VST2/VST3/AU/AAX, there is bit of a learning curve due to the .ttl XSD language.
So, I'm just saying that LV2 can be used by plugin makers very quickly, because the spec is already done.

Apart from that, I feel like making another community format however superior, would in the end fight the same adoption battle and split the little goodwill there is.

[S0lo]

Defaults involving higher level API (Not ABI). Values like default block size, refresh rates, smoothing times. Implementation of useful curves, default functions for saving presets/states based only on parameter values. functions that ease interpreting MIDI messages. etc..

In slang, What I want to say is, the down side of having "too many options" can be lessened by providing automatic stuff.

On the other hand one could go for a minimalistic approach and provide only the necessary features. Leave the rest for the dev to do his own way. Or go for a fully blown API with all what you wish (say VST3, not saying that it actually does that ) and assume that the dev is capable enough to figure it out.

[beginzone]

What's wrong with LV2?
We've implemented it in Dplug, it has a variety of existing hosts, and it already exists. If anything the plugin client code is shorter than the one for AAX or VST3. It was the easiest of all plugin formats.
LV2 is (to a fault?) twisted towards extensibility, and has a very "designed" feel to it. And indeed, the design of this format took a lot of time.

I fear this format has been underservedly treated due to being a bit different than VST2/VST3/AU/AAX, there is bit of a learning curve due to the .ttl XSD language.
So, I'm just saying that LV2 can be used by plugin makers very quickly, because the spec is already done.

Apart from that, I feel like making another community format however superior, would in the end fight the same adoption battle and split the little goodwill there is.

I believe, there's not much wrong with LV2.

Does LV2 define how overlapping MIDI notes are handled?
The XSD thing doesn't look like fun, but surely must have some important purpose, hopefully.
And I like public domain licensing more. For its simplicity.

Adoption battle is a problem for the acceptance of Linux, isn't it? I'm afraid you're right about LV2 and Opi (CAT). But I'm not sure what I really think about it, I use Windows most of the time.

[camsr]

I would like to see all the parameters of the plugin exposed to the host, for facilitating custom control panels. If some of these parameters are unsuitable for modulation, there should be a flag to indicate this and similar qualities. The host could maybe also override these flags in a corner case that modulation does work under certain circumstances (silence, transport stopped, etc.)

[Music Engineer]

I would like to see all the parameters of the plugin exposed to the host

that assumes that the set of parameters is fixed. what about an equalizer with an arbitrary number of bands that are created dynamically? or an envelope generator with an arbitrary number of breakpoints? or maybe it doesn't? ...hmmm...well...you could perhaps create an api that involves callbacks or opcodes like "parameterAdded", "parameterRemoved", etc. this would have to be a plugin-to-host request

[mystran]

I would like to see all the parameters of the plugin exposed to the host

that assumes that the set of parameters is fixed. what about an equalizer with an arbitrary number of bands that are created dynamically? or an envelope generator with an arbitrary number of breakpoints? or maybe it doesn't? ...hmmm...well...you could perhaps create an api that involves callbacks or opcodes like "parameterAdded", "parameterRemoved", etc. this would have to be a plugin-to-host request

Parameters alone won't solve the problem for custom editors though, since not everything you can do in a complex plugin editor is necessarily something that can be made into a parameter, but it would certainly be nice for the purpose of automation.

There's a few complications though, like specifying how to synchronize threads with regards to such changes and also whether to then just go with arbitrary IDs (but maybe the ID should still be used as a sorting key for UI?), given that the set of parameter indexes might not remain continuous anymore.