KVR Audio

D-Fusion · Post by **D-Fusion** » Wed Oct 10, 2007 8:22 pm

double post

aciddose · Post by **aciddose** » Thu Oct 11, 2007 7:19 am

t is almost definitely not a bug in xhip. review the source code if you like. the description of the problem is detailed in the source comments.

the problem is that either:

1) the host sends event packets where the events occur out of order. this would mean detla 500 occurs first, then delta 64, then delta 92, then delta 501. this means that in order for xhip to accept these events it would need to sort the list manually when detecting out-of-order events. since the vst spec does not allow out-of-order events, this is a bug with the hosts and not with xhip. i will not fix xhip - the hosts must be fixed.

xhip's behaviour in this case is to skip all out-of-order events until arriving at a block of sequential events. those events are then processed while out-of-order events are ignored.

2) the host sends multiple event packets between process() calls. the spec again does not allow for this. the host must combine and sort all events before they are sent to the plugin and processevents() should be called only once for each call to process(). in order to fix this it would require that xhip allow insertion of events into the list combined with sorting.

xhip's behaviour in this case is to absolutely ignore any extra calls to processevents() until process() has been called.

the only way that notes can be 'stuck' is if the note-off event is never sent by the host or if the events arrive out of order. (for example, note-off comes before the note-on.)

djex · Post by **djex** » Thu Oct 11, 2007 8:26 am

It could be my imagination but I can't find those restrictions--that processEvents() passes the events in sorted order, and that it is called at most once between process() calls--documented anywhere in the VST SDK. Most hosts indeed implement the VST protocol that way, but unless I missed smt (which, considering the extremely organized nature of the SDK is well possible) these requirements are not written in stone.

If I did overlook it, please prove me wrong!

-- dj!

aciddose · Post by **aciddose** » Thu Oct 11, 2007 10:41 am

they're definitely not written anywhere, but the fact that none of the reference implementations provided in the 'sdk' contain sorting of events or insert-sort means that it is not expected to be preformed, which means events are expected to be sent in-order.

the spec is very poorly documented - i would have to say that evidence points to my point of view being correct and ask that anyone in disagreement point to evidence of their own point of view. there is no evidence to my knowledge that out-of-order events should be expected and it is just as equally as what i say lacking any specification of such in writing.

the reason is simple: the 'sdk' is designed for plugin implementation, not host implementation. that means it only deals with what the plugin must implement. host-side sorting need not be specified at all - it is just assumed to take place. other host implementations according to steinberg are _not_ correct vst implementations. only steinberg's implementation should be used as a reference. all of the hosts provided by steinberg operate in the way i have described.

i can (and plan to) implement sorting as a 'fix' for hosts not following proper procedure however i'd like everyone to know this is not a xhip bug and it is not high priority.

djex · Post by **djex** » Thu Oct 11, 2007 11:52 am

The one and only relevant reference implementation in the SDK--VstXSynth--indeed does not implement sorting of events. Then again, neither does it implement polyphony, multiple outputs, offline processing, and lots of other things. Moreover, the source code claims that it is a "*very* basic example. you should not attempt to use this example to start a serious virtual instrument". So claiming that because it's not in the reference implementation no plugin shd have to implement it" is not that strong an argument.

And nowhere does the example assume that processEvents() is called only once between two process() calls. It won't play properly with multiple calls, but it has the same problem when a note is played and released within the same process() block. So where does the justification for this restriction come from then?

Of course you are free to do with xhip whatever you please. But pointing the finger at Sonar without proper and indisputable justification is not the polite way to go.

-- dj!

Paulie Phonick · Post by **Paulie Phonick** » Thu Oct 11, 2007 11:58 am

Heh, just please don't spend more time arguing about this than coding the actual fix would take

Kyran · Post by **Kyran** » Thu Oct 11, 2007 12:58 pm

Aciddose's claim that they are to be send in order is that Steinberg's hosts send them in order, and that the sdk defines plugins, not hosts. According to steinberg, only their implementation is correct. So if it works in cubase and not in sonar and doesn't violate the vst sdk, the problem lies with sonar.
Seems a pretty robust logic to me.

