PlanetZ forums - scopeusers.com

Years ago my very first impression of pulsar was: the GUI which is neccessary to access the DSP-power of CW's cards interferes with the production platform (e.g. Cubase / Nuendo) and therefore it handicaps the whole system! It does not add extra power - it drains power from the creative standpoint of view. Over the years with different pc-configs OSes and Pulsar/Scope-Versions THIS experience didn't change! And it is getting more and more paradoxical: why do you need better and better Hardware to add the same DSP-card to your system? Because the GUI is growing, adding more and more possibilities to the platform but draining the NATIVE side of the system.
To cut it short: SFP utilizes way to much NATIVE power (e.g. 100% CPU when dragging windows) to 'add' extra DSP-power. You simply can't access the DSP-power adequately. Besides that it stresses core-components of the system like PCI! This strategy doesn't make sense at all!
This is the reason why XTC in theory makes much more sense: it ADDS DSP power and LEAVES the native power for the productive tool (e.g. Cubase / Nuendo). But how to use the realtime-capabilities of the DSPs with XTC? No way!
Did we buy a one-way-ticket? Or do you think CW realizes this (growing) paradoxon?
Please understand my point: I like SFP, I like 'being digital' but if the pill kills the patient you are using the wrong treatment to cure the disease!
CW needs to realize that SFP NEEDS A DIET and they MUST solve the probs described above. If they won't do, NATIVE WILL WIN THE BATTLE and there will be no CW anymore in ~2-3 yrs. I wouldn't appreciate that!

I can sort of understand what you're getting to.. Right, the interface code definitely needs more work, despite its improvements in the recent updates. It seems pretty straight forward to me, even though I don't do much coding, that the interface code is just plain inefficient. Mainly because I've seen dozens upon dozens of programs that handle it much better. But it's getting better. I'll admit that.

And about the GUI mambo jumbo getting in the way of creation.. I'm not sure. For me, sound tweaking never was much easier, as I'm from a background of HW synths. (menus after menu) Perhaps the paradigm is different for VSTi orientated people. But the common denominator for both VSTi and HW synth bunch would probably be the resulting sound quality. I don't go through the hassle of making a Modular patch for one specific sound effect judging from whether the GUI is efficient or not. I want THAT sound, and the only way to get it is to fight with the mind bending GUI. Sometimes the result is worth the cumbersome interface. Same goes with csound or any code-based synth.

But that's an extreme example, I know. While I agree that the current interface isn't being too efficient, if CW does have the resource, I'd put my vote into using it to get cooler sounds and tools. The rest seems less important to me, and that should also simplify the design and make the whole thing slim.

<font size=-1>[ This Message was edited by: kensuguro on 2002-09-19 08:23 ]</font>

And to counter what I just said, having inefficient fancy GUI sometimes does the product justice. I'm thinking of the iMac trend. Ok, obviously the Mac GUI is much, much MUCH more efficient than Pulsar's, but the idea is the same. People just like good looks! Mac OSX looks cool! And so does the computer itself. The image is vital, and I would have to say that Pulsar's fancy GUI does make it more attractive than... say, super collider. (I'm not trying to say that Mac OS is inefficient though, so don't get fired up )

So I can understand that CW goes through the extra hassle to create that sort of "look 'n feel" that attracts users. And certainly, it makes some of the fancy device more "tangible", in a sense. It plays a vital role in making the virtual devices seem more real. So CW chose fanciness over code efficiency. That would seem logical to me. For the time being atleast. They'd have to work with it some time or the other.

<font size=-1>[ This Message was edited by: kensuguro on 2002-09-19 08:33 ]</font>

It always struck me as strange that so much effort has been put into making SFP's interface look "pretty" at the expense of performance. This ties in with the other mystery of exactly where CW's target market lies. I love the innovation CW has brought to the audio world, but I just can't fathom why they've matched such fantastic hardware/software engines with the user interface of a SoundBlaster-class product. It's almost as if they're trying to be all things to everyone, and any well-versed marketeer will tell you that's a dangerous mistake!

