XHip--Please finish your synth!!

[cheul]

yeah Smileys ain't doing the job they're supposed to anymore

[gsoto]

gsoto: one normal is _always_ stored per vertex, never more. in order to get sharp edges, the polygons making up the edge use separate vertices.

But that's redundancy!, I thought you care about efficiency.
Actually I don't know how all these 3d formats handle hard edges. I remember the "smooth groups" thing from 3D Studio though.

I know the tree looks good "for a mesh built tree", it just doesn't look good in any other way.

[aciddose]

well, yes it does look pretty shitty if you mean on an absolute scale

http://xhip.cjb.net/temp/public/3de0_better.exe

i've added some more interface and slightly improved the tree code.
q = save screenshot
x = switch 4x oversampling
mousewheel scroll, click = set fov, reset to 180º

anyway pretty cool for something i've been fooling around with for a few years - started out as a vector engine in basic

the useful thing about writing code for the 3d engine is that it provides me with a different perspective on some things. a lot of the improved code that xhip has received over time has been due to work in the 3d engine. and of course, i might actually USE it for something... one day

[aciddose]

http://xhip.cjb.net/xhip/releases/v0/b6 ... 6.12.7.dll

- fixed redraw in the gui partially so that things work correctly (or seem to) until i get to the gui development to-do section
- the waveform.a dropbox seems to work fine now. if it does, i can replace a few of the selection parameters with the same style dropbox controls on the default gui
- as well as fixing the redraw, i've slightly improved the dirty-rectangle handling so that less of the gui should be redrawn. when drawing rectangles which overlap, only a single rescaled rectangle is drawn. individual rectangles are drawn discretely, which is hope is the optimum solution to the problem.
- last release i fuddle-duddled the version number and so i've changed the code around to prevent this happening again. this shouldnt really influence any users.

[inzeenir]

Dropbox works! Can we have a nice big rotary for the cutoff please

[aciddose]

"Dropbox works! Can we have a nice big rotary for the cutoff please"

No.

[gsoto]

http://xhip.cjb.net/temp/public/3de0_better.exe

Much better, now I can tell it's a tree.

the waveform.a dropbox seems to work fine now. if it does, i can replace a few of the selection parameters with the same style dropbox controls on the default gui

Make the drop box as wide as the button and it will be faster to select a value.
I noticed that when the box is opened and you move the slider below it, the slider comes to front.
For me the best behavior would be that if you click outside the box, it closes on button down, and the click doesn't have any other effect, even if the pointer is over another control.

Yay! bugs and questions!:
- Panning section making weird nonsense (since a couple of versions).
- Is the raise in volume when you push the highpass filter to the top a normal behavior?
- Just to be sure, from 6.11.1 to 6.11.2 the hard sync sounds different. I guess it was a fix.
- With ramp unison, if you choose two ramps, there's no detuning at all.
- Modulators' key tracking doesn't seem to take into account the transpose parameter.

[SQ4]

Small contradiction in XHIP : "EffFlagsCanReplacing=False" BUT ProcessReplacing works...

[aciddose]

weird, it posted twice for some reason.

[aciddose]

but the process replacing function is just:

memcpy(buffer, 0)
process(buffer)

so, whatever the host does (probably the same thing) is equal or better than the actual function. there is absolutely no way to make it any more efficient and the inclusion of "process replacing" in the vst spec was a completely stupid idea - it's pretty much pointless in anything other than some simple gain example. anyway i'll change it to true if you like (for whatever reason).

"I noticed that when the box is opened and you move the slider below it, the slider comes to front."

actually it doesnt, it just draws in the incorrect order since the slider locks the system. the way in which this works is extremely complex and i'll work it out eventually. in order for the dropbox-element to lock the mouse while it is active i would need to cover the entire window with a transparent element to grab events. it isnt practical at all to do this. the system wont be working 100% correctly until i get to that point on the to-do list and for the current time i really dont care about this since it doesnt hurt anything - it just waits until after you release the mouse to redraw.

"Make the drop box as wide as the button and it will be faster to select a value."

i had been playing with different configurations and i've already changed that since i posted last. i also changed the code in the default gui to be automatic for these new controls rather than discrete, so it now automatically replaces all selection controls with drop boxes.

- Panning section making weird nonsense (since a couple of versions).

i'm not surprised, i changed one of the primary functions and the panning is one of the things i pay least attention to. it'll be a simple fix, i probably missed a "2*" or something.

actually, the problem was with my clipping macro. when you include calculations inside a macro they're evaluated multiple times if the variable is used multiple times. the code generated by the macro _should_ have worked, however i suspect there was some problem with operator precedence causing the problem. it seems to work fine now.

- Is the raise in volume when you push the highpass filter to the top a normal behavior?

i do not notice any increase in volume beyond 0db, or what the signal would be if the filter was not applied. you'll need to be more specific. the filter should behave close to ideal at any rate over 48k (so, 96k should be almost perfect) and at lower rates you'll get stronger phasing effects in the high end of the frequency range. at 48k, the voume normally drops off as you get to 1/6 sampling frequency, and when you get to 1/2 sampling frequency it peaks to 0db. if that is what you're talking about yes that is normal. to get rid of the effect run xhip at a higher rate.

