there shouldnt be any huge amount of disagreement on anything since everything can be made optional. if you want horizontal sliders, we can do a horizontal sliders version. if you want knobs, we can do a knobs version. whatever the design grymm comes up with, it can be modified, divided and recreated in as many ways as we like in the future. for now, i'd like it if everyone can keep the short single-opinion statements to a minimum.
what we need now i think is a more general direction to go in. there are certain things which are not important like how the controls look (they can be changed) what colors are used (they can be changed) what fonts are used (they can be changed) and how many things do i need to list off so people get the idea? all these simple things can be changed. the important things which can not be changed quite so easilly are the large structural elements. you might say something like
"it would be cool in my opinion if the filter were to the right of the mixer, and the oscillators could be above, grouped togeather. the envelopes could be in bars on the (left,right,etc) with the modulators in a seperate section in the (ne,sw,etc)."
those are the kinds of comments which are really going to be helpful right now. there are certain things like "it would be cool if you could draw the lfo waveform into a little box so we can see how the parameters change it's shape in realtime" which are also helpful. there are many little ideas like that which people may often pass off which actually have the potential to have a great positive influence on the project.
what i'm asking then is, just try to find the dividing line between what is trivial and unnessicary, and what is small yet potentially very valuable. i hope gyrmm's project, like gsoto's and markdeaton (if he is still up for it, he told me he has been very busy) are successful and i'll try to work in collaboration with everyone in order to see these projects completed.
XHip--Please finish your synth!!
-
- KVRAF
- 12615 posts since 7 Dec, 2004
i've been doing some work on the animation systems.
http://xhip.cjb.net/temp/public/bender_animated.dll
here, i've managed to keep the cpu requirements for animation to a minimum so that it is even possible to animate 100s of these objects on the screen at once. there are three limits placed on the animation. one limit is a hard limit on the framerate which sets exactly how often the control is allowed to be updated. a resonable limit for this is quite fast at about 20ms or less. there is a second limit which only actually redraws the control when it has moved enough to require it. another is that the control is only redrawn into it's backbuffer (it's animation buffer) once between actually being drawn on the screen.
with all these limits in place it is easy to control exactly how much animation takes place and so therefore limit cpu use to a reasonable level. here, when animating the bender, i cann ot get more than 30% of my cpu active and the animation seems just a step down from completely smooth. if i increase the framerate, cpu use jumps to 100% during periods of intense activity, but only for very short pulses. i'd rather limit the animation a little and live with the very minor jerkyness of motion than deal with cpu spikes which may cause audio buffer problems.
these systems can work with any type of graphical element; i've just used the 3d renderer here for this particular demonstration.
the most interesting thing about using animated widgets is that i can define any behaviour i'd like for them. in this case you'll see there is a very simple (aka, not realistic) spring simulation which pulls the bender into the center position. the control's output is actually not connected in any way to the animation of the control; the behaviour you see with wobbly/springy movement is only for visual effect.
if it were desired to add this effect to whatever the control's output were sent to, that would be done in the audio process with much higher accuracy. the animation runs currently at only about 50 times per second, at maximum. these physics calculations are also not constant-time, they're linear newtonian aproximations. in an audio effect, the calculations would need to be taking place 48000 times per second or more and would have to be constant-time.
the plugin does not actually do anything other than display the widget. this is just for demonstration. if i wanted to implement a plugin to actually use the output of this control, it would be equal to any other type of control, there is nothing special about this widget other than it's athetics.
hopefully we'll be able to use these new systems in some way with the new gui's being developed.
http://xhip.cjb.net/temp/public/bender_animated.dll
here, i've managed to keep the cpu requirements for animation to a minimum so that it is even possible to animate 100s of these objects on the screen at once. there are three limits placed on the animation. one limit is a hard limit on the framerate which sets exactly how often the control is allowed to be updated. a resonable limit for this is quite fast at about 20ms or less. there is a second limit which only actually redraws the control when it has moved enough to require it. another is that the control is only redrawn into it's backbuffer (it's animation buffer) once between actually being drawn on the screen.
with all these limits in place it is easy to control exactly how much animation takes place and so therefore limit cpu use to a reasonable level. here, when animating the bender, i cann ot get more than 30% of my cpu active and the animation seems just a step down from completely smooth. if i increase the framerate, cpu use jumps to 100% during periods of intense activity, but only for very short pulses. i'd rather limit the animation a little and live with the very minor jerkyness of motion than deal with cpu spikes which may cause audio buffer problems.
these systems can work with any type of graphical element; i've just used the 3d renderer here for this particular demonstration.
the most interesting thing about using animated widgets is that i can define any behaviour i'd like for them. in this case you'll see there is a very simple (aka, not realistic) spring simulation which pulls the bender into the center position. the control's output is actually not connected in any way to the animation of the control; the behaviour you see with wobbly/springy movement is only for visual effect.
if it were desired to add this effect to whatever the control's output were sent to, that would be done in the audio process with much higher accuracy. the animation runs currently at only about 50 times per second, at maximum. these physics calculations are also not constant-time, they're linear newtonian aproximations. in an audio effect, the calculations would need to be taking place 48000 times per second or more and would have to be constant-time.
the plugin does not actually do anything other than display the widget. this is just for demonstration. if i wanted to implement a plugin to actually use the output of this control, it would be equal to any other type of control, there is nothing special about this widget other than it's athetics.
hopefully we'll be able to use these new systems in some way with the new gui's being developed.
-
- KVRAF
- 8519 posts since 7 Apr, 2003
i started some basic idea.
basic idea is clean design, good organization, colorful controls.
right now pots are done. going to work on faders, switches, and leds next.
working size is 750 x 500
basic idea is clean design, good organization, colorful controls.
right now pots are done. going to work on faders, switches, and leds next.
working size is 750 x 500
-
- KVRAF
- 8519 posts since 7 Apr, 2003
-
- KVRAF
- 12615 posts since 7 Dec, 2004
you do not need to do any colors or anything. what i need is the seperate components of the image. here i see you have the basic shape which you can do in greyscale. there is a specular highlight in the top-left as usual, which you can also do in greyscale so i can overlay it. a plain rectangular marker is overlayed on that combined shape.
so, can you try to produce just those three images? the rotation can be done by software. for color, that'll also be applied by software and specified in either rgb or hls, whatever you like. i generally do shading in hls since it looks better, like with the specular highlight.
have you done animation of the shadow or does it remain static? if it is static it can be a part of the basic image.
so, actually we'll need four parts:
i'm assuming you used something like photoshop or gimp with overlays.
1) the colored section. we might be able to just draw a plain colored circle here and overlay the edges on that. you can include any marks/etc in the edge and specular components.
2) the edges/border. the black parts without the colored part added in, and without the marker.
3) specular highlight. just the part which is added white.
4) the marker. maybe i can construct this from two aa-triangles instead of having to use a bitmap and rotate it.
so, the drawing process is:
1) fill the colored circle which will become the knob body.
2) overlay the border in black. the border image is actually 100% alpha channel to mask this black.
3) overlay the specular highlight. the highlight is actually 100% alpha channel to mask this white.
4) overlay or draw on the pointer, maybe also the shadow unless that was part of the border.
so, can you try to produce just those three images? the rotation can be done by software. for color, that'll also be applied by software and specified in either rgb or hls, whatever you like. i generally do shading in hls since it looks better, like with the specular highlight.
have you done animation of the shadow or does it remain static? if it is static it can be a part of the basic image.
so, actually we'll need four parts:
i'm assuming you used something like photoshop or gimp with overlays.
1) the colored section. we might be able to just draw a plain colored circle here and overlay the edges on that. you can include any marks/etc in the edge and specular components.
2) the edges/border. the black parts without the colored part added in, and without the marker.
3) specular highlight. just the part which is added white.
4) the marker. maybe i can construct this from two aa-triangles instead of having to use a bitmap and rotate it.
so, the drawing process is:
1) fill the colored circle which will become the knob body.
2) overlay the border in black. the border image is actually 100% alpha channel to mask this black.
3) overlay the specular highlight. the highlight is actually 100% alpha channel to mask this white.
4) overlay or draw on the pointer, maybe also the shadow unless that was part of the border.
-
- KVRAF
- 12615 posts since 7 Dec, 2004
example images, mspaint style. obviously the actual stuff will look much better, this is just to display visually the process of rendering the knobs.
1) fill the colored circle which will become the knob body.
2) overlay the border in black. the border image is actually 100% alpha channel to mask this black.
3) overlay the specular highlight. the highlight is actually 100% alpha channel to mask this white.
4) overlay or draw on the pointer, maybe also the shadow unless that was part of the border.
1) fill the colored circle which will become the knob body.
2) overlay the border in black. the border image is actually 100% alpha channel to mask this black.
3) overlay the specular highlight. the highlight is actually 100% alpha channel to mask this white.
4) overlay or draw on the pointer, maybe also the shadow unless that was part of the border.
-
- KVRAF
- 8519 posts since 7 Apr, 2003
nice, man. yes i of course work atomically and have everything separated. that is helpful to know that i dont have to rotate 
let me keep building things knowing this information. i need to think about the organization/layout. it's going to be all on one page hopefully if we can pull it off in that size
also 24bit transparent PNG's would be ok for these different pieces? or if not then what format?
let me keep building things knowing this information. i need to think about the organization/layout. it's going to be all on one page hopefully if we can pull it off in that size
also 24bit transparent PNG's would be ok for these different pieces? or if not then what format?
-
- KVRAF
- 12615 posts since 7 Dec, 2004
we'll use bmp for all bitmaps. we should'nt ever be using a single bitmap which isnt greyscale/alpha channel. if there are large images we can use jpg. i cant support png, too much effort for too little gain.
using alpha-channel only and applying color in the application will get us compression ratios many times higher than png is capable of. the lz compression applied to the executable will handle the bitmap images no problem, and if there is a problem i can do rle on them which will have extreme compression ratios (but isnt going to be nessicary, probably).
i mean, rle vs. alpha-bitmaps would be something like 50k vs. 2k, and i do not think we need to worry about rle to save 48k :)
when sending back and forth though, png is fine since it is lossless. we just wont be using png in the final product, and i do not have access to image editing software so i cant use the data in the alpha channel pngs anyway. it's best to save the alpha channel seperately and divide all elements into atomic form with alpha channel + static color
using alpha-channel only and applying color in the application will get us compression ratios many times higher than png is capable of. the lz compression applied to the executable will handle the bitmap images no problem, and if there is a problem i can do rle on them which will have extreme compression ratios (but isnt going to be nessicary, probably).
i mean, rle vs. alpha-bitmaps would be something like 50k vs. 2k, and i do not think we need to worry about rle to save 48k :)
when sending back and forth though, png is fine since it is lossless. we just wont be using png in the final product, and i do not have access to image editing software so i cant use the data in the alpha channel pngs anyway. it's best to save the alpha channel seperately and divide all elements into atomic form with alpha channel + static color
-
- KVRist
- 411 posts since 6 Jul, 2004 from Richmond, TX
GAAAAAAAAAAHHhhhh... I just went through nearly 50 pages from the old thread and couldn't find any of the pictures gsoto had posted, they must not exist anymore or something.
FREE MUSIC NO MONEY DOWN
http://joeyhoney.blogspot.com/
http://joeyhoney.blogspot.com/
-
- KVRAF
- 8519 posts since 7 Apr, 2003
ahh right i understand what you mean by alphas. that's well, "hip"aciddose wrote:we'll use bmp for all bitmaps. we should'nt ever be using a single bitmap which isnt greyscale/alpha channel. if there are large images we can use jpg. i cant support png, too much effort for too little gain.
using alpha-channel only and applying color in the application will get us compression ratios many times higher than png is capable of. the lz compression applied to the executable will handle the bitmap images no problem, and if there is a problem i can do rle on them which will have extreme compression ratios (but isnt going to be nessicary, probably).
i mean, rle vs. alpha-bitmaps would be something like 50k vs. 2k, and i do not think we need to worry about rle to save 48k
when sending back and forth though, png is fine since it is lossless. we just wont be using png in the final product, and i do not have access to image editing software so i cant use the data in the alpha channel pngs anyway. it's best to save the alpha channel seperately and divide all elements into atomic form with alpha channel + static color
more to come.
-
- KVRAF
- 6478 posts since 16 Dec, 2002
bengeorge wrote:GAAAAAAAAAAHHhhhh... I just went through nearly 50 pages from the old thread and couldn't find any of the pictures gsoto had posted, they must not exist anymore or something.
and 
and I did that too just minutes a go! I wish I would've saved tham while they were still there. They would've put a nice contrast to grymmjacks gadgets.
I must admit, I've been trying to think of ways to utilise that 3d engine in the gui, but this far have come up with nothing spectacular, other than non-ergonomic visual gimmicks.
Then again, a traditional synth gui done as even simplistic vector representation would absolutely rule. I'm talking about showing even the fonts and numbers as 3d elements. that kind of thing would obviously allow perfect seamless scaling, but maybe it would amount to too many polygons on screen for usable CPU usage?. Turning the page to access more options? A cube effect would work here very well. Each side of cube would represent the current tabs system, for example.
A knob would not be such a great control representation as 3D (not informative enough), so maybe sliders should be used through out.
just musing around really.
-
- KVRAF
- 12615 posts since 7 Dec, 2004
http://xhip.cjb.net/temp/public/images/
http://xhip.cjb.net/temp/public/images/ ... me_off.png
http://xhip.cjb.net/temp/public/images/proto1_menus.png
http://xhip.cjb.net/temp/public/images/ ... all_on.png
http://xhip.cjb.net/temp/public/images/ ... ctions.png
http://xhip.cjb.net/temp/public/images/proto1_2.png
http://xhip.cjb.net/temp/public/images/ ... me_off.png
http://xhip.cjb.net/temp/public/images/proto1_menus.png
http://xhip.cjb.net/temp/public/images/ ... all_on.png
http://xhip.cjb.net/temp/public/images/ ... ctions.png
http://xhip.cjb.net/temp/public/images/proto1_2.png
-
- KVRAF
- 7032 posts since 28 Apr, 2004 from france
I really like this sketch.
I'm glad Grymjack does a skin for Xhip, but this one from Gsoto was really quite unique, and it is a pity to let it not finished.
-
- KVRAF
- 8519 posts since 7 Apr, 2003
-
- KVRAF
- 12615 posts since 7 Dec, 2004
he is going to finish it, he is just busy currently. i need to implement a bunch more stuff first anyway. if i had everything i needed to implement finished, i'd have a working prototype version of his gui design already available.