G-Force 4/Toolbar

[JayPro]

As Long as Python and VectorC play nice together, I'm happy.

[BTT]

Hello All

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).....

Then we do NOT want such a menu system in G-Force. LEAVE IT ALONE FOR GOD'S SAKE.


Regards BTT

[BTT]

Hello All

Seems like I am the only one who voted to keep the toolbar, and I am increasingly convinced I did the right thing.


Regards BTT

[JayPro]

I'm honestly not understanding the protestations going on against the newer GUI. If it's already been established that config development only is addressed by the VectorC element of the application, why would a Python-constructed GUI be objectionable?

I'll mention again that the Toolbar is IMO a redundant component whose many functions can *easily* be recapitulated by the many keystroke commands found within the Standalone and the iTunes build...and now, in a clean, convenient way through the new GUI.

How is any of this problematic then? mc2's explanation on which programming language handles its respective aspect of the program suffices for me.

The only thing I would make people aware of is that the Python menu size at its smallest should be as unobtrusive to the enjoyment of GF activity as humanly possible.

[BTT]

Hello JayPro

Reading Andy's post regarding this matter, without actually saying so the Python GUI is more or less going to happen. When things started going Python in WhiteCap it was not too long before WhiteCap was all Python, even the ColorMaps, and I am convinced the same will happen to G-Force. It will start with the Python GUI, and rapidly spread to everything G-Force related, regardless of what SoundSpectrum say now. Personally I do not use the toolbar in G-Force, they can do whatever they like with that, but I do not want to see the Aeon type of GUI in G-Force. I love G-Force as it is - the best visualiser - and I will fight to keep Python a million miles away from G-Force.


Regards BTT

[juxtiphi]

Hello JayPro

Reading Andy's post regarding this matter, without actually saying so the Python GUI is more or less going to happen. When things started going Python in WhiteCap it was not too long before WhiteCap was all Python, even the ColorMaps, and I am convinced the same will happen to G-Force. It will start with the Python GUI, and rapidly spread to everything G-Force related, regardless of what SoundSpectrum say now. Personally I do not use the toolbar in G-Force, they can do whatever they like with that, but I do not want to see the Aeon type of GUI in G-Force. I love G-Force as it is - the best visualiser - and I will fight to keep Python a million miles away from G-Force.


Regards BTT

Hmm I guess I didnt think this through, I voted new menu but now I'm thinking that it benifits G-force to have the tool bar . Being able to control G-force on another screen with out having to affect the vis while watching (unlike Aeon) is a key componet to the overall functionality and beauty of the program.

Being able to customize G-force in real time via the tool bar gives the veiwer more control over what they see and when .

[JayPro]

Then the whole rhetorical question boils down to this, toolbar issues aside for the moment:

Why did Andy & Co. bother painstakingly integrating VectorC into G-Force to begin with, when it would've been easier for them to decide on using Python from the outset????

It's evident that WC, Aeon and GF are now entities as visually distinct as they come. With respect to the first two, yes; Python is the developer's choice of programming; and both magnificently demonstrate how *amazingly* versatile Python is as a "visual music" tool kit.

But re G-Force, how can one Pythonize a flowfield????? Is it possible? Indeed, *why?* would one attempt such a thing, given what I mentioned before with VectorC?

Furthermore, why go thru the hassle of pythonizing a common Aeon/GF-usable palette when the option to making a VectorC-coded config .txt file is to simply integrate a simple .png that VC can read in a snap???

My 64 million quatloo question has been answered and clarified by m2c:

VectorC will continue to be the programming environment for config development within G-Force. Period.
So why would Python be used thus when WhiteCap and Aeon *already exist for that very reason??*

What I perceive as your fears that SS developers are somehow going to "Aeonize" G-Force seem iMO unfounded.

If any of what I've said here is missing any important details or found wanting in accuracy, please correct me.

MY latest vote change on the Toolbar: Neutral/Abstain.

[andy55]

As m2c pointed out, Python would initially only be used for the UI layer in G-Force. It would also allow us to add additional drawing layers on top of it if we chose (or perhaps meta configs that define surfaces for G-Force FlowFields and WaveShapes to act upon). That said, our focus is on Aeon 2.5, release of all the other titles (including G-Force with our pyton based GUI layer), and then our current new vis under development (in that order).

[JayPro]

@Andy

I like how you snuck that last thing in re this new project.

Have I missed an official announcement on this? When does beta testing start? Will it be usable on my machine with it first gets released?........... LOL

Seriously, if the plan is to go Python with this, I'm gonna hafta learn the basics of the program...especially now with this adding of drawing layers you speak of.

I can just imagine a python-constructed 3D surface/object such as found in a WhiteCap background and somehow being able to superimpose a GF flowfield on it....which an ancient, dog-eared veteran config maker like me should still be able to use VectorC for...I hope.

Oh, so , *so* many questions now do leaps and bounds inside my head about this.

[jerohm]

RE: "hafta learn the basics of the program"
... that won't kill ya ... or will it???

