XHip--Please finish your synth!!

[brok landers]

further question:
1.is xhip able to read loop information stored into a wav file (i.e. looped with wavelab)?
2.can i use single cycled waveforms?
3. will i be able to load basic multisample waves?
i.e. will xhip identify the rootnote/keyspan by name?
f.e. "bass01_c3_b#2-d#3.wav"?

[aciddose]

the version should be part of the filename. yours should be adxhip.0.6.11.7. that version will always exist from now on. all future versions will obey this naming convention so you shouldnt have to rename anything.

the only thing i've reverted is the extra 12db gain boost on the oscillators. the other additions will remain in future versions.

1.is xhip able to read loop information stored into a wav file (i.e. looped with wavelab)?

yes, xhip loads the first smpl chunk loop and assumes it is forward-infinite.

2.can i use single cycled waveforms?

yes, just loop the entire waveform.

3. will i be able to load basic multisample waves?
no, this will never be supported. xhip isnt a sampler. i might add functionality for this sort of thing later, but i doubt you'll ever be able to load multisample waves.

i.e. will xhip identify the rootnote/keyspan by name?
f.e. "bass01_c3_b#2-d#3.wav"?

no, but you can store that information in the smpl chunk of the file. xhip currently loads the information and then ignores it. if i add multisample/keyspan support, it'll use this information. you wont be able to load multisample waves automatically, but you will be able to load them individually and save them individually. when and if this is implemented, all the waves will be saved in a patch, so you can then load the patch to get the whole layout and samples back. there are methods for doing multisamples in riff using cue points, multiple wave chunks and other stuff, but that is just too complicated. xhip is not a sampler like i said.

[brok landers]

ok, what's a smpl chunk, and how do i store this info into the smpl chunk, say, saving from wavelab?
so you say i can (when implemented) load one multi wav file after another, named like i described, and after i loaded the necessary files, i just store the patch, and xhip loads these files automatically then? well, that'll do for me!

[brok landers]

aciddose, could it be that the keytracking of the env a (didn't test env b yet) doesn't work?

[aciddose]

yeah it doesnt seem to work after i changed a few things. i'll fix it dont worry

[brok landers]

[aciddose]

for everyone interested in the reverb, i've done some work on it.

http://xhip.cjb.net/temp/public/xhipeff ... verb.1.dll

some of the controls now allow full range from -100% to +100%. they may not behave as you expect. the number of delay elements per channel is now adjustable. there are two delay elements used for the pre/post delay/echo stage on top of that. you can select from zero to thirty-two elements to use per channel, which would be sixty-four in total. the cpu use has been reduced and performance is pretty good in the 4-8 element per channel range.

it needs more work, for example you might notice with large numbers of elements the total delay is a bit larger and you get some phase issues.

since you're accessing the parameters directly, you have to run a "model" parameter processing in your head. for example if you want a typical room verb, set the diffuse to 215 with the default settings at startup. dont forget to also increase the wet gain to 0db or whatever you want.

try changing the number of elements to three. you'll notice you now need to adjust the diffuse downward to about 195 and you'll also need to decrease the size parameter to about 110 to get the same effect.
it'll be less smooth with less delay elements, but take less cpu power. ifyou increase the number of elements you'll have to move the parameters in the oposite directions.

a parameter map or "model" will do this for you automatically based upon the diffuse and roomsize/roomtype parameters when i'm finished working with the more important parts of this effect.

[bengeorge]

YES!! the effects are awesome awesome awesome.

the reverb is one of my favorites, i use it on extreme settings for this rich organic sheen behind my tracks.

[bengeorge]

OH. by the way, aciddose, in the etc.7 beta, when I open it up, and play a note, about 0.5 sec after I stop playing the note I get a 100% CPU spike that holds for about 0.25 sec and then drops to normal.

details:
~energyXT v1
~no other vsts going
~default preset ("square").
~intel pIII 1.6Ghz cpu

[funkadil]

For those interested Id like to make known that aciddose made an effect version of the xhip filter with an envelope follower which is really neat.
http://www.kvraudio.com/forum/viewtopic.php?p=2302892
But yeah. Nice to see the reverb updated.

[cYrus]

i really like this synth. but i somehow miss this features (or couldn't find them):

1) pitch modulation of OSC A (or a nice mod matrix)
2) the pitch modulation of OSC B already starts to pitch too much with very low values. i would like to use almost unhearable pitch modulations to create a bit more analog feeling. so it would be helpfull if i could set there really low values..
3) if i change some tuning it's really hard to reset them to 0. something like CTRL+Click to reset it to 0 would be a nice addition.
4) something like SHIFT+Click to change into a kind of slow motion mode while manipulating the faders. so it would be more easy to make small adjustments while sounddesigning (would probably be the solution for 2))

[aciddose]

1) pitch modulation of OSC A (or a nice mod matrix)
oscillators page, oscillator envelope, modulator, etc.
this adjusts the root frequency. if you want to adjust only osc.a, use the inverse modulation for osc.b. i'm not going to do anything to "fix" this, its useless and you really dont need it. if you do, you'll have to wait for the modular version.

2) the pitch modulation of OSC B already starts to pitch too much with very low values. i would like to use almost unhearable pitch modulations to create a bit more analog feeling. so it would be helpfull if i could set there really low values..

this is going to be fixed when i switch from using byte values to store parameters to longs, which have 16 million times more accuracy. that'll do, right?

