G-Force 4/Toolbar

Post by **andy55** » Thu Jul 19, 2012 7:11 pm

Hey everyone,

I've love to get some input and opinions regarding G-Force, especially from our moderators and other senior users. Please be conscious of the various details described below so that you can form the best analysis possible.

With the built-in Themes and Category features now built into Aeon 2.5 (and WhiteCap when it's released), there's basically no longer a lot of value in the separate G-Force Toolbar that we ship with G-Force Gold and Platinum. This is because the built-in Themes and Category features now present in our engines are a superset of functionality offered with what the G-Force Toolbar offers. Basically, the only thing the G-Force Toolbar offers at all at this point is a native UI (rather than an in-product user interface).

You may wonder, "let's have both the Toolbar *and* an in-product UI". Sounds great, but SoundSpectrum sadly does lacks the developer resources to maintain both (since they both have to play nice with each other and the testing required).

So, I'd like people to comment, weigh in, and vote on what they'd like to see. Again, because we're strapped here, we can't have both a G-Force Toolbar and an in-product user interface. As CTO, switching to an in-product UI and retiring the Toolbar is *way* easier and less time than the keeping and maintaining the Toolbar. However, we here at SoundSpectrum have concerns that users who are evaluating G-Force to buy may not be as likely to purchase G-Force if they're not enticed by seeing that they get the Toolbar by purchasing G-Force. It'd be great for people to comment if they think the ads or expectations for G-Force Toolbar had an impact on their decision to purchase G-Force.

Thanks!

Andy

juxtiphi · Post by **juxtiphi** » Thu Jul 19, 2012 7:55 pm

Hello Andy

Maybe an easy way to go would be to "relaunch" G-force as in "G-Force Mach 2" with the relaunch you can implement the new design so old and new customers would easily be made aware of the change.

just my two cents

JayPro · Post by **JayPro** » Thu Jul 19, 2012 8:41 pm

The next level up is obviously 5. The easily understood psychological significance of the number makes the new features an absolute cinch to be associated with this new version's release. No extra labeling IMO is needed.

All that needs explaining is the the GUI of G-Force is merely undergoing the same facelift as all the others. But it's also important to remind folks that this is necessary to re-establish its status as the company's flagship product, and at once ensuring consistency vis a vis how it's used.

This IMO gives the user the impression that intuitiveness of use is the company "motto".

The Toolbar for GF has been redundant for years now. Even the V-Bar might be perceived by a handful as a compact version of the Standalone...although there exists a feature or two that warrants its continued development, i.e. can the modern SoundSpectrum GUI be actually applied to the SA?

Fabricio · Post by **Fabricio** » Thu Jul 19, 2012 8:41 pm

Hello,

It's hard. I like: on-screen menus (Aeon), but I also like G-Force Toolbar.

G-Force Toolbar is the face of g-force. It's the difference ...

but, on-screen menu is modern, elegant, easy access. I choose: remove G-Force Toolbar.

JayPro · Post by **JayPro** » Thu Jul 19, 2012 9:07 pm

@Fabricio;

Actually the GF Toolbar and V-Bar were both relatively late additions to the product. Before all of that, the user simply toggled command keys within either the Standalone or the iTunes visualizer to get the results they wanted.

jerohm · Post by **jerohm** » Thu Jul 19, 2012 9:15 pm

I have a valid Aeon license, but it seems 2.5 is not available for general download, so I haven't gotten the chance to evaluate the new interface.

During GF Waveshape development, I find the toolbar indispensable, but maybe only because it is convenient. Right now I can run multiple displays, with GF running Fullscreen on one display, and the Toolbar and editor opened on the other. Would the keyboard shortcuts still work? ... I would miss them. Since I assume that the Toolbar communicates/controls the GF engine utilizing the script command language, I would HOPE GF would still support the full Script Command set... right? If the Script Command Language would go away, it would be sorely missed.

(being a facility IMO, ripe for enhancement!) Just viewing, I don't see much of an issue... development and testing may be a little different story..
jrm

JayPro · Post by **JayPro** » Thu Jul 19, 2012 9:25 pm

@jerohm;

IIRC the keystroke commands are retained in all SS apps that use the "in-house" GUI. I haven't had a chance to play with my WC app in some time; but it is my almost certain recollection that the key functions are there...and I don't really see any reason why that feature should be done away with.

Post by **BTT** » Fri Jul 20, 2012 7:07 pm

Hello All

Does this mean that G-Force will in future be using Python?, and will the configs also be constructed using Python?

Regards BTT

jerohm · Post by **jerohm** » Mon Jul 23, 2012 9:19 am

RE: "will the configs also be constructed using Python?

I, for one, would be incredibly disappointed

, if that be the case. There are several features of constructing Waveshapes that I have discovered through just playing around... and like Unix, they followed a very logical thought process. Since they are not documented, I can only assume they were positive side-effects remaining from the inclusion of VectorC. Although the documented syntax was obviously good enough to create a vast number of effects, the additions which came along with the VectorC port (as well as the 'select()' statement) greatly increased the possibility of what could be accomplished (or the efficiency thereof). A language should facilitate the ease of trying to get a task done. Configs are a very specific task and the current syntax, along with VectorC (extensions) meets that goal very nicely. Not that some additions ('shuffle(cols of a row)', Pen and LwDt(dimensionalized to accommodate X_,Y_ pairs within a single task, etc) would be welcome. Python enforces rigorous structure to accommodate convention/control/reusability... good for some purposes... bad for others... When the solution (implementation) becomes more complicate than the task you are trying to accomplish, it is time for a beer, and to take another look.

jrm

JayPro · Post by **JayPro** » Mon Jul 23, 2012 12:59 pm

^^^^^^^^
That.

I'm hoping to God that we don't go all Python with G-Force. I have zero programming experience with it; whereas at least in spite of the recent C+ based recensions of the long-standing GF config coding language, I can still create configs. This especially applies to the classic configs that *still* work that don't have the aforementioned recensions took place.

Briefly, if transitioning to the G-Force 'in-house" GUI requires a wholesale shift to Python, I choose to revert to the Toolbar.

And think about this: *Every single config* available in the Contributors section of the website will have to be redone. There are even more of my creations that *aren't* in those archives because I haven't submitted them for various reasons. And I'm sure there are others who will tell you more or less the same thing.

I will not be able to muster the patience to "Pythonize" any of them.

m2c · Post by **m2c** » Mon Jul 23, 2012 1:26 pm

Not to worry, switching the UI won't affect any existing configs. In the future, if we went the route of adding python to G-Force, it wouldn't change the existing way of creating content, it would simply add more options of what to draw in the foreground (currently waveshapes), as far as I know.

jerohm · Post by **jerohm** » Mon Jul 23, 2012 2:49 pm

Well that is a relief... I real appreciate the syntax now...Most everything I throw at it, Just Works (I have generated a list of what I consider implementation deficiencies... in case you are interested). Not that I couldn't make a few suggestions for enhancement... but they would be more to address efficiency, and to a lesser extent, functionality.
...And I can assume the scripting command language would remain 'functionally' intact??

One other question, will the licensed version have anyway of controlling over the network, or does that go away?
thanks

(vote: abstain)

Post by **BTT** » Mon Jul 23, 2012 2:54 pm

Hello All

Well, I am not convinced. If G-Force is to have a GUI as Aeon, and WhiteCap which both have Configs or Scenes, call them what you want the fact is they are both in Python (as are the ColorMaps in WhiteCap) which has me thinking that SoundSpectrum would like to go the same way with G-Force. Should such a decision be made I believe this could well be the beginning of the end for G-Force which is a quality program, and has a reputation other SoundSpectrum products can only dream of. G-Force is the money maker for SoundSpectrum, so keep G-Force as we know it, keep the the toolbar, and maybe add some new features as suggested in jerohm's post.

Regards BTT

JayPro · Post by **JayPro** » Mon Jul 23, 2012 4:38 pm

m2c wrote:Not to worry, switching the UI won't affect any existing configs. In the future, if we went the route of adding python to G-Force, it wouldn't change the existing way of creating content, it would simply add more options of what to draw in the foreground (currently waveshapes), as far as I know.

...quote edited by me.

But that's just it, though. G-Force waveshapes and particles, as you surely know, are made with the good ol' syntax code that puts all other GF configs together. Pythonize that, you might as well pythonize everything else.

I'm changing my vote to "abstain" until this matter is straightened out one way or another...but if pythonization is the inevitable fate of the GF config's method of construction....I'm changing it back to "keep the toolbar".

m2c · Post by **m2c** » Mon Jul 23, 2012 4:44 pm

To clear some confusion, only the menu system (choosing configs, themes, colormaps, etc.) would use python (as it must, that's what it is built on) - there is no talk of replacing vectorC as the means of defining waveshapes & particles. Whitecap uses backgrounds that are made in python - G-Force uses the flowfield as the background, and obviously it would not make sense to change that in G-Force.