XHip--Please finish your synth!!

[erebus]

a good example of what that means has already been mentioned. the spec says that hosts can return through getcurrentprocesslevel the current process level, but it does not say that they must always return the 'correct' value. it doesnt specify what the correct values are or how to deal with them. it doesnt say that a host must respond to this request at all.

with all due respect, but that makes absolutely no sense at all. the vst specs also define

virtual void* getDirectory ();
Returns the plug's containing directory.

but nowhere does it say that it has to return the 'correct' value. shd we therefore assume that the directory it returns can be anything and does not actually need to contain the plugin? even worse,

virtual float getSampleRate ();
Returns the current sample rate.

but the sdk doesn't say that the host has to return the 'correct' samplerate when thus asked.

i mean... come on! i can only assume you're joking.

[aciddose]

yes but exactly what "processlevel" means is not defined.

"Returns the hosts's process level. A plug is like a black box processing some audio coming in on some inputs (if any) and going out of some outputs (if any). This may be used to do offline or real-time processing, and sometimes it may be desirable to know the current context."

it doesnt say that a host must return offline if it isnt actually processing 'realtime'. more importantly my point was that it doesnt define the host's behaviour at all, it only defines what a plugin should expect. it says that the function will return "a" process level, it doesnt say it will be the 'correct' process level based upon any particular definition of 'correct'.

getsamplerate() could return 1000.0 when the actual sample rate is 48000.0. the spec doesnt define anywhere that the host "must tell the exact rate of the hardware audio output device" - in fact we might be doing offline processing where there isnt any real hardware audio rate at all. once again it doesnt define anything regarding what the host must do, it only tells what a plugin can expect.

so, you can expect that you'll get a number from getsamplerate(), does the spec even say it must be positive?

you can expect you'll get a processlevel value from getcurrentprocesslevel(), does the spec even say it must be a particular value at a particular time, or in a particular range?

[erebus]

does the vst sdk explicitly state anywhere that what is defined in the sdk is correct?

either you just don't want to admit you're wrong, or you've completely lost it. over and out.

[aciddose]

are you actually paying attention to what i've said?

"does the spec even say it must be positive?"

no.

"does the spec even say it must be a particular value at a particular time, or in a particular range?"

no.

it was said that you can not use a particular host as a reference because it "behaves contrary to the specification". i'm only pointing out here that the specification says nothing about what a host must do - it only specifies plugin behaviour. it says that a plugin should expect that it will get a context value back from the host using this function - however it does not say that the host must give a particular value under particular conditions. you would think if it were processing offline it would return the offline status, however it does not. it does not say in the spec that "if you call this function, you'll definitely get this value back under this particular condition".

same thing applies to sorting events. it never says "the event list might not be ordered" or "plugins must manage sorting of events on their own." one argument was that "neither does it say hosts must manage sorting of events." that argument is invalid however as the specification says nothing about host behaviour, it merely specifies plugin behaviour.

"does the vst sdk explicitly state anywhere that what is defined in the sdk is correct?"

no, and this is the result of supporting a proprietary and weakly defined specification. it does not say "contact X for problems with the specification" or "the vst specification is strictly defined by ISO xxx-xx-xxxxx" or anything like that. if steinberg wanted, tomorrow they could replace the whole 'sdk' with one file named turnip.jpg and nobody could do anything about that.

if you have problems with the sdk, you know who to contact. if you have problems with a particular host other than those created by the authors of the specification, you know who to contact. if you have a problem which is specific to my software, you can contact me.

aq actually pointed out something very interesting. he said that his plugin does not implement event sorting, yet it does implement allnotesoff midi messages. hung-notes should never occur due to ignoring that message as the midi specification is explicit in stating that all note-on messages must be paired in-order with a note-off message and that allnotesoff is absolutely not an acceptable replacement for this. it specifically states that an allnotesoff message must be used in addition to a note-off message for every active note and that allnotesoff should be sent after all require note-off messages have been sent.

it may be that the host in question is not obeying the midi specification. it may have nothing to do with vst.

[Leslie Sanford]

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 ??