3) if i change some tuning it's really hard to reset them to 0. something like CTRL+Click to reset it to 0 would be a nice addition.

use right click. the next version i upload will work with ctrl left, or ctrl right.

4) something like SHIFT+Click to change into a kind of slow motion mode while manipulating the faders. so it would be more easy to make small adjustments while sounddesigning (would probably be the solution for 2))

it already has that.

ben:

this is caused by denormal scale values in the dc filter. for now you can disable the dc filter if you have a problem with it. i'm doing the processing in float with a second pass to the buffer. i'll think about zeroing denormals, but i might redesign the output stage to use an integer buffer instead which will increase accuracy. not sure. i should maybe be dithering at my int to float conversion to maintain higher accuracy too.

[aciddose]

brok sorry i didnt see your question about a smpl chunk

"ok, what's a smpl chunk, and how do i store this info into the smpl chunk, say, saving from wavelab?"

i have no idea how you do it in wavelab. a smpl chunk though is:

Code: Select all

struct smpl
{
 struct head
 {
  unsigned long label; 
  unsigned long size;
 } chunk;
 unsigned long manufacturer;
 unsigned long product;
 unsigned long period;
 unsigned long note;
 unsigned long fraction;
 unsigned long smpteformat;
 unsigned long smpteoffset;
 unsigned long loops;
 unsigned long data;
 struct loop
 {
  unsigned long id;
  unsigned long type;
  unsigned long start;
  unsigned long end;
  unsigned long fraction;
  unsigned long count;
 } list[]; 
};

loops is the number of loops in the loop list. i forget how the hell this works, it works pretty stupidly is all i remember. the only important thing is, xhip uses the first loop and ignores the others. for now it assumes the loop is always forward-infinite, but it loads the type and just ignores it so that in the future i'll be able to support bidi, reverse, etc.

i forget what the hell "data" is, i probably should've given it a better name in the struct.

so, the loop entry stores the start and end position + fraction of a sample off end position.

i had been trying to implement fractional loops which are pretty cool since when modulating the loop start and end the frequency of the looped section changes smoothly rather than in steps of one sample at a time. i never got it working to my satisfaction with interpolation though. i was thinking about it the other day and the only really practical way to get fractional looping with interpolation is to do two layers of interpolation, one to stretch the existing samples so that the fractional end looppoint fits on a real integer sample, and another to get the output sample based upon that set of first layer interpolated values.
it's kind of too complicated to put in xhip for now. atleast not until you actually can modulate loop points in realtime, assuming i actually ever will implement that.

actually though, the most important reason for fractional end loop points is it lets you get better tuning accuracy for loops. the fact the start point isnt fractional means you might not be able to loop at exactly the place you want, but atleast you can fit loops of waveforms at frequencies which dont line up perfectly on integer sample positions.

so, in your editor there may be an option to include extra data in the wave file like "sampler information" (smpl stands for sampler) which will offer you the option of including smpte information, the root frequency, and some list of loops. to get your own loops working in xhip, just add one loop to that list and save the file with that extra sampler info enabled.

i know that for example modplug tracker saves it's loops into wav files when you export them, so you have that as an option for saving looped files. older versions of modplug have a bug though where it saves the loop end point incorrectly. i'm not sure if the openmpt versions fix this or not, but i think xhip loads the points correctly which is the important thing.

"so you say i can (when implemented) load one multi wav file after another, named like i described, and after i loaded the necessary files, i just store the patch, and xhip loads these files automatically then? well, that'll do for me!"

well, no it wont load the files, it'll store every file inside the patch. i'm to be honest not sure what i'll do though, i might make it store the original path/filename instead. i dont think about these things, like i said xhip isnt a sampler. there are lots of samplers out there which will do all this stuff :P this business will be added after a 1.0.0.0 release, so dont hold your breath. for now i just want to get the existing feature set working so i can make that 1.0.0.0 release.

[aciddose]

"so you say i can (when implemented) load one multi wav file after another, named like i described, and after i loaded the necessary files, i just store the patch, and xhip loads these files automatically then? well, that'll do for me!"

more on this..

the filename doesnt do anything and never will do anything. naming your files like that isnt terribly useful anyway.

what xhip will be able to do is, if it has key mapping for samples, another riff chunk which i currently cant remember the name of allows you to store this information in the wav files. it has a base frequency stored in the smpl chunk. the other chunk duplicates this base frequency, and adds low and high midi note numbers for the keymapping span. that chunk also has a bunch of other information i cant remember which may or may not be useful to xhip. i'm not sure if whatever wav editors you use allow you to use these chunks, but if xhip implements this stuff, xhip will use the riff chunks for loading and saving.

if you really desperately have need for translating stuff from the filenames into the keymapping information in those riff chunks or the other way around i can always code a little console app to do that for you, after xhip already implements this and you find you have a need for it.

[Okke]

You need Live 6, MidiYoke, MidiOx (and preferably a BCR2000 controller) to use this:

http://okkevandenbroek.googlepages.com/bcr2000Xhip.jpg

It is a Xhip GUI with 'everything' on 1 page
You then can have a quatro-directional control, meaning:

change any of the parameters on the Xhip controller/ Live params/ BCR2000 hardware/ Xhip GUI
and the rest will automatically be adjusted.

I'm testing it right now and works well. I'll try to make it downloadable with some info if there is any interest in this.