the real question is why on earth anyone would develop a language, i.e., Python (or any language), and go out of their way to ignore perfectly good, tried and true (to say nothing about familiar), 'C' language syntax, while offering nothing advantageous by this decision (I think I read that in a piece of someone's documentation once ). It is the height of arrogance... Dennis is surely spinning in his grave.


("initially" is scary a word)

[BTT]

That said, our focus is on Aeon 2.5, release of all the other titles (including G-Force with our pyton based GUI layer), and then our current new vis under development (in that order).

So not much point in having a poll or asking for peoples opinions then.


Regards BTT

[BTT]

Hello JayPro

Hey everyone,

First off, many thanks to all the moderators for doing their best to keep the peace in the face of less than impressive responsiveness here at SoundSpectrum.

The short version is that we're working hard on the engineering side to get things out the door, and we're working on making improvements on the support side. On behalf of SoundSpectrum I offer my humblest apologies for any lack of support responses we owe people. This is not our norm, nor is it acceptable. I confess that I often hide from my inbox daily so that I can concentrate on getting out releases out the door and our R&D project codenamed 'replicant' in the works. I've been dealing with a couple major personal problems, which hasn't helped any of us, so please give us a couple more weeks to get G-Force and WhiteCap out the door and hopefully everyone will enjoy all the work we've been putting in over here. Look for Aeon 2.5 in a week.

Sincerely,
Andy O'Meara
CTO, SoundSpectrum

http://www.soundspectrum-forums.com/vie ... 8&start=30


Regards BTT

[andy55]

That said, our focus is on Aeon 2.5, release of all the other titles (including G-Force with our pyton based GUI layer), and then our current new vis under development (in that order).

So not much point in having a poll or asking for peoples opinions then.


Regards BTT

Well, there's things we're focused on in the next couple weeks (such as the things I listed), and then there's next moves with G-Force. I thought it would be fun, helpful, and exploratory to assemble what you and other SoundSpectrum users thought of the kind of high-level engineering decisions are to be made here at SoundSpectrum. If users want us to dumb stuff down and treat the userbase like a bluechip company would (i.e. not tell users anything about product decisions or incorporate user feedback at all), then we can do that.

To clear up issues in this thread:

- "Python in G-Force" just means that we'd bring our GUI to G-Force (similar to Aeon). it does NOT mean that any of the G-Force guts or ways config types are defined will change. if you think that i'd choose to regut and redo all of G-Force innards for nil benefit rather than work on current and upcoming projects (Replicant and Flux), then you need to get to know me better.

- The current G-Force Toolbar is expensive (in an engineering sense) for SoundSpectrum to maintain, but we know it offers value to users. But how much? If an Aeon-style GUI in GF supplants the functionality of the GF Toolbar, then does anyone really lose from such a switch? This question is why this thread is here.

[JayPro]

@Andy and your clarifications:

Well spoken. Now my initial vote to ditch the Toolbar can be recast with confidence.

As one who remembers the days in late '99 when your G-Force and WhiteCap page consisted of a simple white frame with a pithy product descriptions and simple download option (i.e. *well before* the mint-green Andy55 page...and yes, I'm severely dating myself), I have been honored to see how ten years of dedication and hard work on your part under extreme duress has brought us to this moment.

Now, we're talking about well-known musicians and artists and--just today--the Olympic Games using SS for the closing ceremonies. This can only reap results of great mutual benefit that will grow with time. If not for the poor condition of this economy and the attendant scarcity of job opportunities in many sectors (i.e. have programmers been affected?), I wonder how much farther we all could have gone.

It does my heart good to hear of more pieces falling into place...and in more than one respect.

[jerohm]

First off, I want you to know how much I appreciate your efforts in creating GF. After working on OS/Compiler internals for years, this is really the only application (other than coolpro), I ever developed an affinity towards... mostly because it allows me to help others visualize what has been running around in my head from the get go... before GF, people only really cared if my work met their objective... like I could care less...

Let there be no misunderstanding, I will MISS the toolbar. I use it on a daily basis. Do I NEED it?? That is a harder question to answer. I also understand your motivation to normalize the SS product line. It amazes me that you still have the wherewithal to support so many different permutation... I wouldn't. I would HOPE you will continue to support the product; Flowfields is what make it special. I make fun of Objects a lot because, I think people spend a lot of time trying to shoehorn a valid concept into irrelevant scenarios. Objects enforce order into potentially chaotic environments... but that is really only valuable when trying to rein in cowboy programming staffs (greater than a couple people). There is a lot of overhead that makes for some pretty fugly code... or at least a lot of overhead that has absolutely nothing to do with the problem you are trying to get done. Perl may make for some pretty unreadable code, but at least you can get the job done in the fewest number of lines. It was the first language I was ever exposed to that mimicked/supported the way I address problems... but that is another topic.

I wish you would solicited more suggestions on the potential evolution of GF. You did a remarkable job out of the gate; there are certain issues that only become apparent with time. Slideshowing scripts is one example. I think writing scripts is more within the range of everybody's ability, and would open up a new level of program interaction (which is the only reason I hang around)... Starting scripts manually have a use... but randomly, automatic is the next level.

Selfishly, I could suggest several, easy(?) to implement, Config language enhancements along the same lines as 'select()' and 'choice()', but I am willing to accept baby steps.

Changing the UI helps YOU from a support standpoint, but doesn't really enhance the product from the user's experience.
- jrm