KVR Audio

audiojunkie · Post by **audiojunkie** » Sat Sep 13, 2008 5:53 am

OK, I think I've found something to better help explain what I'm trying to see this synth being. Check out Imageline's Poizone:

http://www.flstudio.com/documents/poizone.html

This vst should show you a little bit how I'd like to see the combination of knobs and sliders. It is a very clear and easy to see and you GUI that gives a good representation of what is going on and the layout is logical.

This one is a better example than synth1.

Thanks!!!!!!!!!!!!!

--Sean

aciddose · Post by **aciddose** » Sat Sep 13, 2008 5:53 am

i've been ranting about how powerful the gui code is for months and nobody really noticed, so hopefully this will make a difference. did i mention anything can be textured and the whole system is object oriented with backgrounds, overlays and different forms of blit. (alpha channel, transparency, binary ops, masking, arithmetic, etc)

i forgot to mention about the knobs you said you like, those are just basically circles with a little "metal specular" bitmap in the center and a little dot that moves. that's easy as heck and i'll write the code to generate the stupid specular bitmap later on. for now i'm bored.

also, adding bitmap alpha effects to texture everything uses quite a bit of cpu power, obviously.

i already know what you're talking about with your sliders and knobs and other nonsense, don't worry. those designs are just extremely inefficient and it would be impossible to fit all of xhip's controls using that style. you must choose then between pages (switching mod.a, mod.b, env.a, env.b) or knobs it's really that simple. try drawing it out in ms-paint and you'll quickly realize "IT DONE GONE AINT GONNA FIT

".

that's just the way it is. i refuse to make the gui bigger than about 900x650 and i'm really stubborn.

audiojunkie · Post by **audiojunkie** » Sat Sep 13, 2008 5:58 am

aciddose wrote:i know what you mean, i just think that's totally wrong. if you want to use left-to-right and top-to-bottom order, you start at the cv/gate, then the routing and modulators, then oscillators and on through the signal path. i'd put the "output" after the waveshaper if it would fit on the screen. really though it can be arranged in any way you like, the only problem being that the output is 4 tall while the bottom row modules are 3 tall, they don't mix.

http://xhip.cjb.net/temp/public/one4.png

http://xhip.cjb.net/temp/public/one4.xhipgui

Well, I don't want to be any trouble..... I just am offering ideas. I like the work that you are doing, and trust you. If you feel that my suggestions are wrong, then I'm sure that there is a perfectly good reason.

Maybe there is some other way to indicate the signal flow from component section to component section in the synth.....

--Sean

P.S. Thanks again for all of your hard work!!!!!! You are wonderful!!!!!

audiojunkie · Post by **audiojunkie** » Sat Sep 13, 2008 6:06 am

aciddose wrote:i've been ranting about how powerful the gui code is for months and nobody really noticed, so hopefully this will make a difference. did i mention anything can be textured and the whole system is object oriented with backgrounds, overlays and different forms of blit. (alpha channel, transparency, binary ops, masking, arithmetic, etc)

i forgot to mention about the knobs you said you like, those are just basically circles with a little "metal specular" bitmap in the center and a little dot that moves. that's easy as heck and i'll write the code to generate the stupid specular bitmap later on. for now i'm bored.

also, adding bitmap alpha effects to texture everything uses quite a bit of cpu power, obviously.

i already know what you're talking about with your sliders and knobs and other nonsense, don't worry. those designs are just extremely inefficient and it would be impossible to fit all of xhip's controls using that style. you must choose then between pages (switching mod.a, mod.b, env.a, env.b) or knobs it's really that simple. try drawing it out in ms-paint and you'll quickly realize "IT DONE GONE AINT GONNA FIT ".

that's just the way it is. i refuse to make the gui bigger than about 900x650 and i'm really stubborn.

Acidose,

First of all, I want to tell you that I'm sorry if I am frustrating you.

That is not my intention. It really isn't. I was getting excited and trying to help you.

Again, I'm really sorry if I am making you mad.

You are doing a really, really good job, and I really like the work that is going on with Xhip!!!!!!

Thank you for all of your efforts!!!!

I really appreciate it!!!! I hope you aren't mad at me....

--Sean

audiojunkie · Post by **audiojunkie** » Sat Sep 13, 2008 6:08 am

Go take a break and relax... I don't want you to burn yourself out because of me...

Thanks again,

--Sean