whyterabbyt · Post by **whyterabbyt** » Thu Oct 11, 2007 1:30 pm

Kyran wrote:According to steinberg, only their implementation is correct.

Where have Steinberg stated that only their host-side behaviour is correct?

You do know they only provide 'samples' in the SDK, there is no 'reference implementation' included.

Consider this: how can Steinberg's own plugins work in Sonar if they dont implement event-sorting?

So if it works in cubase and not in sonar and doesn't violate the vst sdk, the problem lies with sonar.

Not if the behaviour used by Sonar is not expressly ruled out within the VST plugin specification, no. It is not enough to observe the behavour of Cubase and claim 'Steinberg do this, so only this may be done'.
I cant find anywhere in the SDK that it specifically rules it out; can you?

Question : if events should never be sorted, why is VstEvent::deltaFrames declared as being 'sample frames related to the current block start sample position', rather than something like 'sample frames related to the previous event time', which would explicitly mandate time-sorting ??

whyterabbyt · Post by **whyterabbyt** » Thu Oct 11, 2007 1:37 pm

aciddose wrote:i can (and plan to) implement sorting as a 'fix' for hosts not following proper procedure however i'd like everyone to know this is not a xhip bug and it is not high priority.

Its definitely not a bug; its merely an assumption that input data will be received in a particular form, when it may not be. A result of an incomplete specification, basically.

As for 'proper' procedure, thats probably best for the SDK mailing list. I know there's at least one event-sort on the music-dsp archive, so its not unexpected behaviour even if you dont consider it 'proper'.

aciddose · Post by **aciddose** » Thu Oct 11, 2007 1:45 pm

it is unexpected behaviour. if you'd like to hear steinberg themselves say that only their implementations are correct, all you need to do is ask them: "which hosts can i use as a reference when developing vst plugins?"

in any case, if you'd really like event sorting code it in yourself.

AdmiralQuality · Post by **AdmiralQuality** » Thu Oct 11, 2007 1:46 pm

whyterabbyt · Post by **whyterabbyt** » Thu Oct 11, 2007 1:54 pm

aciddose wrote:it is unexpected behaviour.

something which most plugin developers know to expect is unexpected? umm, okay.

if you'd like to hear steinberg themselves say that only their implementations are correct, all you need to do is ask them: "which hosts can i use as a reference when developing vst plugins?"

Umm, no. If I really wanted steinberg to tell me that their hosts can be used as a reference, I'd ask that question. On the other hand, if I wanted to know if any other behaviour than sorted events was acceptable, I'd ask the right question.

I see you dont care to address my question about the definition of VstEvent::deltaFrames, or why Steinberg plugins clearly already support event-sorting. Lazy, or just avoiding the issue?

in any case, if you'd really like event sorting code it in yourself.

if i really cared, i would.

aciddose · Post by **aciddose** » Thu Oct 11, 2007 1:54 pm

fairly amusing aq isnt it, especially when the fact is that when a user asks you for a feature you do not want to implement, you tell them "sorry, it'll never happen. goodbye."

disturb · Post by **disturb** » Thu Oct 11, 2007 2:09 pm

AdmiralQuality wrote:

oh noooeeeessssss

AdmiralQuality · Post by **AdmiralQuality** » Thu Oct 11, 2007 2:10 pm

aciddose wrote:fairly amusing aq isnt it, especially when the fact is that when a user asks you for a feature you do not want to implement, you tell them "sorry, it'll never happen. goodbye."

Does Poly-Ana exhibit this bug in Sonar? Cuz she don't sort either.

Again, this is yet another example of your "customers" getting what they paid for and you blaming the entire industry for your own lazy mistakes.

I'll go away now, just had to have a little giggle at your attitude.

Edit: Oh and there you go mis-quoting me again. Though if a feature isn't ever going to happen that's exacty what I'd tell someone. Can't recall the instance you're pretending to refer to though. Most requests have been for an alternate GUI and better CPU performance, both of which WILL probably happen. Hello.

XHip--Please finish your synth!!