Interesting question. If the host does not provide the events to the plugin in order in which they arrived at the host via some MIDI input device, there will exist ambiguity when two or more events occur at the same time. For example, it's possible for a note triggered and released quickly enough to generate a note-on event followed by a note-off event with the same timestamp. The order of events cannot be determined strictly by the delta frames value.

Which would mean that if a plugin cannot assume the events are in order, in addition to sorting the events by their delta frames value, it will have to use additional logic to ensure it doesn't get any stuck notes by accidently processing a note-off event before a its corresponding note-on event, ditto for sustain pedal events. Pitch bend might be troublesome as well (not for stuck notes but for tuning reasons).

In the plugin I'm currently writing, I have logic in place to ensure that events are sorted by their delta frames value, but that's as far as I'm willing to go.

It would be nice if the delta frames value was relative to the previous event as it is with MIDI files. Then processing events would be similar to processing a MIDI file. There would be no ambiguity involved.

[aciddose]

it's funny what you've said leslie because you've made me realize whyterabbyt's question has in fact proved my assumptions. you're absolutely correct that if events were not required to be inserted in-order, two events with the same delta value might have ambiguous order.

the only way to remove the ambiguity is to assume that all input events come in-order. that way two events with the same delta value must occur in the order they are presented, even if during the same time slice.

so, the decision to use delta events in this way actually proves that events must be provided in-order from the host. you could weasel your way out of this requirement by only ensuring that events with the same delta value are sent in-order and that the sort used is stable, however that wouldnt be elegant and would seem from my point of view quite like a kludge.

[Mutant]

@Aciddose:

Please do not waste your precious time arguing on KVR.

@Whiners:

FFS Leave him alone ! If you really want to prove your superiority - write a better synth !

TIA

[disturb]

DANG

[aciddose]

it's true i shouldnt really bother arguing with them, but there is little else anybody can do to get rid of them. ignoring them, would that even have worked?

but it is amusing if you consider the time spent arguing with them, i could have implemented the fix for those buggy hosts.

[Kingston]

just popped in to say thanks a lot for letting us have a peek at the sources. Some of the math is a major task in obfuscation for someone like me who hasn't done integer based DSP. At least there's a few float algos thrown in as "clues". The convention and interfaces are clean and easy to read, although I can't imagine why you use a single space instead of a tab.

I seem to recall you use GCC based compilers. I would be curious if this was ran through the latest Intel compiler. Since you do clean C++ code I would expect a major performance boost for xhip synth. Something like 20-30% off compared to MS or GCC x86 compiler is quite usual. It's something to think about for some well tested xhip synth v1.0 when it gets set in stone.

Thanks.

[aciddose]

"I can't imagine why you use a single space instead of a tab."

tabs make code _way_ too wide. some of the source files actually have part tabs and part spaces and they need to be processed before i officially release them. you should be able to get an application for automatically applying tabs - doesnt vcexpress do that?

the main speed improvement will come when i implement smc (self modifying code) to switch unneeded operations out of the rendering function. conditionals take too much cpu and their execution isnt absolutely stable which is why i removed them. using a better optimizing compiler could definitely be a thing to consider - i'm not too interested though but anybody else can compile the code on any compiler they like.

[stefancrs]

"I can't imagine why you use a single space instead of a tab."

tabs make code _way_ too wide.

Hm, uhm, in what editor? I haven't ever used a code editor where you can't set the size of the tabs (I usually use a tab length of 2).

[aciddose]

yes, i use a tab length of 1 when using a tabbing editor. i just use space when writing the code by hand though. (by the way, this sort of thing is part of the reason i dont like the idea of releasing source if you dont like it, fix it with a tool. i use spaces.)

also, you might notice the source for the synth is absolutely tiny. it actually compiles when you strip out the patch editing functions and notelogic stuff down to less than 12kb. 'xhip' is really a gui, not a synthesizer.

[stefancrs]

I have no problems converting spaces to tabs, or vice versa I was just curious to knowing what editors didn't allow you to adjust the tab width.

And yeah, quite advanced synths can be very small if you don't need all that "GUI junk". The one we used back in the days in 64kb demos used about the same size, including song player.

[Chris Walton]

are you using any gcc-specific stuff? if not, I might take it for a spin in msvc.