aciddose · Post by **aciddose** » Sat Sep 13, 2008 6:28 am

i'm definitely not mad or even upset, i was only explaining the issues. i suppose a different type of gui could be done but that's another gui. this one is just a test that i've been working on for only a few hours so far. if you wanted to just fiddle with the positions of the controls to change the way it looks, changing the oscillators to the top-left or whatever that's easy. you should really grab the mingw installer, then grab gnumake once mingw is installed. i can help you out with getting it working, then you can edit the source yourself and do this sort of stuff. it's really not complicated, the lines that actually tell where the controls go look like this:

Code: Select all

  {
   frame *pn = addpanel(p, 0, 3.5, 2, 3, "osc.a", hred);
   addknob(pn, 0, 0, WF1, "waveform", red);
   addknob(pn, 1, 0, PW1, "width", yellow);
   addknob(pn, 0, 1, WENVA, "env.a", blue);
   addknob(pn, 0, 2, WENVB, "env.b", blue);
   addknob(pn, 1, 1, WLFOA, "mod.a", blue);
   addknob(pn, 1, 2, WLFOB, "mod.b", blue);
  }

so, the important thing to know is which parameters do what, and for that you need what are called "function prototypes", here:

Code: Select all

adgui::control *xhipgui::addknob(adgui::frame *parent, float x, float y, long param, char *label, long color)
adgui::frame *xhipgui::addpanel(adgui::frame *parent, float x, float y, float xsize, float ysize, char *label, long color)

so from this you should see that the "addknob" function takes a "pointer to" a parent, x and y position relative to the parent, the parameter number (like WF1 for waveform 1), the label for the knob (like "waveform") and a color for the knob.

the "addpanel" function takes the same, only instead of the parameter number it has "xsize" and "ysize" to tell how wide the panel is.

so, the "osc.a" panel is [2 x 3] located at [0 x 3.5] and it's label is half-red which is a color i defined earlier in the code.

a pointer to the panel gets saved into "pn", and then that's used to create the knobs inside that panel.

the "waveform" knob is at [0 x 0] inside the "osc.a" panel, it's parameter is "WF1" and the knob color is red, another color i defined earlier in the code.

so that is really all that's involved, you just switch the numbers to move the controls and panels around and i can write additional functions for sliders and so on to be added in the same way. it's too difficult for a beginner to write their own code, but playing with these coordinates is easy.

people are just really, really afraid to get into this stuff and i guess i can understand why, it seems terribly complicated. it is, but the cool thing is you can use the simple parts at first, then learn the more complicated parts once you need them. at least in this case you have all this code available and don't need to start with a blank file

there was a memory leak in the one4.xhipgui module and some stupidly constructed code that i just fixed, so grab this if you want to actually use the module: http://xhip.cjb.net/temp/public/one4b.xhipgui (same as one4.xhipgui but with the fix, lower memory use and no memory leak)

D.J.T. · Post by **D.J.T.** » Sun Sep 14, 2008 12:41 am

This looks heaps better already ad, although I'm overseas atm and not in a position to test it.

Are people actually using this gui now? If so any feedback?

Are you looking for ideas to implement ad, or are you happy to work at your own pace?
I will say that there seems to be little gui feedback and interaction with the user, as I mentioned before no display of value may be an issue.

What other controls aside from knobs can be implemented and what kind of CPU inefficiency do these introduce? For example looking at the Filter frequency. Is it possible to create a digit display that can then be inc/dec by click dragging up/down or are you limited to only changing the value of a parameter within its screen area (25x25pixels for example)?

Looking good ad.

aciddose · Post by **aciddose** » Sun Sep 14, 2008 12:54 am

