xhip beta 5 out
- KVRAF
- 12615 posts since 7 Dec, 2004
xhip.cjb.net as usual
i was wondering if anybody could try this and tell me
1) if it crashes on them or anything
2) if the interface is better like this for now
3) if they banks work like they wanted
i hope it hasnt been to long, and i hope someone
gets some good use out of it since i fixed most of
your complaints :')
i was wondering if anybody could try this and tell me
1) if it crashes on them or anything
2) if the interface is better like this for now
3) if they banks work like they wanted
i hope it hasnt been to long, and i hope someone
gets some good use out of it since i fixed most of
your complaints :')
- KVRAF
- 1908 posts since 7 Jan, 2004 from Earth
-
- KVRian
- 1023 posts since 14 Jan, 2004 from germany
sounds very good - but the interface is almost unuseable
- KVRAF
- Topic Starter
- 12615 posts since 7 Dec, 2004
what makes it unusable?
telling me its bad doesnt help, because this is the best
interface for me, slide bars, value boxes (prints value, hold and move mouse to change), switches, check boxes, list boxes, are the best suited controls to mouse input. knobs are rediculous in my opinion.
the final interface will be composed of these components, just in different colors and different graphics, unless people start giving me better reasons to use other kinds of controls. having a knob and taking up 80% of the space with label text is insane, with slide bars, no space is wasted.
i am open to suggestions, but they have to be logical and verbose.
telling me its bad doesnt help, because this is the best
interface for me, slide bars, value boxes (prints value, hold and move mouse to change), switches, check boxes, list boxes, are the best suited controls to mouse input. knobs are rediculous in my opinion.
the final interface will be composed of these components, just in different colors and different graphics, unless people start giving me better reasons to use other kinds of controls. having a knob and taking up 80% of the space with label text is insane, with slide bars, no space is wasted.
i am open to suggestions, but they have to be logical and verbose.
-
- KVRian
- 1023 posts since 14 Jan, 2004 from germany
everything is hard to read - which comes from the colors and the font
the sliders should be grouped visually - oscilator sections, filters sections - and so on
also very helpful would be to see the state of a slider
(i dont wanna click on oscA to see if its Pulse or saw)
u should consider doing some graphics - our brain works very visual (remembers pictures much easier than numbers or words)
maybe some more experienced gui-designers can help u?
the sliders should be grouped visually - oscilator sections, filters sections - and so on
also very helpful would be to see the state of a slider
(i dont wanna click on oscA to see if its Pulse or saw)
u should consider doing some graphics - our brain works very visual (remembers pictures much easier than numbers or words)
maybe some more experienced gui-designers can help u?
- KVRAF
- 8705 posts since 9 Jan, 2004 from leroyaumeuni
you can't really find the right control instantly which is very annoying.. but apart from that I like the sound
although I get quite a few clicks and pops
although I get quite a few clicks and pops
My other host is Bruce Forsyth
- KVRAF
- Topic Starter
- 12615 posts since 7 Dec, 2004
the synth has absolutely zero clicks or pops, maybe you're cranking too much out of it for your cpu. i have a p3 450 katmai (basically, horrible) here and i can manage eight voices maxed out with 75-90% cpu use.
everything is hard to read, kind of, but everyone also complained from it being vertical. it is now not vertical. i can use a nurbs font but it will possibly take 150% time to draw, meaning 150% startup time. (redraw is static though.) everything is grouped visually, you noticed the labels and colors are all groups right?
what do you want, a giant colored rectangle instead? and single color gray sliders? that could be easy to do, if people want that.
it took me 30 minutes to get used to the interface while switching from vertical to horizontal, i assume it takes max 45 mins to learn for a newbie, assuming they know basic subtractive components.
experianced gui designers cant help me since xhip uses absolutely no static graphics, the entire thing is code generated, and part of it isnt even cached, it is redrawn as needed per-pixel.
suggestions like these (although as verbose, detailed as possible) is best, and what i need.
dont feel afraid to say things you think would be insanely cpu intensive to draw, since it probably isnt. like 3d rendering, etc. i have an antialiased shaded polygon function with z buffering which works perfectly for horizontal spans. basically 256x oversample at the speed of 2x oversample. sbuffering will make it absolutely perfect and twice as fast.
rasterization isnt dead, only your heads, slowpokes :O
everything is hard to read, kind of, but everyone also complained from it being vertical. it is now not vertical. i can use a nurbs font but it will possibly take 150% time to draw, meaning 150% startup time. (redraw is static though.) everything is grouped visually, you noticed the labels and colors are all groups right?
what do you want, a giant colored rectangle instead? and single color gray sliders? that could be easy to do, if people want that.
it took me 30 minutes to get used to the interface while switching from vertical to horizontal, i assume it takes max 45 mins to learn for a newbie, assuming they know basic subtractive components.
experianced gui designers cant help me since xhip uses absolutely no static graphics, the entire thing is code generated, and part of it isnt even cached, it is redrawn as needed per-pixel.
suggestions like these (although as verbose, detailed as possible) is best, and what i need.
dont feel afraid to say things you think would be insanely cpu intensive to draw, since it probably isnt. like 3d rendering, etc. i have an antialiased shaded polygon function with z buffering which works perfectly for horizontal spans. basically 256x oversample at the speed of 2x oversample. sbuffering will make it absolutely perfect and twice as fast.
rasterization isnt dead, only your heads, slowpokes :O
- KVRAF
- 3338 posts since 1 Sep, 2002
works very well in aodix 
and i love it
THANKS
Odo
and i love it
THANKS
Odo
Make Your Voice Heard!!
EUROPEAN VAPERS PROTEST 29th 2.00PM.It saved my life.
EUROPEAN VAPERS PROTEST 29th 2.00PM.It saved my life.
- KVRAF
- 8705 posts since 9 Jan, 2004 from leroyaumeuni
I think I got the pops when using modulation on panning.. but it might be my on-board audio and asio4all driver on my work machine in the office as well
I'll try at home
I'll try at home
My other host is Bruce Forsyth
- KVRAF
- Topic Starter
- 12615 posts since 7 Dec, 2004
it looks like i'll be working on the interface next instead of improving the synth more, but i suppose the interface is an improvement, from a certain perspective. (i spend most time writing notes, not editing patches...)
i'm glad you like it, i hope it wasnt too long for this release,
spaceman, if you can reproduce the clicks without an obvious source (lfo on pulse or width adjusted to ramp?, or random s&h?),
then definitely tell me how to, and i'll get that fixed. i thought i had it working perfect since when it did have clicks before.
i'm glad you like it, i hope it wasnt too long for this release,
spaceman, if you can reproduce the clicks without an obvious source (lfo on pulse or width adjusted to ramp?, or random s&h?),
then definitely tell me how to, and i'll get that fixed. i thought i had it working perfect since when it did have clicks before.
-
- KVRAF
- 1714 posts since 14 Mar, 2003 from Israel
@aciddose:
Since your synth has no graphics, why don't you replace the sliders with dragable text - like in scuzphut's echographz or in shotcircuit.
This takes less space than a slider while allowing clearer display.
Since your synth has no graphics, why don't you replace the sliders with dragable text - like in scuzphut's echographz or in shotcircuit.
This takes less space than a slider while allowing clearer display.
CubaseStudio4 µTonic/Rapture Nitro/GS-201/Ohmicide/TBK 1&3
-
- KVRian
- 1023 posts since 14 Jan, 2004 from germany
- KVRAF
- Topic Starter
- 12615 posts since 7 Dec, 2004
the size of the slider handle with respect to the slider box size sets the resolution of the control. say if the box is 100, and the slider is 50, that makes 50 pixels of resolution.
what i could do, though, is draw a colored bar behind the text which shows the position, and let you drag anywhere on the bar
in relative motion to change the setting, making one pixel equal to exactly one control nth input. (actual param resolution)
hm, because one other problem with a big slider handle isnt just the control's resolution, but the fact you can only represent that much resolution on the display.
the idea currently for the final interface is to use generated graphics. but that doesnt mean they need to be simple. infact, they can be as complex as required. drawing the text into the slider background (and allocating gdi bitmaps to contain, and blitting the bitmaps) takes the most time. actually drawing into the background bitmap is very fast, although very slow if you ignore the fact it uses gdi.
i've considered using windowed directdraw, what do people think of that? it can improve drawing time by about 8x faster or more, and also is quite well supported (winxp has dx8.1 included hard into the os)
if i start using directdraw, speed and graphics quality would surely be increased by a huge amount. i can redraw the background in directdraw faster than gdi can blit a cached bitmap of it.
edit:
or did you mean 'draggable text' as in value boxes?
a rectangle with the value printed inside, moving up and down
changes it, and using left/right buttons changes resolution of input?
i can do that very quickly, but i didnt think people would like that as much.
what i could do, though, is draw a colored bar behind the text which shows the position, and let you drag anywhere on the bar
in relative motion to change the setting, making one pixel equal to exactly one control nth input. (actual param resolution)
hm, because one other problem with a big slider handle isnt just the control's resolution, but the fact you can only represent that much resolution on the display.
the idea currently for the final interface is to use generated graphics. but that doesnt mean they need to be simple. infact, they can be as complex as required. drawing the text into the slider background (and allocating gdi bitmaps to contain, and blitting the bitmaps) takes the most time. actually drawing into the background bitmap is very fast, although very slow if you ignore the fact it uses gdi.
i've considered using windowed directdraw, what do people think of that? it can improve drawing time by about 8x faster or more, and also is quite well supported (winxp has dx8.1 included hard into the os)
if i start using directdraw, speed and graphics quality would surely be increased by a huge amount. i can redraw the background in directdraw faster than gdi can blit a cached bitmap of it.
edit:
or did you mean 'draggable text' as in value boxes?
a rectangle with the value printed inside, moving up and down
changes it, and using left/right buttons changes resolution of input?
i can do that very quickly, but i didnt think people would like that as much.