the effect is due to the compensation of the filter. the same effect takes place on every filter mode, it is just less audible. without compensation it would only be possible to run the filter at that 1/6th frequency and you should notice that most other software synths have that limitation. while actually using the filter in music i've never noticed the effect. similar effects take place in analog highpass filters as well and i cant really tell any difference, so i'm not motivated to "fix" a non-existent problem.

- Just to be sure, from 6.11.1 to 6.11.2 the hard sync sounds different. I guess it was a fix.

yes, at that point i worked on the oscillator code and corrected the sync. the sync now works correctly in all situations (A->B isnt different than B->A with the same waveforms/etc) and sounds a lot better in my opinion.

- With ramp unison, if you choose two ramps, there's no detuning at all.

changed
if (avg)
to
if (avg && saws > 1)

obviously the average of 1 is equal to that 1. so, the detune was being canceled out by the "centering" code. another interesting thing to note is the fact with an odd number you should be getting n-1 detuned and two oscillators tuned at the center frequency. i'll have to think about how to handle this in a uniform manner.

- Modulators' key tracking doesn't seem to take into account the transpose parameter.

the bender input is used for the transpose and detune control parameters. so, the envelope and lfo now pay attention to transpose, detune, and bender values for keytracking.

i also changed the default color back to 0x00808080

you can see how the problem with focus works if you try opening two drop boxes at once in the same parent (the same group) and then across different groups. two boxes in the same group will function correctly (the focus is transfered immediately) however in different groups you have to wait until the mouse is released for the old one to close.

i wonder how we went from 69kb to 73kb in 12.5 to 12.6.. weird... ah it may be due to the addition of those extra controls. i think i've got some unused stuff compiling in atm.

http://xhip.cjb.net/xhip/releases/v0/b6 ... 6.12.8.dll

12.8 already

[aciddose]

by the way, i'm still working through some bugs, for example:

if you click on the first option in the drop box (item 0) nothing happens until after you've already selected some other option. that is because the control is initialized to 0 rather than -1, and i need to look things over and change this in a way which makes sense to fix the problem.

some text doesnt fit inside the area for the labels. the text also isnt clipped correctly into the label rectangle, it seems to bleed off the left side for some reason.

using the glide mode box on the control page causes an immediate crash. i've no idea why at this point. it for some reason isnt able to get the strings and values used to initialize the listbox. actually, i have a good idea of why this is, it's just as usual a matter of figuring out how to elegantly solve the problem.

i'm sure there are other issues!

[AdmiralQuality]

processReplacing() replaces the buffer contents. This is the usual function that is called in modern hosts.

process() accumulates (i.e. mixes with) the buffer contents. This seems to be a legacy function, I don't believe I know of a recent host that calls it.

So it's not strictly correct to process one with the other.

(i know, i know, you meant to do that. )

EDIT: Oh I see now you're intializing the buffer to zero. Well, by making processReplacing your main function you save both that step, as well as the addition in the process function (assuming you're accumulate in the process function as you're supposed to.)

[Lance]

The 0.6.12.8 version crashes in Orion. I did a quick test with 0.6.12.7, that works fine, as every version which I tried in the past.

[aciddose]

probably something wrong with initialization, oh well. stick with the one that works then.

"by making processReplacing your main function"

i think you need to think this through. in any case, no matter what, the function will require an extra pass in order to first clear the buffer before mixing onto it. in process(), you expect the host to have already done that for you. most hosts implement this by memset(buffer, 0). in processreplacing, the host expects you to manage it yourself. if i were to make process replacing my main function, the process (accumulate) function would need a seperate implementation. i think you've got this backwards.

if i were to make "processreplacing" the main function, it would require that i maintain my own mix buffer. this would be redundant and fill up the cache needlessly.

[AdmiralQuality]

probably something wrong with initialization, oh well. stick with the one that works then.

"by making processReplacing your main function"

i think you need to think this through. in any case, no matter what, the function will require an extra pass in order to first clear the buffer before mixing onto it. in process(), you expect the host to have already done that for you. most hosts implement this by memset(buffer, 0). in processreplacing, the host expects you to manage it yourself. if i were to make process replacing my main function, the process (accumulate) function would need a seperate implementation. i think you've got this backwards.

if i were to make "processreplacing" the main function, it would require that i maintain my own mix buffer. this would be redundant and fill up the cache needlessly.

processReplacing() just replaces the buffer contents with the signal your process produces. it's an =. process() adds the signal TO what's in the buffer.

By encasing processReplacing inside process, you're adding an unnecessary memset (because all those values would get written anyway, no need to initialize them) and an unnecessary addition for each sample. Sure, it's not a lot of time, but it's infinitely more than zero operations.

And again, process just isn't called anymore (AFAIK). You can safely do without it except in really old hosts.