I'd be more than happy to trade glossy interfaces for a highly responsive and reliable system, and I know I'm not the only one with this opinion. I just think CW need to get some more focus on who they want to please most and act accordingly.

Before this becomes a 14 page diatribe, I'll close in saying that like Ken, I too come from a HW-only background but I don't see this as an excuse to settle for sloppy software. One of the major reasons many of us are switching to PC and Mac based DAW's is because of the potential computers have in offering user interfaces that are superior to their HW-only counterparts. I hope CW catch on to this before it's too late.

If XTC were more extended -and it's development goes hand in hand w it's user base- it would be much faster. The GUI looks the same, it's just that the surfaces are 'converted' into regular stuff that is as light& fast as the other graphics on our comp's.
Of course, they'd need to make some 'universal dsp plugin host' for the VST host, to be able to run enough plugins -also those without XTC version, like modular, Zarg's, etc. etc.
And of course, there's no more routing in XTC. Has anyone tried sidechains in XTC mode? Guess it should work though.

CW, can we get a GUI-lite?

(I'm speaking from a Windows point of view; don't know about mac)

a graphically 'light' OS would definately be cool! I've discussed this idea earlier on Planetz but can't find the article now..... Anyway I wouldn't mind a graphical interface that uses just the standard Windows interfacing, having non-shaded boxes/windows with old-fashioned straight edges. No background images, no shadows effects, no custom fonts, no special creamware-buttons to close windows, no 'show windows contents while dragging' (hell, even the VU's of the mixers update while dragging the window!!), no nothing; just functionality!
I'm pretty certain that would improve things a lot. using good colour-schemes it can still look pretty attractive without draining CPU.

CW; paleeeeeeeeeeeaaaaaaaaaaaase???

I have to admit that there has to be a way to make the SFP display more efficient.

We have to keep in mind that making a platform specific GUI would be, well, platform specific. This would mean having to recode all plug-ins for each platform(Mac, Win, $YourFavoriteDreamOS).

I'm certain that we're not about to see that.

I guess that we'll just have to hope that someone at CW will have some time to spend optimizing thwe display code.



RedSun .:.

well,if it could be done,i'm not against making the gui lighter,however,i've found the pulsar/sfp environment to be very useful.my backround is in real world studios,so i am very comfortable in the sfp world.i DO however,much mixing in the logic environment,and there is not much reason to be flipping screens.

still, i can run 30 or more tracks and plugs to go with and STILL access sfp(and ahardware) plugs as i wish.i checked the cpu meter in logic and it was not significantly higher with sfp running.maybe this has somethig to do with cubase as well....

I don't really see the problem, SFP seems very light and quick to me, almost as quick as the normal windows gui. Actually it's much better than the old Pulsar software with the all transparancies slowing things down. I'd rather have my software look pretty too if I have to stare at it for hours at a time.

I agree with King of Snake. I only have a 500Mhz PII and I have no problem with the speed of the interface, even when running a medium-sized Cubase project. I love the quality of the interface and much prefer spending time looking at it than most other music software. What's more, PCs are getting more powerful all the time, so I think Creamware should concentrate on the sound quality and getting more 3rd party people on board.

I'm interested to know what kind of video cards the people who report fabulous results are using. I still don't think a DAW should have to rely on a cutting edge video card to achieve accurate representation of its functions. It is afterall, an audio machine!

BTW, my argument isn't based on how SFP behaves when moving windows from one spot to another. This was adequately addressed when CW got rid of transparency in their GUI. Some may see it as demanding too much, but I believe a package of this calibre should be able to at least come close to matching the VU response of a pro mixing desk, for example. So far, SFP pales in comparison.

On 2002-09-19 08:32, kensuguro wrote:
So CW chose fanciness over code efficiency.
<font size=-1>[ This Message was edited by: kensuguro on 2002-09-19 08:33 ]</font>

