KVR Audio

fritzman · Post by **fritzman** » Fri Jan 20, 2006 12:51 am

aciddose wrote:fritz; make sure you have replaced the dll correctly, it is impossible for changing allocation to cause a crash with the current code.

http://xhip.cjb.net/temp/adxhip_fix_2.dll

fixed ringmod, noise, and implemented constant-time linear glide.

You named them that way so they do work side by side. I didn't change their names.
BTW, I'm sure you know the difference between "theoretically impossible" and "it happens"? Sorry, but I only described what I did before it crashed here.

All the best, FRitz

aciddose · Post by **aciddose** » Fri Jan 20, 2006 12:57 am

if you load pcm and switch the waveform to another pcm while playing notes with that pcm, it can cause a crash because the position might be "105332" for one sample, while another sample is only "53324" samples long, obviously this means the position pointer will try to read data from the 2nd sample from a long way past the end of the valid data, and cause an access violation.

i will fix this in the future so that adjusting the waveform always resets pcm position info.

i have not been able to find any other problems which occur when switching the waveform parameters for either oscs or lfos.

fritz; of course it is only impossible 'in theory' in general, but being a coder i dont not think in terms of theory or probability, i think in terms of boolean facts, 1 and 0, yes and no. it is possible that i am wrong, and so my statement "it is impossible ..." may in theory be incorrect, but based upon my knowlage and if i am not mistaken, with the current code it is indeed impossible during normal operation and controlled conditions (which is what the whole idea of a computer is) it is impossible for reallocation to cause a crash.

previously reallocation was triggered from the gui. vst is supposed to be single threaded, where all operations occur linearly and operations can not overlap. it seems many hosts use a single thread for audio and parameters, however they use a seperate gui thread. this is incorrect, since if a parameter is changed on the gui, it can occur at the same time data is being accessed by the audio thread, possibly resulting in a problem.

to work around this, i've removed the direct reallocation and set up a "waiting for reallocation" flag. this flag is checked every time a process function is called (such as parameter access, midi data, or audio process.)

this means it is impossible for a crash to occur because data will always remain valid and under the complete control of the audio process and no other process, ensuring linear behaviour.

so.. i'm having real trouble figuring out how it can be possible to have a crash during reallocation, and it is extremely confusing since no matter what i do i have been unable to cause any crash even completely abusing the controls..

could you remove all copies of xhip and use only the latest _3 copy? if the bug indeed still occurs i'll have to send a debugging version because if i can not reproduce the bug myself it becomes extremely difficult to figure out what the problem could be.

aciddose · Post by **aciddose** » Fri Jan 20, 2006 1:18 am

http://xhip.cjb.net/temp/junoishbass.mp3

this sounds so much like my alpha juno, its sickening :P

all that sound quality is _JUST THE LINEAR GLIDE_ ???

yes, like i've been saying as long as i can remember :P

a lot less magic involved than most people think.

the rubbery sound of that synth mostly comes from the linear glide, but the waveforms used also have a good influence on the sound. this isnt very special though since most of the same spectra can be composed using 2 or 3 oscillators with standard waveforms. i rarely hear the ramp/pulse ramp/and etc waveforms used from a juno anyway :)

LiteOn · Post by **LiteOn** » Fri Jan 20, 2006 1:57 am

Hi Acidose,

just updated my Xhip demos. Well, I have to say - and that's a great pleasure - this thing ROCKS!!!! The most analogueish VA I've ever heard (saw.mp3, junoishbass.mp3).

... and for all the people looking for a "is there a VSTi like Virus": here it is (aciddose_-_xhiptrance.mp3, XHIP_supersaw.mp3, _starcraft__-_trance_unison_pad.mp3)!

How about your schedule: when did you plan to release 1.0?

Wahnsinn....

cheers,
LiteOn

aciddose · Post by **aciddose** » Fri Jan 20, 2006 2:22 am

lite; my plans are to release 1.0 once the synthesizer is in a state where i dont want to improve anything else. so, currently on my mind i want to add a few more options like fm, lfo->env retriggering, etc. once that is done, i also need to get the patch data saved in hosts correctly, and improve my patch and bank formats to include extra data like notelogic mode and etc, and add a ini file use by the synth to have default options like changing gui parameters, colors, etc.

at that point, all the 'main' functionality will be finished so i can make a 1.0 release and take it out of beta. improvements after that point will be labeled "xhip r1" "r2" "r3" etc. improvements would be things such as better parameter naming and displaying "51 ms" for the lfo delay instead of "21%" and others.

the current version is stable, beta does not mean unstable.

alpha -> design
beta -> implementation
release -> finished product
updated releases -> minor asthetic and utility improvements

the short answer is that i do most of my coding in winter and early spring since i have not much else to do and nowhere to go in this cold and wet weather. i hope by summer of this year i should have the first release version.

http://xhip.cjb.net/temp/xhipperz_.mp3

btw, dont you guys have webspace? i should set up a public ftp for uploading mp3s and so on.

aciddose · Post by **aciddose** » Fri Jan 20, 2006 2:44 am

actually; http://xhip.cjb.net/xhip/todo.cgi

Kingston · Post by **Kingston** » Fri Jan 20, 2006 3:21 am

aciddose wrote:http://xhip.cjb.net/temp/junoishbass.mp3

this sounds so much like my alpha juno, its sickening

SEXY! me like.

glad to see xhip coming along. like I said it before, it will be featured heavily on my future endeavours.

