XHip--Please finish your synth!!
- KVRAF
- 12615 posts since 7 Dec, 2004
http://xhip.cjb.net/xhip/releases/v0/b6 ... 6.12.6.dll
just been playing with the graphics/gui code for a while. i've got a dropbox-listbox for osc.a waveform with a textbox containing the current waveform embedded in there.
i've changed the drawing around so that controls update themselves rather than depending upon a naive dirty-rectangle system. i hope i can move back to the naive dirty-rectangle method later on (i changed it in trying to fix a bug, i think i can change it back but too lazy right now) since you get some flickering at times with the way it is configured now. the gdi blit function is also called way more than needed which probably is slower than just using the naive update-expanded-dirty-rectangle method.
a quick explanation of the dirty rectangle thing: when adding rectangles you can only really end up with a rectangle which represents the smallest rectangle capable of containing all the component rectangles. that means if you update something in the top-left of the window, and the bottom-right, then you'll have to redraw the whole window even if those two updated parts were only a single pixel in size. that seems very inefficient, but it is very difficult to design a system for maximum efficiency where the method of dealing with update/dirty rectangles is selected dynamically based upon what type of rectangles they are. instead, it's more practical to do it the naive way.
i'll have to get to changing the synth internals now so that i can knock more items off the todo list.
just been playing with the graphics/gui code for a while. i've got a dropbox-listbox for osc.a waveform with a textbox containing the current waveform embedded in there.
i've changed the drawing around so that controls update themselves rather than depending upon a naive dirty-rectangle system. i hope i can move back to the naive dirty-rectangle method later on (i changed it in trying to fix a bug, i think i can change it back but too lazy right now) since you get some flickering at times with the way it is configured now. the gdi blit function is also called way more than needed which probably is slower than just using the naive update-expanded-dirty-rectangle method.
a quick explanation of the dirty rectangle thing: when adding rectangles you can only really end up with a rectangle which represents the smallest rectangle capable of containing all the component rectangles. that means if you update something in the top-left of the window, and the bottom-right, then you'll have to redraw the whole window even if those two updated parts were only a single pixel in size. that seems very inefficient, but it is very difficult to design a system for maximum efficiency where the method of dealing with update/dirty rectangles is selected dynamically based upon what type of rectangles they are. instead, it's more practical to do it the naive way.
i'll have to get to changing the synth internals now so that i can knock more items off the todo list.
-
- KVRian
- 673 posts since 15 Nov, 2004 from Montevideo, Uruguay
Nice!aciddose wrote:http://xhip.cjb.net/temp/public/amen_flori_r.mp3
Xhip reverb can sound great indeed. I think it's probably the best sounding reverb of the ones I've tried. A shame that I can't seem to grasp the parameters completely.
That 3D tree looks pretty bad, I have to say.
Are you storing only one normal per vertex? The models seem to lack hard edges, but I guess the problem is in the models.
cheul, any chance to get a cleaner performance?
Try with a ramp waveform, or pulse around 30-60%, moderate attack, lowpass, moderate resonance, envelope modulating the filter. My intuition tells me that if you play with the frequency input modulation you could get close, maybe adding some waveshaping too. I can't give it a try at the moment, maybe later.
-
- KVRian
- 533 posts since 16 Jan, 2006 from France
Great idea :whistling: !aciddose wrote:I'll have to get to changing the synth internals now so that i can knock more items off the todo list.
- KVRAF
- 12615 posts since 7 Dec, 2004
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. some of the models in 3dobjects.zip have sharp edges, and as a result the geometry decimator does not work correctly, it shreds the edges. in order to get mipmapped geometry with sharp edges you need to be generating the geometry from surfaces with known curves and boundaries with a method like nurbs. the edge vertices are placed into a separate group which can only be decimated if the edge is maintained.
it is possible to "detect" edges, but if you want to read all the brain-melting boring papers on that stuff you know where to look
it isnt practical to have such a decimator for the purposes i'm using this one.
the trees look pretty good for mesh built trees. if the leaves were replaced by semi-transparent textures in the shape of actual leaves it would make them look a lot better. the thing with a software engine and software renderer is you need to minimize the number of polygons and vertices for speed reasons.
...and good looking trees would use a different technique for branching. anyway the current method works great for simple bushes and things. wait until i set up a scene with 100s of plants and pathways and so on.
it is possible to "detect" edges, but if you want to read all the brain-melting boring papers on that stuff you know where to look
the trees look pretty good for mesh built trees. if the leaves were replaced by semi-transparent textures in the shape of actual leaves it would make them look a lot better. the thing with a software engine and software renderer is you need to minimize the number of polygons and vertices for speed reasons.
...and good looking trees would use a different technique for branching. anyway the current method works great for simple bushes and things. wait until i set up a scene with 100s of plants and pathways and so on.
-
- KVRist
- 499 posts since 9 Oct, 2005
Thanks a lot for your time gsoto. Yes, it was a quick, dirty draft using my guitar as a guitar synth. That's why I need to properly input it with my MIDI keyboard.gsoto wrote: cheul, any chance to get a cleaner performance?
Try with a ramp waveform, or pulse around 30-60%, moderate attack, lowpass, moderate resonance, envelope modulating the filter. My intuition tells me that if you play with the frequency input modulation you could get close, maybe adding some waveshaping too. I can't give it a try at the moment, maybe later.
I'll try to translate your tips into actual tweaking and see what I can come up with. I'm really excited to start using xhip in my projects (which are no synth based projects at all originally lol).
- KVRAF
- 12615 posts since 7 Dec, 2004
-
- KVRAF
- 3499 posts since 9 Oct, 2004 from Poland
aciddose wrote:bbtr: http://xhip.cjb.net/xhip/faq.cgi
Code: Select all
404
the path you requested does not exist.
if a link from a page on xhip.cjb.net/* is broken, try using the emailer to inform me.
other than that, stuff comes and goes here all the time
[====[\\\\\\\\]>------,
Ay caramba !
Ay caramba !
- KVRAF
- 12615 posts since 7 Dec, 2004
i just modified the entire site code. whatever.cgi is no longer used.
http://xhip.cjb.net/xhip/faq
the use of .cgi - THAT was lame
although, "lame" refers to an inability, like a disability for example.
1. crippled or physically disabled, esp. in the foot or leg so as to limp or walk with difficulty.
now if you want to talk about who is really lame, not bothering to browse from the site root
http://xhip.cjb.net/xhip/faq
the use of .cgi - THAT was lame
although, "lame" refers to an inability, like a disability for example.
1. crippled or physically disabled, esp. in the foot or leg so as to limp or walk with difficulty.
now if you want to talk about who is really lame, not bothering to browse from the site root
-
- KVRist
- 189 posts since 1 Jun, 2006
Stop moaning.bbtr wrote:pretty lame, really...