I agree with you in general - I don't know much about gui coding but why the SFP GUI work slow both on 16MB cards and 64MB ones (read: yesterday's and today's cards)?

I adore SFP's GUI. It's absolutely beautifull.

In XTC mode it's as pretty as in OS mode, but although -as someone mentioned above- SFP GUI goes fast enough, the GUI speed could take too much cpu cycles/priority. I think that's why André Dupke suggested to run SFP in Low Priority mode.

Many cases of clicks or pops could be easily be avoided by ie. removing a mixer device from the screen. Or just take away the VU meters, you'll see how much more VST(i)/audiochannels you can run

I find SFP's GUI way more responsive since for example 2.04, CW has done a real great job. Still it creates obviously more obstacles than native programs. I do understand CW wants as much as possible cross-platform compatibility. The large majority of other programs has managed to deal with it.

I do love my cards and SFP, I'm only trying to make suggestions.

One point from me on pretty GUI's.

I have an OASYS card as well as a couple of Pulsar's. I have no criticisms about the quality of the OASYS but I find myself drawn to my Pulsars in preference to my OASYS every time, because the GUI is so much more intuitive, and yes, I'll admit it, attractive.

It's not just a cosmetic thing, though - I find that Pulsar devices stick in my mind far better than the Oasys one's - having a distinctive GUI for each synth makes it memorable, whereas I can never remember which synth is which in OASYS. Furthermore, the virtual studio concept in Pulsar is so much easier to understand than the Multi's (etc) of Oasys, because it's modelled on a real studio concepts.

My Matrox G550 handles SFP & SX1.03 (& whatever else I happen to be running) without problem - but make sure you're running SX 1.03 as this did fix problems with glitches when switching between applications.

I'm also sure that pretty graphics influence sales. I think that's one reason why (eg) the B4 and the MTRON have done so well - there is a 'wow' factor when you first see it that you don't get with an Oasys synth.

Cheers,
Ben

I too agree that the GUI of SFP rocks. However, I also agree that it would <b>benefit greatly from some hardware acceleration</b>.

Imagine it using your Geforce or other OpenGL card to accelerate the graphics. Hey, even the OSX GUI was really slow when it first came out, but they slowly improved it.

There is a big difference between 3.01, and SFP 3.1 in the GUI, so Creamware does seem to make progress here. I think the biggest difference is they ditched the lovely (but intensive) alpha-blending from 3.01.

Now all we need is <b>hardware acceleration</b>!! Creamware, what do you think?

I agree on accelleration, and, since OpenGL is already multi-platform (both unix and windows) it should be pretty easy to integrate this feature in the graphics librairies they are using!

OSX is Linux based too

Search for "Next"

not exactly, it's FreeBSD based with a Mach kernel, but the Open GL improvement for the Jaguar version is true.
I'm bound to live with it (on the job) from next year on, so for me it's a kind of love-hate relationship

cheers, Tom

On 2002-09-20 12:26, subhuman wrote:
I too agree that the GUI of SFP rocks. However, I also agree that it would <b>benefit greatly from some hardware acceleration</b>.

Imagine it using your Geforce or other OpenGL card to accelerate the graphics. Hey, even the OSX GUI was really slow when it first came out, but they slowly improved it.

There is a big difference between 3.01, and SFP 3.1 in the GUI, so Creamware does seem to make progress here. I think the biggest difference is they ditched the lovely (but intensive) alpha-blending from 3.01.

Now all we need is <b>hardware acceleration</b>!! Creamware, what do you think?

now the windows are spread all over the place and mixed with regular windows i would think that would be very difficult, and directX and openGL must get the power to work from somewhere (your precious CPU cycles and memory bandwith for example).

I would rather live with the "slow" interface that works very well anyday. rather than:

Try using sampler - computer - hard drive SCSI interfaces aRGH SLOW!!!

try even getting all the voices off an FSIR to edit in the computer, edit them and see how they sound..yawn easier to press the tiny yamaha buttons and twiddle the knobs.