XHip--Please finish your synth!!

[aciddose]

voices++;
while (--voices)
{
voice = getvoice(voices);
l = left, r = right;
set initial configuration for this block for this voice
samples++;
while (--samples)
{
l/r += make sample with voice
}
}

here, the data for a single voice is more likely to remain in the cache during rendering of that voice. i render the block per voice rather than render each voice per sample. that makes the most sense when there are no interactions between voices.

so, this way we save because:
- the voice is more likely to remain entirely in the cache.
- only need a single block of samples to be accessed rather than many blocks, so that block remains in the cache during the whole rendering block along with whatever voice is being used at the moment.

if you'd like to run a simple benchmark for yourself you should do that, you'll find that using a single block to process per voice becomes many times more optimum when the size of a voice increases and the size of a block decreases - which is the case in something like xhip running with a small block size - realtime.

in order to process this way without first clearing the buffer, we would need to use the _same_ process only an additional buffer. the additional buffer would need to be either cleared before rendering the voices, or filled once for each voice and then mixed in a seperate pass. no matter what you do, you still would have to clear some buffer for mixing, the only way you get around clearing a buffer is by using another cleared buffer.

i do not want to discuss this anymore. it is a fact that in my code it is many times faster to do things the way i do them. perhaps the code you write is arranged in a manner which makes it less optimum to operate this way - that would seem odd to me though since this arrangement is optimum in all but the most simple case such as processing an effect without any mixing passes.

xhip is not an effect. it is a polyphonic synthesizer.

also, you save because the host can call the process function with any buffer length it wants. the way xhip works it is entirely dynamic. no memory reallocation ever needs to occur at any point in the processing. it doesnt matter if the host gives a chunk length of 1, or a chunk length of 10,000, the code will execute perfectly with no changes.

[Urs]

Ah... ok... my first synth did that, too. Nowadays I render into an internal output buffer first. I've got a memory layout that is probably the most compact footprint possible for my stuff. My buffers and my synth data usually fit in a single cache line.

Btw. you never know what they come up with. What if some plugin format suddenly comes with interleaved audio. Or INTEGER buffers. Or just 64 bit. *shiver* - that's why I put a layer inbetween plugin format and my stuff. This way I can also compile several plugin formats into a single binary, as long as these formats use different entry points

However, ok. The buffer must be cleared. In Process() you have to have an internal buffer if you have built-in effects in a synth. In ProcessReplacing you can either get buffers that are already cleared, or clear them yourself. Latter is preferable because not all kinds of synths need cleared buffers. Those can omit the clear phase.

[aciddose]

xhip actually has several process functions coded and the vst wrapper just accesses specific functions in the synth.

xhip actually isnt a vst plugin, i use a vst wrapper to access the real xhip code which is written in a platform independent modular/oo manner. the original code actually was part of a tracker sequencer and used 16 bit interleaved buffers. the rendering logic is a bit different and less optimum there in the same conditions.

i only use vst because it happens to have the widest use. if i wanted i could stop supporting the vst version tomorrow and release the core xhip module to be loaded by a seperate xhip-core to vst wrapper plugin - but that wouldnt make much sense.

actually you should've heard me badmouth vst five years ago. (wait.. five? no.. this was in 01.. and i started the first work on an unnamed sequencer in 00..) i never imagined i would be using it due to how much it sucked, and sucks worse today. i was writing my code along side the authors of renoise, fruityloops, several of the current big vst groups (i was invited to join three of them, if only i could remember which ones) and so on.

well, it turns out vst was widely adopted, to my astonishment, so i changed gears and concentrated on the vst version of xhip. while we gained a good synthesizer, sometimes i wonder what my own format and sequencer would've been like. anyway it doesnt matter since that can still happen any time now.

[AdmiralQuality]

that makes the most sense when there are no interactions between voices.

How do you deal with simple things like LFO sync between the voices then? Do you have to buffer or recalc your LFO waveforms then?

My voice loops are within the sample/subsample loops, to keep everything in sync. I did consider what you're suggesting, but there would have had to been workarounds added, as described above, and I doubt the CPU hit would be worth it.

