first of all I am impressed by the new GUI Interface. This is really a great step into comfortable GUI design!
I have two minor problems with the new GUI:
!.) Sometimes if you move of resize a template, it disappeares visually but not really. It seems to live on like a ghost. At special cicumstances, I did not find out till now, this template appeares again visually as a line, or part of the template.
Is there a possibility to limit the minimal size of a template object, or to show, if there are hidden objects?
2.) I have a radio button group for my oscillators with 5 positions 16',8',4',2' and off. This works well in the prototype interface, but not in the GUI. I use the "rbstripsilverbutton5" template, but it switches only between three states: 16' first state and 8' 3-5. state. The second state is "off". This seems to be a set and not a get problem, because if I start with the prototype interface and set the radio button to 4' or 2' and switch over to the GUI interface the setting is correct. Another radio button group with 8 positions has similar problems. Do you an idea, what this is?
1) The vanishing controls issue is solved with the button that says "Lock VCs" which locks the View Containers so that nothing can be dragged/dropped into them. The ability to freely move GUI items between View Controllers is something you can't do with the drag/drop editor in VST3 clients. This was a pet peeve of mine so I made my GUI designer allow you to do this.
The Templates are embedded in View Controllers. If you do not have the VCs locked and you drag one template over another, or you drag a GUI element into the templates outer VC (even just barely), it will absorb it into the template's VC. If this happens, the easiest thing to do is to use the Undo button to restore the GUI, then hit Lock VC's to lock down the template outer containers. You can also see the "captured" controls by expanding the template's outer VC (use the mouse to drag the corner of the VC in the red outline ) to reveal the hidden controls.
I spent a lot of time debating with myself whether to start the GUI Designer with the VC's locked by default (currently they are un-locked by default). When locked by default, it gave the misleading impression that controls could not get dropped into a standard (empty) View Container. However, I may decide to change this in future revs to lock them down by default. And, it is dangerous to try to decide whether the VC is an empty one, or belongs to a Template cluster.
So, my advice would be to start the GUI designer and immediately hit the Lock VC button. Then, only unlock it if you need to create your own VC + controls for a User Template. This will prevent the built in templates from capturing/absorbing other GUI elements.
2) I am probably going to remove the Radio Buttons from the GUI designer. The reason is that there is not a similar corresponding control in VSTGUI4 and I am using the CVerticalSwitch object instead, which is a major pain because you have to manufacture huge graphics files. I have several GUIs where I do use the Radio Buttons but have not run into this problem, though I will look into it.
The solution is to use the "correct" GUI control for this kind of string-list element and in VSTGUI4 that is the Option Menu or Drop List control. It takes up far less real-estate and looks a lot better. You can also customize the colors for each drop-list. So for now, please switch to that GUI control and that will fix the problem.
I almost did not include the radio buttons in the current release because of this issue.
All the best,
now I understand the VC concept. I like it very much, it is really great. But as you pointed out, it is difficult to decide if you switch it on or off by default. I would prefer it switched off by default, because it is a feature for experienced use - and you can add this containers later.
I tried the Option Menu for my switches, they work without problems. I will check the radio button templates next week again, maybe I did something wrong.
I have 3 points on my wishlist. For me Version keeping is very important. Every time I make a bigger change in the programm I start a new version.
1.) Is it a problem to modify the "save as" routine to save the project from RackAFX with another name and update the relevant lines in the "main".cpp and .h and in naming of the the .rc. Now this works nearly, but the .rc is not renamed. And the old namespace is kept in the "main" file . This seems to work, but I am a little unsure, what may happen, if .....
2.) Is it possible to save the complete GUI Interface by default into the new version?
3.) Nearly 90% of the storage for one project is used by the Sock2VST3.... files. Is it possible to make a checkbox in RackAFX to include this files or not. I expect this to be the VST3 libs for different compiler versions.
I don't know if this is easy to implement or not, if it is a problem - I really can live without this features.
Last question: Is there a safe way to update the value setting of my sliders by program the same way I do by the Prototype or GUI Interface (including the graphical representation of this sliders)?
Thanks for help
OK, then I may just Lock the VC's by default in the next revision - it's safer that way.
1) not sure I completely understand your question here but the Save As option only renames the project (including the Visual Studio project files). The .RC file does not need to have the name changed but I could alter that to make it similar. The problem with changing the C++ object to the new project name (in the main .cpp and .h files) is that it is extremely dangerous. It would require changing all the object names as well as any instantiation of the object elsewhere (yes, your C++ object can carry around lists of pointers to newly instantiated objects - one way to handle polyphony). The name-change is done with string-replacement methods only. It is very easy to really screw up the code this way as string-replacement is un-intelligent and would not know how to replace only the object strings. So, for safety, only the project name is saved. To change the name of the object, you would need to do that manually. It isn't difficult for most plugins, but not something I want to try to do programmatically. Also, for reference, the Save As function came as a request from a student to "freeze code" which is common when working with constantly changing revisions. In the code-freezes, the whole project is copied and saved, but object names are never changed. This allows you to go back to a previous (working) version and copy the code directly without having to change object names.
2) the new GUI is packaged in the RackAFX.uidesc file, which is also copied in the Save As operation. It should show up by default in the Save As version as well - if not, let me know and I will check on that.
3) yes, these are different libs for each compiler - this is also new from the pre-6.5 versions because these new libs include the std::string library, which is different for each version of Visual Studio (sigh) but not XCode. I could add an option in Save As so these files are not copied. Also, in the next version, you will be able to delete all these libs so you can move the project folder around easily. Then, each time you open RAFX, it will copy over any missing libs.
4) to update any GUI control from within RackAFX (programmatically) you use the sendUpdateGUI() message, after setting the underlying variables. This is covered in the Forum post here:
If you look in the plugin.h file, you will see that this function lies outside of the "ifdef _WINDOWS... statement. It is the only update function that is cross-platform compatible. There are 2 (now obsolete) functions:
void sendSliderCtrlUpdate(UINT uID);
void sendAssignableButtonClick(UINT uID);
These only work in Windows, and therefore do not work in the VSTGUI-code part because I have to make sure to keep it platform-independent. sendUpdateGUI() will handle all cases except the assignable button click, which no one seems to use anyway (I have never had to use it myself).
A new version will be forthcoming within a few weeks as I have a minor issue to correct with the Analyzer dialog hiding some buttons. I will see how many of these issues I can add - for example locking the VC's by default is easy.
To 1) Yes, you are right my wish may end in a nightmare, so forget it.
To 2) I started with my MultiMoogA project. Then I saved the project as MultiMoogB and added a GUI in the "B" version.
After saving MultiMoogB as MultiMoogC the compiler misses the MultiMoogA.rc file, which was not copied. I copied it manually and the project compiles well but had no more GUI. The RackAFX.uidesc was includeded in the MUltiMoogC project, but it was not the RackAFX.uidesc of the MultiMoogB project (size 115 kB) but a smaller (empty?) RackAFX.uidesc (15 kB). I placed the correct RackAFX.uidesc file in the project, rebuild and then everything works.
Again - thanks you for your help!
I have just released v6.5.14 with three changes from your list - Save As now properly saves the RC file and GUI - you can compile the Save As version right away correctly and with the GUI in tact. It also adds an option to Omit VST3/GUI Libraries to save disk space. Finally, the GUI View Containers are now locked by default - remember to unlock them when building your own templates or VC based clusters.
Also note that Save As *does* change the plugin's name string (m_PlugInName) so that it will appear as a separate plugin in the User Plugins menu as well as VST/AU ports.
Thanks for the suggestions.
Most Users Ever Online: 152
Currently Browsing this Page:
Guest Posters: 2
Moderators: W Pirkle: 693