Studio One... in my eyes it´s a bug, but...???

[Trancit]

Tested this with Voxengo's GEQ effect plugin and yes it does as shown in the above video, initiates number duplication. The behaviour is the same from 4.5.2 down to version 2.6 of Studio One.

My guess is that the issue resides within the code of that of VST plugins themselves. Each VST has an ID reference which is recalled and what I suspect is that the plugin doesn't have an incremented instance reference code. So rather than keeping track of the number of existing instances created, they add an additional value. In other words, the code is missing the variable to be able to increment properly. I've not tested in other DAWs to confirm if the results are the same though... In any case, you're best to use the plugs that do behave because it's not an issue that's sitting on Presonus's doorstep to be able to do anything about. Contact the plugin developers instead.

1. No, it doesn´t happen in any other DAW... it´s a S1 only feature ...
2. If it would be a problem of how S1 reacts to problems with ID conflicts, how comes that copying the same problem plugin via drag n drop from track to track works flawless...?
3. As it happens only in S1, I highly doubt that the problem is on the plugins side... my guess would be more towards Presonus...

[DaveClark]

Hmm, had to think a minute about this...
Don´t you think, this is a bit splitting hairs??

Their own plugins do not auto number regardless of what you do... this is in my eyes the desired behaviour... otherwise they would behave different imho...

If now a few 3rd party plugins behave different (only in S1, so a fault of S1) is for me definetely a aberration from the desired behaviour... this is for me a bug then... just because it´s not all 3rd party plugins... just these from a few developers...

If the plugins from a handful developers stop making noise in S1 (and only in S1) while the plugins from other developers do, would this be a bug for you??

Hi Trancit,

No, I don't think it's splitting hairs. This is the first step in assigning priority. Now I should say that I don't like the defnition I described and that it leads to bad relations with users. I'm just telling you the most likely reason why they consider it not to be a bug.

Although the behavior is an aberration from your point of view, that behavior may never have even been considered by the developers. You would have to prove that it was considered and that they designed it to behave in some other way than it actually behaves in order for it to be considered to be a "bug" under the definition that they appear to be using.

On your last question, and taking into account the definition of "bug" used by many if not most software companies, one would (again) need to know whether or not the developers considered this behavior and designed the plugin to behave like that or not. Although you may feel that this would be impossible to consider and design in that way, I would respond that to the extent that your question is an unrealistic scenario, it is also a failed reductio ad absurdum argument.

Again, whether we like it or not, this is how complaints are handled at many sofware companies.

Regards,
Dave Clark

[Trancit]

Hi Trancit,

No, I don't think it's splitting hairs. This is the first step in assigning priority. Now I should say that I don't like the defnition I described and that it leads to bad relations with users. I'm just telling you the most likely reason why they consider it not to be a bug.

Although the behavior is an aberration from your point of view, that behavior may never have even been considered by the developers. You would have to prove that it was considered and that they designed it to behave in some other way than it actually behaves in order for it to be considered to be a "bug" under the definition that they appear to be using.

On your last question, and taking into account the definition of "bug" used by many if not most software companies, one would (again) need to know whether or not the developers considered this behavior and designed the plugin to behave like that or not. Although you may feel that this would be impossible to consider and design in that way, I would respond that to the extent that your question is an unrealistic scenario, it is also a failed reductio ad absurdum argument.

Again, whether we like it or not, this is how complaints are handled at many sofware companies.

Regards,
Dave Clark

I am still not convinced, but thx anyway for participating here