Really, all my voice params should cache. It's not like there's megs of them.

Another issue is with synths that are also effects. As the in buffer is usually the same as the out buffer, you overwrite your input unless you do it one sample at a time (or unless you make a copy of the input buffer).

[aciddose]

"that makes the most sense when there are no interactions between voices. "

"How do you deal with simple things like LFO sync between the voices then? "

that would be an interaction. there is no interaction between voices.

i wrote some other stuff but really i dont want to discuss this.

[gsoto]

I tried the .fr version yesterday.
Low pass mode sounds similar; high pass is similar too, probably better. But is it possible that the peak and band stop modes are acting weird? peak sounds too loud, and band stop, I don't know, acts a little strange...
I had some problems with the drop down boxes too. Sometimes the lists are empty and you have to open them again.
edit: Oh, and i think that the waveshaper is broken.

frere_jacques.mp3
lalala.adxi

[aciddose]

the boxes are blank? i've never seen that before

i made a mistake with the clipping i think, and i also messed up the waveshaper yes.. i have no audio on this pc right now (my headphones broke ) so it's hard to work on xhip. i'll probably put speakers in here so i can do some more work soon.

[funkadil]

haha yeah, the parabolic waveshaper is really loud!

[gigglyAPE]

I think you (aciddose) should use recursive algorithms for filter and oscillators like this way:

filter(int sound)
{
sound+=cutoff;
sound-=res;
// DO SOMETHING ELSE HERE
filter(sound);
}

[NAD]

I think this thread should be moved the Plugin Development Forum. My delicate psyche cannot handle looking at all these functions!

[kippertoffee]

Hello chaps.

Did a new gui for xhip ever get underway?

I only ask cos i'm getting ready to buid a diy midi knob box
http://www.ucapps.de/midibox64.html
and i was considering designing it work primarily with xhip. If anyone has come up with anyhting i'be interested in seeing it.

I guess only the most important functions would be on the box (max 64 knobs), then less important ones accessed via secondary cc banks.

Pete.

[aciddose]

xhip can respond to midi cc, and vst parameter changes. you'd be best to make the box generic because xhip can and will change quite a lot in terms of parameters.

if you want to see what is being done, look here http://xhip.cjb.net/xhip/faq/

i cant see how a grid of knobs would be useful though. if you imagine a grid of knobs on the screen, a physical implementation wouldnt be any more useful. you'll probably spend a majority of your time trying to figure which knob maps to which parameter.

why not try something like 12 knobs? having them in a single row, or maybe two columns if vertical might be best. for more than that you could just use multiple controllers linked in series.

[gigglyAPE]

help i want to see some gui suggestions for forthcoming releases?

[glokraw]

i've made some more filter changes which solve the "drop out and back in" at the highest frequencies for the band/high/notch modes. the distortion has been reduced and stability increased. it sounds better to me than the old version although it does sound slighty different.. i havent tested it extensively. i think i want to stick with this change the same as i've stuck with the res compensation change. tell me what you guys think if you have the time to compare the last versiion with this:
http://xhip.cjb.net/temp/public/adxhip.0.6.12.8.fr.dll

i fixed some problems i introduced in the last few versions and i'm going to have a go at throughly testing for bugs and squashing them before i make the next alpha release (0.6.13.0) which will be the last release before i make the major changes to handling of patches. hopefully that shouldnt take too much effort.

If you can replicate the patch loading/saving like Abakos, or Zebra, that would allow easier use in linux, not requiring a host, and also if
you release a standalone version...would a
'pre-release bounty' speed things along? Or make the boss happy? ':)'

[aciddose]

'pre-release bounty': no, not really.

i wont be doing any linux stuff until i've got the next section of the todo cleared away. i wont be doing any of the next section of the todo until i go out and buy some headphones. i wont buy any headphones until i get off my ass.. so this is really unpredictable. your best hope is that i fall out of my chair/couch, but if i land in a comfortable position i may simply remain there.