GUI Ideas

1 2 > >> (Page 1 of 2)
  • ssj71

    ssj71 - 2011-06-16

    I may have some time to work a bit on a GUI. I'm not familiar with the GTK libraries, but I'm looking into it. Its all C and C++ right? :D But I'd like to get a feel before working too hard: would you prefer rackmounted effects like guitar rig  and revalver or pedals like audiffex?

    I think the idea is something simper so users aren't overwhelmed with the every-parameter-up-front interface. I think the easiest would be to make a bunch of pedals for the background of the pedal frame, then load a few knobs for the most important parameters and bind them to the sliders of the effect underneath. Basically making a skin over the current effects. We'd still have the On/bypass led and maybe just some arrows for presets or still the drop down. Then maybe if you click the stomp button you could open the full parameter view (as it is now) underneath. Maybe that's counter-intuitive. Anyway, I just wanted to hear what everyone thought.

    I've only started playing electric this year so I'm a total newb to what parameters are most important. I'd probably need someone to make a list of the <5 most important parameters for each effect (excepting the EQs of course).


  • Transmogrifox

    Transmogrifox - 2011-06-18

    I can help you with a list of important parameters for each effect.  My target would be 3 (maximum) if possible.  My preference for a GUI would be like a guitar pedalboard and something that looks like pedals.  That seems to be an interface that would be familiar to most guitar players.

    As far as the GUI goes, it is easy with Rakarrack.  It is designed where the signal processing thread and the GUI are totally independent, so you don't have to work with anything that exists.

    Our conversations on the topic before usually end with an agreement that any and multiple GUI's can be launched at startup.

    You can write a GUI with all the options you like.  Any of the knobs/buttons/preset parameters, etc, only need to be designed so the button calls a function and gives a value.  Rakarrack takes care of the rest, so not much needs to change.

    Then we can help you attach functionality to the knobs & buttons.  If you want, you can come up with your own scheme for users browsing, displaying and editing presets.  The rest is just calling the functions already in place to load and save.

    Starting fresh, you can use any GUI library you want.  QT has a nice designer interface, GTK is not too bad.  You could be really adventurous and design the whole thing using SDL.  GTK is a good choice if you want to target the Gnome desktop environment (Ubuntu default).  If you want to target KDE users, then QT is probably a good choice.

    The GUI will have the least impact on RAM usage if you choose a library that is consistent with your target desktop user, since typically most of the shared libraries the application will use are already loaded in RAM before you start the program.

    In the case of Holborn and myself, FLTK is good because it's lightweight on resources and we don't use a desktop environment…just X and a window manager… so FLTK is good that way.

  • Transmogrifox

    Transmogrifox - 2011-06-18

    …and to answer your other question, GTK IIRC is written in C in an object-oriented manner so C++ programs can make easy use of the libs.

    Really, it's just API programming where you happen to be using C or C++ as the glue to hold the components together.  You could probably make a perfectly functional Rakarrack GUI using Perl and GTK (although the interface to Rakarrack will be easier using C++).  If we implemented osc control, then a web interface designed to run on a remote server could be easily implemented for all that. :)

  • Anonymous

    Anonymous - 2011-06-19

    Hi guys, just my two cents :

    I find the interface of Rakarrack really nice (well, not *nice* in the plastique sense) and practical. The only area where FLTK is a bit of a mess is in the "order in your rack" window, the sound bank, the prefs, but the main GUI is really OK, and lightweight (I had to switch from KDE4.4 to LXDE to finish my last song's mix & mastering because of xruns).

    What I wouldlike to see improved :

    -The routing of the modules - it's unclear what out goes into what in
    -Saving of the patches - The saved file should be internal to Rakarrack, only exposing a file requester if one wants to "import" improving the workflow and limiting clutter
    -Plugin integration - Rakarrack could provide two INPUT an OUTPUT menus like JAMin does… Oh well, it works really good right now, patching things with JACK.

    But as it is right now, Rakarrack really rocks rabid rabbits :)

    Just as a side note, how can I turn on antialiasing for FLTK fonts, like in your neats screenshots?

    Here it's all mangled, and I tried every window mgr under the sun - I'd really like some help, where can I find this info ?


  • Josep Andreu

    Josep Andreu - 2011-06-19


    Thanks for the ideas …

    I agree with the Order rack window … unfortunatelly the FLTK browser widget doesent support Drag and Drop :-(  and that's really bad …. I can subclass the widget ..and add this feature but … do that only for this is too much work ..  for nothing.

    The route of the modules is very simple … is linear … IIRC is explained in the help …  we have plan to improve that …  we are thing on that :-)

    Sorry my english is bad and I can not understand what you meant in the Saving of patches part ..  if you can explain me … I will appreciate :-)

    About the antialiasing fonts in FLTK … I made all the scshots .. maybe the possible solution is in /etc/fonts/conf.d … they are some configs that probably you need on a ligthweight desktop that maybe this big desktop managers don't  use, I really dont know I have years without Gnome or KDE in a minimalist system sorry. Or maybe is due becuase I use the nvidia driver that helps.


  • Renato

    Renato - 2011-06-19

    I second Phil, I find the current GUI very usable and efficient, but I also would find great if there were an option to use a more cleaner one in gtk or qt, and also I think it will help expand rakarrack's user base.

    What I think Phil was saying for saving patches is that as it is now it's quite cumbersome to tweak patches, because each time you want to save you have to choose the file.

    One situation which happens me quite often when I use rakarrack is I have a bank with many patches, and I go through them to tweak them and normalize volumes; every time I like the changes I made I have to:
    1) switch to bank window
    2) right click on the patch name to overwrite it
    3) choose "Save" from the file menu
    4) select previous bank file (first time actually choose the correct folder from the "Favorites") and click ok
    Of course it isn't very much of a hassle for a single patch, but when you have to do it many times it becomes cumbersome. Of course I could also save the bank only once in a while.

    So I guess what Phil was saying with the saving process being "internal" to rakarrack was that you don't have to choose the file every time, but rakarrack has a single big file somewhere (maybe in your home) where all your presets are stored, and to save a preset you just click a button in the main GUI.

    BTW, would it be possible, without OSC, to write a GUI in python with pygtk, wxpython or whatever? I guess you'd have to use something like cython to implement the calls to the rakarrack engine right?


  • Transmogrifox

    Transmogrifox - 2011-06-19

    The only thing preventing a GUI from being developed with a different language like Python or Perl is a C binding.  Since I'm not familiar with Python, I'm not sure what bindings exist… but if you can do it without needing a special interface/binding on Rakarrack, then the segregation between the GUI is enough that you don't need to do any of the signal processing in the GUI - it's only passing messages and load/save configurations.

    Renato - that hat (in your avatar) is amazing ;).  I like it.

  • Josep Andreu

    Josep Andreu - 2011-06-20


    IIRC … the patch name that appears in the "Save" window use is the "actual" patch name …  if you want a differet name what you need is rename the patch in the main window… and press ok  in the "Save" window, is a way to avoid the "Are you Sure" window,     also when you save a bank … only the first time you need to select the file .. ( needed to create a new bank) .. the next time you save the bank the the Bank Save Window remember the last file saved .. then what you need is only press the OK button … also is a way to avoid the "are you sure"  window  :-)

    Well … maybe they are better ways :-)


  • Renato

    Renato - 2011-06-20

    haha yes the hat comes in handy in those windy winter days we have here, like this:

    regarding the saving process, yes I see what you're saying josep…. but still IMHO it would be good if the "Save" button just saved, without opening the window and having to click "Ok" (there could be a "Save as" entry in the File menu if one wanted to save to another place) AND if there where a "Save patch and bank" button that would save both the patch in the bank and the bank, without asking anything…

    But that's just an opinion of course, it's something open for debate and ultimately not that important…


  • ssj71

    ssj71 - 2011-06-20

    Well, I hope I haven't bit off more than I can chew. :) I thought I'd post a little update here though. After a few hours of working I've got some mockups for feedback. I am planning to do this in qt (C++) but I'm going to subclass the qdial and buttons to make them able to have different "skins" so it won't really look much like a qt program. That way anyone who wants to make an svg can use it as a knob or pedal frame or button etc. Anyway, I digress. Here you are:

    One thing though: I can make the labels as part of the background image (ie the red pedal) or use the QT text label object. If I use the text object it can be translated but as the background its more fancy. Translations would require a separate skin. Thoughts?

    Anyway hopefully this is a positive direction, not doing useless work. I do plan on having an "advanced" window that you can open to see all the parameters of the effect.

    Transmogrifox: in the rakarrack "engine" is there anything preventing multiple instances of an effect in the chain? Is that a desirable feature? This is still down the road quite a way, but I've been wondering about it.

    Anyway, cheers,

  • Renato

    Renato - 2011-06-21

    wow, that looks really cool, looking forward to your GUI :)

    I think you can leave the names as part of the graphics, since AFAIK effects' name aren't translated; for example in italian, "Gain" is "Gain", "Overdrive" is "Overdrive" and so on. I think that's the use since those that produce real hardware pedals don't bother making different versions for different countries, so these foreign names got in the guitarist's/musicist's language.

  • Transmogrifox

    Transmogrifox - 2011-06-22

    Transmogrifox: in the rakarrack "engine" is there anything preventing multiple instances of an effect in the chain? Is that a desirable feature? This is still down the road quite a way, but I've been wondering about it.

    Nothing fundamentally prevents this, but the current implementation is relatively static.  We have talked about making a mixing & routing functionality before so this might be a good reason to try to implement it.  Either way we will all need to be involved because at this point I can't just tell you "invoke this object then that one"… I mean, yeah, you could make a magicmixer.C file and use each of the FX objects to your liking, but the implementation is a non-trivial thing…

    So we need to get Holborn's input and probably hash things out on IRC when you get far enough along to start trying to integrate it with Rakarrack.  Unfortunately  I don't have as much time as I used to so as you can see, my git activity is pretty sparse recently :/

    It does help to "put some fuel in the tank" when somebody shows interest so this may be enough kick to get things moving again :)

    Your mock-ups look like the right idea.  Stompbox looks nice.  I definitely vote for non-widget text, I mean, designed as part of the graphic so it can look as good as the skin designer can make it :)

  • - 2011-09-05

    Hi guys,
    Are you still thinking about a new GUI?
    Because I have something fresh in mind, and I'd like to know your opinion about it.
    The problem is that I don't know anything about using C (or other language) to create user interfaces, this includes GTK+.
    How long could it take me, if I already know plain C and work hard for 1-2 hours a day, to design this?

    It's here:

    Some details about it:
    It's NOT a screenshot! The background is a screenshot, but the gui is done (as a preview) with html and css.
    The link inside the effects is the first mock-up I did, then this link is the second mock-up.
    There are 3 panes, the Control (top), the Overview (bottom) and the Specific (right).

    Control would be really similar to the one now in rakarrack, just a bit more compressed, mainly in the Preset section.

    Overview: If you click the button which contains the name of the effect, turns it on/off.
    If you click the X, it "deletes" (hide) that effect (reminder: and turn it off), making that spot available for another one (clicking in the remaining space).
    The Overview interacts with the Specific in this way:
    If you click the space (which will be a small image with non-interactive buttons) between the led-close and the name, that effect will be loaded at the Specific view, allowing a big resolution adjustment (instead of many small ones), with more precision.

    It's really intuitive. I don't think it requires more than few seconds to get used to it. Still, it's new and fresh, I haven't seen it in any other guitar effects. I think it's the ideal join between the modular design of Guitar Rig (which could be confusing) and the pedal-like design of Audiffex (which has too many shown options, like Rakarrack).
    It doesn't overwhelm the user with loads of options at the same time.
    It allows a more modular and easy theme design; You can design just one effect skin at once.

    It requires one click more for each effect, and if you are playing the guitar it's annoying.
    When creating a theme, you'll need to do 2 designs for each effect. The big with small button (right) and the preview (left).

    Conclusion: I like the design I made (that's why I'm showing it to you here), but what do you think about it? I would really appreciate some feedback.

    PS, I thought about the themes, what do you prefer?
    1. The user can edit the border background, the fabric pattern and each effect texture, making the shadows, sizes and other etc fixed.
    2. The user can edit the background (border+fabric+shadows), and each effect.

    Sorry for my English! I hope you all understood me.

    Cheers, Francisco

  • - 2011-09-05

    PS, Godaddy and 000webhost apparently don't want to work well together (I think I'm doing something wrong), if the link doesn't work, please delete the www.

  • Renato

    Renato - 2011-09-05

    hi, the graphics look very good to me!

  • ssj71

    ssj71 - 2011-09-22

    Hi friends,
    I worked a bunch during the summer, but I'm trying to pump out a masters thesis so free time isn't really around any more. Maybe at Christmas. I only got so far as overloading the paint method of the various qt interface widgets (knobs, buttons etc) to load svg images instead of the default. Its looking good but progressing slow. Next step was to get them to load into a stompbox widget. If anyone wants to pick up on this I'd be more than happy to send the source and some better explanation of my idea.

    @pakito:  That looks great! its a really slick idea so keep going with it. If we end up with 3 different GUIs at the end I don't see how thats bad.

  • - 2011-09-22

    I am still working on the code, I've done the window frames (so far, there are no images nor anything except the simple very simple frames). I attach the image, what do you think/feel about the preview? Are you missing something? (well, I forgot the "File etc menu")

    I would really appreciate feedback about it, any idea or opinion, even a bad one, would help and encourage me to keep working on this! (:

  • Transmogrifox

    Transmogrifox - 2011-09-23

    What is in the Effects boxes, and what is in the Adjust Effect frame?  Are the "Effects" just images of the effect, then Adjust is where you modify parameters for it?  Then maybe you click on the effect, and the Adjust Effect frame changes to show the effect parameters?

    Or do the Effect boxes have some of the simple parameters, then Adjust lets you tweak the more advanced parameters?

    Second, what is the "Gain" dial for?  You already have and In and Out level, so I'm not quite sure what is adjusted by "Gain".

    Here is an idea worth considering ->  What do you think of making the effects frame something like a canvas, where it is like Patchage?  You would drag the FX out of a palette onto the canvas (as many as you want), then draw lines between for whatever signal routing you like.  I could add something like a mixer module, then somebody could put effects in parallel.  I know it's a lot of work, but it's an idea…it would make it feel more like having a pile of pedals, cables and mixers…  :<, :/  or :) or :D?

    Thanks for posting, and thanks for your efforts. 

  • Transmogrifox

    Transmogrifox - 2011-09-23

    Oh… another idea came to mind.  What about dual in/out levels.  I mean for stereo, one for left, one for right so left/right levels can be adjusted independently, but make the two chainable, so they move together when you chain them, and keep the same relative positions they had when you chained them.

  • - 2011-09-23

    The effect boxes are the individual effects, and there are 3 buttons within each little effect box: The whole effect, that would display that effect in the right side letting you tweak the effects there, the bottom button that would turn that effect on/off (and it'd be seen on the led), and the X button, that would delete that effect from the effects. I thought about putting few simple parameters at each of the small effects, but then I thought it would be too much. I really wanted to make this simple and easy to use, because if you are playing the guitar I don't think you want to be bothered with too many small buttons.

    Sorry for writing "Gain", it should actually be named "FX%", as it's seen in the current GUI.

    About your other ideas:

    The first one, :D definitely!! But, also, it seems impossible for me as I'm learning, if someone could do it, it'd be really cool!

    The second one, I think it'd be good to have that function, but I don't think it's important enough, at least for the use that many people gives to Rakarrack -to play at home-, but thinking about the future, it sounds good. Would it be a channel selector at each effect?

    One more idea I thought, what about integrating a small drum machine in the effects? I know that the best if you want to play the guitar with a drum is to use something as Hydrogen at the same time than Rakarrack, but I think it'd be useful for a quick play with basic drum, it'd be a bass drum, a snare, a cym and a hit hat (and maybe a couple of toms) in a loop way, just to add some variety to the  tempo and that doesn't require to know a lot about rythm to be set up

    Right now I have no idea on how to continue, I'm designing it with Qt3 Designer and I need to learn how to "define" each effect so when you click to add it, the GUI changes to show this in the rack. I will be asking around at forums, but if anyone can progress about it, please post it here!

    Here is the source code (just save it as .ui and open it with Qt3 Designer), ofc you can modify it as much as you want, just, if you do use it, say my name somewhere visible ;)

    And a screenshot of the current progress:

  • Transmogrifox

    Transmogrifox - 2011-09-24

    Generally speaking, each "effect" will be its own class that gets its coordinates from the frame.  Probably when you draw that frame, each "space" will invoke a function with a switch statement that has each effect enumerated, and whatever case matches the parameter passed is the object that will get drawn to the frame in that location.  Probably there are more efficient ways such as making an array of pointers to the classes you want to draw, so when you get a screen refresh you just step through an arrray of 10 pointers - this is actually very similar to how the DSP code calls the effects on the non-gui side…well…is actually a big switch statement but the array holds each case and the switch is invoked 10 times.  Even there maybe an array of pointers would be more efficient …but that is off topic.

    Anyway, I know that was a very broad and generic way of stating it, but I hope it pushes you in the right direction anyway.  Using QT designer at first sort of hides the underlying mechanics (which is the point), but when you're new to GUI design and learning it may be as much a hindrance as a help.  I can' t offer much more advice than that because my only experience with GUI programming is a few minor things I do to the existing Rakarrack GUI.  Most of the time I play in the DSP code so I, like you, would consider myself more of a C programmer with some basic understanding of C++.

    The work flow is not as easy since all the parameters are not one mouse click, but still not too bad.  It's pretty quick to click an effect then move the mouse to edit.  For having all parameters in view, well, we have the GUI we have now :)  It wouldn't make sense to make an alternate GUI that is the same, for sure.

    One thing that I think would be easy to implement would be "connectors" in the graphics - just something like a cable between each one that shows how they are all connected.  Then that removes the uncertainty about how the signal routes through the chain, and then you don't have to read the help to know it  ;/

    This interface could be very professional looking if a good graphic designer got involved making skins.  I'm thinking you're on the right track in making this a much more simplified interface with only a few knobs on each effect.  Maybe as time goes on and if you have the time you could eventually implement an "advanced" button that opens a pop-up window with more of the advanced parameters.

  • Bart Deruyter

    Bart Deruyter - 2011-10-01

    Very interesting discussion :-), I am waiting for a change in GUI for a while. I know plenty of people wanting to try linux for multimedia, and the way software looks is for most a real issue. Most find Rakarrack great, when they hear it… but they step back when they see it. So, it is really important.
    Because I'd like to see a more widely use of tools like Rakarrack, (also for the selfish reason that I'd love to see my friends use the same tools I do, which would make some things like sharing ideas about making 'the sound' of a song quite a lot easier) I want to contribute, even if it's only with developing the ideas.

    I like transmogrifox Idea about cables showing how the pedals are connected. I'd give this a big + . I'd like to add something to this actually. In my pre-opensource time I used to work with 'Reason', softsynths and a sequencer, with effects bundled in one package. And I loved their approach. Pushing the tab button lets you switch to the back view of the synths, effects, mixers etc… where you make your connections. Cables can be swapped around by dragging them around to the different effects and synths.

    I admit, it's not that efficient, in terms of speed and connecting things quickly, but it is for musicians a familiar view and easy to understand. An issue could be how to let the user know they have to switch to the back view of course. But I think with a simple sign, like a button on the bottom with a 'page turn' sign could do the trick with a click too, and perhaps a tooltip when hovering over it, showing the 'tab' as alternative to get to it.

    If wanted, I could try to design some things in Inkscape and Gimp, making mockups is something I really could do and would love to do. Also for the current ideas of course, having a more detailed view on how it should look like can ease the development. A mockup is easier to modify then code.
    Let me know to go for it :-). And I hope you like my idea.


  • - 2011-10-06

    First "working" mockup of the window:

    The three main bugs so far:
    Corners are not correctly rounded
    Radio buttons have a sqared background
    The Big Effect (renamed from "whole effect", it's the one at the right) overlaps. This is a problem since there's even an order of overlapping, so you'd have to hide manually  other effects to edit the ones at the bottom.
    The fourth one not shown here, it's that all the Big Effects are showed at the beginning, and I don't know how to change this.

    I'm really tired and it's late, tomorrow I'll explain a little more and answer your opinions

  • - 2011-10-06

    Awesome, the main problem (the one about the "Big Effect") is solved thanks to Liz at StackOverflow:

    So thinks seem to work much faster now, I might have the main gui ready soon enough and then I (or whoever who wants to do it) will start to work about implementing it with the Rakarrack functions and some other features.

    I have one more question,
    Is Rakarrack dynamically expansible? For example, can I add a different effect as a patch or would I need to change some source files? Because if that is the case, then I should re-think about the way I'm creating the GUI, and also to know if I can borrow the current list of effects to design them all.

    About the implementations you propose, all of them are great, but I really cannot and don't know how to do most of them…

    To transmogrifox:
    I finally solve that problem about showing different big effects, it's as easy as putting one on each other and to raise the one you click. I'm seeing another problem coming from this, but I'm still not there.

    The "connectors" you propose is a great idea, so I think it's just a graphic thing, so I won't implement it right now, but it's a must for the final version!

    I also think that the work flow is not that good, but in exchange we have a bigger (bigger buttons), less stack and easier to use interface. I don't think I'll put any button at the end inside the small effects.

    One of my best friends is really good at drawing and graphics in general so that's not a problem, when I finish the interface with my horrible drawings/colors I'll ask him for help, and this can be the very last thing.

    I didn't see the bit about the popup button until right now… what kind of advanced parameters could I put there if they're all in the big pedal? I don't really understand that, sorry.

    To bartissimo:
    "I am waiting for a change in GUI for a while. I know plenty of people wanting to try linux for multimedia, and the way software looks is for most a real issue. Most find Rakarrack great, when they hear it… but they step back when they see it." One of that people (persons?) was me, and since I saw that there was more people like me and the possibility to make some change, I started to design this interface. And I hope that it's useful for some people apart of myself. (;

    About the idea from Reason… I already stated I'm not good programming gui, I can design it and give it my best, but I don't think I can go that far.

    Thank you all for the opinions/ideas, I'll take some time to keep working on the GUI and I'll try to post here when it's finished!

    PS, sorry for my bad English.

1 2 > >> (Page 1 of 2)

Log in to post a comment.