there are already displays, text boxes that show the frequency. you can do anything, any type of control, anything. there is absolutely no limitation other than that the fundamental system is 2d - but i do also have a 3d system with which i can create 3d guis, so really no limitations. (for cpu and ease of use reasons, not to mention ease of design, we'll just stick to 2d layouts)

i'm not really interested in writing the guis, YOU people can do that. if you have ideas you just need to follow my instructions in the post above and i'll help you to do what you want. i can write the controls and the main parts of code, and you guys can do the layouts. this one is intended as a demonstration of some of what can be done.

notice it took me about one hour to do the layout.

the rest of my time for the last day has been spent making improvements to the behind-the-scenes code.

nix808 · Post by **nix808** » Sun Sep 14, 2008 12:55 am

Hey,
Thanks for sharing your animation method. I'm a bit late to the party, but I had another play with xhip. Thanks so much aciddose, sounds really good, just doing simple things with it.
Wishing satisfaction in creation, nix

aciddose · Post by **aciddose** » Sun Sep 14, 2008 2:38 am

http://xhip.cjb.net/temp/public/brick_or_stucco.png

was just playing with writing another texture generator for a little bit more variation available and i came up with this pretty quickly. it's a force-wrapped (made to tile smoothly) brick or stucco flavor texture. the generator has adjustable settings of course to generate variable flavors from very dense rough brick/concrete to a light wavy stucco.

i'm still not finished getting graphics out of my system, hopefully i'll write something boring next and go back to the event routing implementation.

BlackOp · Post by **BlackOp** » Sun Sep 14, 2008 2:45 am

This event routing.. you mean theres going to be a mod matrix?

aciddose · Post by **aciddose** » Sun Sep 14, 2008 1:14 pm

no. http://xhip.cjb.net/xhip/todo/
http://xhip.cjb.net/xhip/faq/

for example, velocity to cutoff, or cc #42 to panning. triggers are external events only, internal data and events are not available. the synth is locked down. this is only part of the gui/interface.

Limeflavour · Post by **Limeflavour** » Sun Sep 14, 2008 7:24 pm

aciddose, I played around a bit and made a small mockup.
Before I continue I just wanna know if this is possible or maybe I should scrap the idea.
I made the skin exactly the same size as in "0.6.16.4" and made all knobs 32x32 pixels.
I read that you can easily change the coordinates of all the knobs and boxes but don't know anything about the background, is the background one single bitmap? If it is then maybe my mockup version is possible.

http://stashbox.org/218761/mockup.png

_starcraft_ · Post by **_starcraft_** » Sun Sep 14, 2008 8:45 pm

aciddose wrote:give me a brushed metal texture, the code can load bmps and jpgs. i was generating a brushed metal texture before also, i'm just generating something at the moment to fill the space.

when you say brushed metal do you mean like this? i can just use this texture generator if you like this one:

(this is my simple drawn knob control)

as for sliders, i'm working on that. i just need to improve the slider control to support vertical as well as horizontal alignment, then i can create a bitmap based control in addition to the current drawn version and use better looking handles and slides for them. i can then do some switches that way, and i'll probably want to implement a rocker-switch control too.

just wanting to play with shadows and stuff now actually, nothing fancy just faked shadows that don't move.

nice,geeky and minimal. love this design.

please unlock the features and add I(delay) to the envelopes.
u know it makes sense.

aciddose · Post by **aciddose** » Sun Sep 14, 2008 11:13 pm

Limeflavour; actually you shouldn't continue with the mock up anymore, you should start to implement that with the code instead. there is no limitation like 32x32 for knobs, it's just that it's so difficult to fit everything with larger widgets.

the background can easily be a single bitmap and that is in fact the most cpu efficient method because all background rendering is precalculated and offsets can be passed to the knobs in order to "clean" the background when they redraw using a single blit.

using the real-time rendered backgrounds like these:

http://xhip.cjb.net/temp/public/marble_pwns_metal.jpg

the knobs must "capture" a copy of the background the first time they draw and use that instead. it's actually equally cpu efficient after the initial capture (actually very slightly faster), just less memory efficient.

yes, this design can easily be implemented and if you're very afraid of code i can implement it for you if you give me the source bitmaps. you should try to use alpha-channel if possible, but an alpha-channel can be synthesized using distance from the pink mask that you have now.

starcraft;

please unlock the features and add I(delay) to the envelopes. u know it makes sense.

well, you should know that i asked people several months ago for a period of about one month to give me features requests for anything that was still missing from the synth because the synth was going to be locked, and the feature wasn't requested at that time. actually it doesn't make much sense because you can emulate the effect easily using a combination of both envelopes and both modulators.

i told you i can add a envelope trigger option (in addition to gate, lfo.a, lfo.b, reset) for ("lfo.a delay", "lfo.b delay") to effectively delay the envelopes using the lfo delay controls. that would mean the lfo delay controls are then used up and lfo delay would be disabled, or something. that's the effect of a kludge.

controls will not be added.

that was actually the design i made for my hardware analog.

http://xhip.cjb.net/hardware/audio/ddt2.mp3

XHip--Please finish your synth!!