I'm know it'll work like a charm alongside ABL pro for example. Guess there's lots of rubbery blippe-ti-blop sounds to do now that there's the tools for it. (modern porn funk anyone?)

_starcraft_ · Post by **_starcraft_** » Fri Jan 20, 2006 8:08 am

rock stable here.
i still find the unison flangeing when adjusting voices a little bizzarre...and even more bizzarre that by going and moving the randomization slider right and left while playing i can halt the flangeing immediately and have the sound ready as it should be. like it activates a switch ..or it finally undertstands that it has to stop affecting the sound.

anyway in your juno sound example ..the very last note....that low punchy bass just struck like that isn't it lovely?

pure analog delight.

LiteOn · Post by **LiteOn** » Fri Jan 20, 2006 8:19 am

Hi aciddose,

thanks for feedback. Summer sounds good - just like Xhip!

cheers,
LiteOn

fritzman · Post by **fritzman** » Fri Jan 20, 2006 8:22 am

aciddose wrote:http://xhip.cjb.net/temp/junoishbass.mp3

THIS stuff is why I love this synth! It simply sounds right! Yeah ...

aciddose · Post by **aciddose** » Fri Jan 20, 2006 8:45 am

hah, i find that a bit funny. i've always thought of sounds like in my 'junobass' example are plasticy, weak sounds.. it sounds so.. hm, hard to explain subjectively. it is digitally influenced though, typical digital things like digital keyboard (perfect frequency control and gating, constant time linear glide, etc) and perfect filter and oscillators without distortion.

i've always thought of 'analog' as the real stuff, like a ms-10 or old model ms-20 with the korg35 filter in it, or something like that.

it seems when most people think 'analog' they are thinking of sh-101, <insert ota based roland gear here>, and 90s digital gear etc.

believe it or not, the sh-101 is probably one of the least 'analog' sounding subtractive synthesizers ever :)

for the very in-sync, finely tuned stuff personally when i'm thinking of those types of sound, like used in professionally produced music from the 80s and early 90s, i think DIGITAL, not analog.

oh well, i've given up on such things though, it always seems if i just keep working toward my own goal everyone else gets what they want too. i just discribe things in the completely oposite way most of the time i guess.

ultimate digital sounding saw: http://xhip.cjb.net/temp/vibris.mp3

aciddose · Post by **aciddose** » Fri Jan 20, 2006 8:56 am

_starcraft_, let me reiterate how the phasing thing works.

assume we have two, 0.1 for one, and 0.2 for the other

0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.0
0.0, 0.2, 0.4, 0.6, 0.8, 0.0, 0.2, 0.4, 0.6, 0.8, 0.0

as you can see, the '0.0' will line up, they are in sync. the size of the numbers used to represent the fraction of detuning between the two will roughly represent how long it takes between those zero phases meeting up.

(infact i have a feeling if you multiply the left and right numbers togeather you will have the number of cycles of the higher tuned oscillator that occur between phase syncs)

here the ratio is: 1/2
and you can see they meet up fairly fast.

but, have you considered with a ratio like: 1/634

they will still meet perfectly at that 0.0 phase position, it is only that the time between meetings is much longer.

1.0, 1.001577287066246056782334384858

now, if you can imagine rather than two, maybe sixteen, you should see that eventually, no matter what the tuning of each is, they WILL eventually meet at zero phase.

being a pattern recognition device, your brain can easilly detect this zero phase meeting point and then detect the pattern of phases that occur on each repetition.

now, this is easy for it because of the fact the meeting point is the same phase for every oscillator, being 0.

what if we randomize the phases of each so at that meeting point the phases are all different? suddenly it becomes extremely difficult and most likely impossible for the brain to recognise a pattern from this.

you should understand that adjusting the tuning randomly for each oscillator and then resetting to a predictable detuning function is equivelant to randomizing the phase of every oscillator.

so, this should explain to you why this effect occurs, it is entirely natural and only seems odd because you do not understand it.

the simple solution of course is to randomize phases on new notes, as will be implemented in the future, until then, just take the time to do it manually!

_starcraft_ · Post by **_starcraft_** » Fri Jan 20, 2006 9:04 am

yeah it's "perfect" analog.....u must know that so far we've been used to vstis which do not sound right....and to retain such elestic response on that low register thumping bass ....well with most other vstis u get something more resemblant of a fart.
anyway i wasn't very impressed with the filter sweeps....but u should make your sound examples at 96khz when doing such things. when doing blips with xhip i strictly operate at 96khz or it dont sound right to me. i can hear the filter lag(or whatever it is) too well...

fritzman · Post by **fritzman** » Fri Jan 20, 2006 9:11 am

aciddose wrote: the simple solution of course is to randomize phases on new notes, as will be implemented in the future, until then, just take the time to do it manually!

These are the sentences we wanna hear!

About the digi vs. Analog thingy: I couldn't care less if I like the outcome. And your vibris thingy sounds ok to me.

Crashing: I took ALL other (ad)xhip.dlls out of my VSTplugins folder and used adxhip_fix_3.dll instead. I open N2, load Xhip, turn up unison, detune and random detune, FEED IT WITH SOME NOTES, adjust the number of voices WHILE THE SEQUENCER IS RUNNING and: Poof. Less than a minute to "successfully" reproduce it here.

Best wishes, FRitz

aciddose · Post by **aciddose** » Fri Jan 20, 2006 9:22 am

fritz, this must have something to do with different methods of access in n2. i'll have to take a more in-depth look later. solution for now: dont do that while its running :)

xhip is amazing ! Thanks Acidose