sonar5pe or cubase sx3 which and why?

[advaya]

Oh no! The VST implementation debate all over again!

For what it's worth, the VST wrapper in Sonar isn't as cumbersome or half-baked as some would have use believe. But having said that, I do think that Cakewalk has a long way to go in that regard.

I guess the thing I like most about Cubase is that I don't acutally have to 'do' anything (asside from install the plugin) to have access to it inside the sequencer. And I really appreciate the fact that I can organise all my plugins in any directory structure of my choosing, and that organisation-scheme will reflect automatically within Cubase.

I do like that little program you wrote for the organisation of plugins within Sonar whyterabbyt. But in the end, I saw it as just another step I needed to perform to bring things up to 'ground-zero' ...

Just my two-cents.

[grymmjack]

What exactly does that have to do with your own claims regarding 'bloat' et.c.

Nothing if read out of intended context. The way in which I replied was from the top down without inserting tons of quotes everywhere, I chose to do it at the very top, and then refer to each one down the line. That part was regarding the "cleaner and better sound". Since there was some confusion I have chosen the quote every bit in isolation method this go around.

As for bloat, the VST adapter is bloated because of the way it muddies things up with the registration/system level emulation of directx adpated VST->DX/VSTi->DXi's.

Again out of context. The bloat part is the VST wrapper.

That's far from the common meaning of 'bloated' regarding software.

Really? What is the "common meaning of 'bloated' regarding software" ?

It's just one more stupid hoop I have to jump through to take advantage of the excellent (many free) VST offerings available, and it annoys me to no end for I do not have to do this in other smaller hosts with less commercial backing. Yet the small-guys have much better ways to go about doing the same thing.

And what, exactly, do you have to do? Wait while Sonar boots up and does a scan of some folders. That differs from any other application how exactly? Oh I see. You can run the interface separately, and you can change some parameters. If you want.

Some 'stupid hoop'.

Well, FLstudio handles it in a more elegant fashion. I dont need to scan EVERY time on startup. It builds it's info once, keeps it until /I/ decide to change it, and lets me pick which I want to bother with. FLstudio has nowhere near the commercial successful legacy that cakewalk does (but that's changing), and it blows the doors off of cakewalk in regards to plug-in integration. It does DXi, DX, VST, VSTi, and Rewire. And it does so very well. It doesn't waste my time scanning every startup, unless I tell FLstudio "scan" once the app has launched. Cubase is the same way unless it detects a change in the VST folders configured, it scans once and only once. Then I can pick from a list just like FLstudio. Cubase even lets me toggle DX/DXi's just like FLstudio.

But still, I could go with the adapter and the hoop that comes with it as well, if it worked properly, but it doesn't work as well as the one offered natively in cubase.

Of the five or six hundred VST plugins Ive had installed, from freeware to SE plugins to high-end commercial stuff, the only ones which have ever been problematic have been Steinbergs. They seem to make them that way on purpose.

Do you have any proof of this? Steinberg plugs work just fine for me in FLstudio and T2. Hrmm.. Damn man 500-600 plugins? WTF do you do with all those Seriously I cannot even imagine how complicated it must be to deal with that much stuff. You don't use them all of course right? Good lord...

It's a huge frustration and adds to the complexity that we deal with all the time fighting with the machine instead of making music with it.

I feel you are grossly over-exaggerating here.

You are entitled to feel that way

A better solution would be one that didn't require a system-level modification just to conform to the existing DirectX "fit" inside the Sonar programming.

Its not any kind of 'system level modification' at all.

Registry modifications are required to register a directx plugin if I am not mistaken? That seems like a system-level modification to me. And it's one that effects the entire system no?

Something internal to sonar itself, like FLstudio with it's excellent wrapper, would be much better IMO, where we would not have to do anything besides point to a directory containing our plugs (like nearly every other app with VST support) and then let the app recursively scan and we pick from the "all systems go" list.

The wrapper is internal to Sonar itself, and you do not have to do anything besides point to any number of directories containing your plugs and then let it scan.

Not from what I know of. The translated VST stuff that is adapted to DX and is interpreted by sonars DX handling bits as such and not as native VST. It's still using only DX and no native VST code right? If it wasn't then why would they need an adapter to begin with?

As it stands, we have to run an external adapter.

No you do not. The GUI may be run externally, or it may run automatically.

It is still external to the cakewalk application itself bro.

What bothers me more is that as a side-effect I have no way to disable the presence of an adapted plugin within other direct-x aware apps -- for example I do not want soundforge scanning and detecting certain plug-ins that I don't use inside of soundforge, etc. And I don't want to have to open the adapter and disable it before launching soundforge..

And you do have a way of disabling the presence of a VST plugin in other VST-aware applications than Cubase, do you? Or is that just a red herring.

Yes. In FLstudio and T2 both. I can disable them or exclude them. Same with the latest incarnation of Soundforge.

Lackluster is when the WDM kernel streaming mode performs better than the ASIO mode even though my card has native ASIO support which is lower latency. Why is this?

I have no idea. ASIO performance has been better on both of the soundcards I have used.

I /wish/ that such was the case for me too. I honestly LOVED pro audio 9. Of course back then I wasn't concerned about all this fancy crap, only interested in making music and recordings.

I could not sort it out. I honestly change nothing on the card or in its settings, open cubase, and everything works fine. To me that experience is exactly lackluster; it works -- sorta.. mediocre performance. The ASIO mode in cubase works better for me on my system. Great performance.

Hmmm, I think I was right. 'Total fallacy' and 'Completely circumstantial' were indeed appropriate to your own post as well.

Fact from trial and error and experimentation is not fallacy. I never said "cubase sounds better" I said "my system works better under cubase". Which fallacy is that? Circumstantial based on my system/hardware, perhaps. What I was refering to was his statement of "sounds better".

*sigh*... Anyway bro, we both have better things to do than bicker here. The bottom line is that I have plainly said sonar rocks in it's own way, and so does cubase.

[kp]

Very quick reply to a couple of points.

Well, FLstudio handles it in a more elegant fashion. I dont need to scan EVERY time on startup. It builds it's info once,
keeps it until /I/ decide to change it, and lets me pick which I want to bother with.

That's exactly how SONAR works - in SONAR <5, you ran the Adapter when *you* wanted to. Just like in FL. In SONAR 5, you can configure it to run automatically every time SONAR starts (and it's very quick if nothing's been changed in the VST directories) or run it manually. You can even run it while SONAR is running and have it pick up new plug-ins without having to restart SONAR (you can also enable and disable DirectX plug-ins in the same way on the fly, which is incidentally far more useful than it sounds).

Not from what I know of. The translated VST stuff that is adapted to DX and is interpreted by sonars DX handling bits as such and not as native VST. It's still using only DX and no native VST code right? If it wasn't then why would they need an adapter to begin with?

Define "native" VST. I think you'll find that, for example, all Sony apps that support VST have a dll that provides an interface from the app to the plug-in. Is that "native" or not? It's purely because Cakewalk has always used a separate executable to manage the VSTs that it's been labelled "adapted". That was probably a mistake they made way back whenever, and if they'd hidden the "adapter" from the word go, the whole issue would never have arisen (I'm not touching on missing functionality such as MIDI loopback; even a "native" VST host doesn't have to support every VST call, y'know...).

I could not sort it out. I honestly change nothing on the card or in its settings, open cubase, and everything works fine. To me that experience is exactly lackluster; it works -- sorta.. mediocre performance. The ASIO mode in cubase works better for me on my system. Great performance.

Can you define "mediocre performance"? Worse sound, higher CPU reading, worse latency (for the same setting)?

[whyterabbyt]

Nothing if read out of intended context.
The way in which I replied was from the top down without inserting tons of quotes everywhere, I chose to do it at the very top, and then refer to each one down the line. That part was regarding the "cleaner and better sound". Since there was some confusion I have chosen the quote every bit in isolation method this go around.

My question had nothing to do with 'cleaner and better sound', and since that is the case, referring to it repeatedly it has nothing to do with the context I initiated. It is you who are taking things out of context.

Again out of context. The bloat part is the VST wrapper.

The VST wrapper is what I am referring to. It is the context.

Really? What is the "common meaning of 'bloated' regarding software" ?

Generally alluding to excess code, and being overladen with unecessary features.

[

Well, FLstudio handles it in a more elegant fashion. I dont need to scan EVERY time on startup.[/quote]

You don't need to do that in Sonar either.

It builds it's info once, keeps it until /I/ decide to change it, and lets me pick which I want to bother with.

Just like you can do in Sonar.

FLstudio has nowhere near the commercial successful legacy that cakewalk does (but that's changing), and it blows the doors off of cakewalk in regards to plug-in integration. It does DXi, DX, VST, VSTi, and Rewire.

...just like Sonar. Hardly 'blowing the doors off'.


And it does so very well.

It doesn't waste my time scanning every startup, unless I tell FLstudio "scan" once the app has launched.

Neither does Sonar. You are labouring under an awful lot of misapprehensions here.

Do you have any proof of this?

The plugins which have consistently been reported as problematic with Sonar have been Steinberg plugins. Search here at KVR, or at the Sonar forums.

Steinberg plugs work just fine for me in FLstudio and T2.

Hrmm.. Damn man 500-600 plugins? WTF do you do with all those

I said that was the number I have had installed. Not that I have installed. Up until approximately 18 months ago I tested every free plugin or plugin demo thatI could get my hands on.

Seriously I cannot even imagine how complicated it must be to deal with that much stuff. You don't use them all of course right? Good lord...

What would be complicated about it?

Registry modifications are required to register a directx plugin if I am not mistaken? That seems like a system-level modification to me. And it's one that effects the entire system no?

If it 'sounds' like a system-level modification to you, then you have a very strange concept of 'system-level modification'. Reordering your Start menu modifies registry entries. In most applications, opening a document modifies registry entries. Installing software modifies registry entries. Changing preferences in Explorer modifies registry entries.
Unless you have some argument that adding a few pointers to some .dll files is a 'different' kind of registry change.

Not from what I know of. The translated VST stuff that is adapted to DX and is interpreted by sonars DX handling bits as such and not as native VST. It's still using only DX and no native VST code right? If it wasn't then why would they need an adapter to begin with?

If it was using no native VST code it wouldnt be able to handle VSTs at all, would it?

It is still external to the cakewalk application itself bro.

What is? The wrapper, or the GUI which makes the registry entries? They are different.

Yes. In FLstudio and T2 both. I can disable them or exclude them. Same with the latest incarnation of Soundforge.

No, thats not what I asked. You stated that the wrapper meant that you could not disable wrapped plugins in other applications. You are now saying that those other applications have plugin management for VSTs, and that you can. You are being inconsistent. If, as you claim, it is the case that they cannot manage other plugins, then it is not an issue to do with Sonar, or the VST-DX wrapper at all.

[grymmjack]

Very quick reply to a couple of points.

Well, FLstudio handles it in a more elegant fashion. I dont need to scan EVERY time on startup. It builds it's info once,
keeps it until /I/ decide to change it, and lets me pick which I want to bother with.

That's exactly how SONAR works - in SONAR <5, you ran the Adapter when *you* wanted to. Just like in FL. In SONAR 5, you can configure it to run automatically every time SONAR starts (and it's very quick if nothing's been changed in the VST directories) or run it manually. You can even run it while SONAR is running and have it pick up new plug-ins without having to restart SONAR (you can also enable and disable DirectX plug-ins in the same way on the fly, which is incidentally far more useful than it sounds).

The ability to run it and have it refresh without rescanning is cool. However, the point was it's more work for us to bother with an adapter when other hosts dont require one at all. Yes I guess the fact that it's an after-the-fact-oh-yea-lets-buy-something-that-already-exists sort of thing it is more apt to recieve attention than not. The "just point it at a directory and let it go to work" way it is in other hosts is how it /should/ be in sonar itself.

What excuse is there for it not being like that?

Cakewalk bought the rights to the vst adapter correct? Or just distribution rights? Hence it is not integrated directly into cakewalk but only a side-effect of the way that directx works is it hooking "into" sonar? Confusing yea? That's why I avoid it... How do you disable the plugins inside of sonar? I have never seen that ability. I thought you had to launch the adapter then do configuring there, and not INSIDE sonar?

Not from what I know of. The translated VST stuff that is adapted to DX and is interpreted by sonars DX handling bits as such and not as native VST. It's still using only DX and no native VST code right? If it wasn't then why would they need an adapter to begin with?

Define "native" VST. I think you'll find that, for example, all Sony apps that support VST have a dll that provides an interface from the app to the plug-in. Is that "native" or not? It's purely because Cakewalk has always used a separate executable to manage the VSTs that it's been labelled "adapted". That was probably a mistake they made way back whenever, and if they'd hidden the "adapter" from the word go, the whole issue would never have arisen (I'm not touching on missing functionality such as MIDI loopback; even a "native" VST host doesn't have to support every VST call, y'know...).

I say native in that it actually does it's own integration with the VST SDK stuff I guess? Like not relying on a 3rd party, external programmer who rolled an adapter, etc. Now we are getting to the meat and this is good. You are definitely right they all have some way to hook in, my complaint is the way in which the hook works in sonar with the adapter. You are definitely right if they hid it it would be a non-issue, atleast until a plug-in failed to work as it did in another host (another point here). The cubase VST implementation is the most robust for obvious reasons. For example in groove agent it can output the actual MIDI notes into a track in cubase. Whether or not this is part of the actual SDK, or a late change as mentioned by rabbyt, I know not. What I do know is that it works as it should in cubase. so..

I could not sort it out. I honestly change nothing on the card or in its settings, open cubase, and everything works fine. To me that experience is exactly lackluster; it works -- sorta.. mediocre performance. The ASIO mode in cubase works better for me on my system. Great performance.

Can you define "mediocre performance"? Worse sound, higher CPU reading, worse latency (for the same setting)?

Definitely. Higher CPU reading, higher latency, and for the same settings. 16bit, 44.1khz same as cubase.

Believe me I tried to figure it out but why bother after a while you just give up and use what works the best for your equipment.

[Meffy]

Confusing yea?

Is it? The rest of us don't seem to be having too much trouble. To me at least the VST adapter is about as confusing as an about box, and no more effort to deal with.

I think most of your objections are based on misunderstandings about how Sonar works. I have just a shallow understanding of how Cubase works, which is why I don't post criticisms of how it works.

[headquest]

I agree with Meffy's point (as usual!). The VST adapter in Sonar 5 is not intrusive to me at all. It does not (noticeably) run when I start up Sonar unless it automatically detects that I have added a new VST instrument or effect to the folder (i.e. one that it did not previously scan). If it does detect something new an information box simply lists all the VSTs it has spotted to inform me that they are now available. I can't see how this could possibly be a problem?

To compare with some other sequencers I use or have used, Ableton does a full VST scan upon startup. It therefore takes longer to open as a program (again though, not exactly a big deal

grymmjack - you praised Tracktion 2 earlier in the thread. I don't know how familiar you have yet become with Tracktion (I have been a registered user for around three years now), but you will find that it, too, does a full VST scan when you open it up... unless (as with Sonar) you delve into the settings and tell it not to. Once again, you will see all the VSTs listed as it does its scan, and it takes considerably longer to do this than Sonar, in spite of the wrapper.

I think that you are making a big deal about the Sonar wrapper, and from your comments I can only assume you are talking about some previous version of the software, as the current version is not probalatic at all in this respect.

There ARE issues and problems with Sonar - as with all software - but the VST wrapper is not really one of them.

[grymmjack]

Do you have any proof of this?

The plugins which have consistently been reported as problematic with Sonar have been Steinberg plugins. Search here at KVR, or at the Sonar forums.

So what does that say about the quality of the wrapper implementation? If the plugs work ok in other hosts without the wrapper?

Hrmm.. Damn man 500-600 plugins? WTF do you do with all those

I said that was the number I have had installed. Not that I have installed. Up until approximately 18 months ago I tested every free plugin or plugin demo thatI could get my hands on.

You have a lot of free time eh?

Seriously I cannot even imagine how complicated it must be to deal with that much stuff. You don't use them all of course right? Good lord...

What would be complicated about it?

500-600? Well picking which to use for starters. Heh.

Registry modifications are required to register a directx plugin if I am not mistaken? That seems like a system-level modification to me. And it's one that effects the entire system no?

If it 'sounds' like a system-level modification to you, then you have a very strange concept of 'system-level modification'. Reordering your Start menu modifies registry entries. In most applications, opening a document modifies registry entries. Installing software modifies registry entries. Changing preferences in Explorer modifies registry entries.
Unless you have some argument that adding a few pointers to some .dll files is a 'different' kind of registry change.

I like a clean system with no needless stuff hanging about in the registry Sure there are lots of things outside of the audio domain that modify things, what we are talking about here is Sonar. Stick to the topic eh? Other hosts don't do this, because they dont need to.

Not from what I know of. The translated VST stuff that is adapted to DX and is interpreted by sonars DX handling bits as such and not as native VST. It's still using only DX and no native VST code right? If it wasn't then why would they need an adapter to begin with?

If it was using no native VST code it wouldnt be able to handle VSTs at all, would it?

The code isn't cakewalks though, which is the point.

It is still external to the cakewalk application itself bro.

What is? The wrapper, or the GUI which makes the registry entries? They are different.

The DX adapter isn't the same as the wrapper? Unless something has changed in v5, the adapter was an external app from sonar itself.

Yes. In FLstudio and T2 both. I can disable them or exclude them. Same with the latest incarnation of Soundforge.

No, thats not what I asked. You stated that the wrapper meant that you could not disable wrapped plugins in other applications. You are now saying that those other applications have plugin management for VSTs, and that you can. You are being inconsistent. If, as you claim, it is the case that they cannot manage other plugins, then it is not an issue to do with Sonar, or the VST-DX wrapper at all.

I am not being inconsistent. I am trying to make sense of this whole mess.

Yes it is what you asked, read your post again. You asked if I could do that in other hosts, or if it was just a red herring. My reply is pointing out that indeed I can do it in other hosts.

Where is the communication breakdown here? Heh.

[grymmjack]

Confusing yea?

Is it? The rest of us don't seem to be having too much trouble. To me at least the VST adapter is about as confusing as an about box, and no more effort to deal with.

I think most of your objections are based on misunderstandings about how Sonar works. I have just a shallow understanding of how Cubase works, which is why I don't post criticisms of how it works.

You are kidding right? I know how sonar works, perhaps not v5 but the older ones for sure. Nothing is hidden in sonar, it's all right there. It's the point of "ADAPTING" that is annoying. Other hosts dont need this.

[grymmjack]

grymmjack - you praised Tracktion 2 earlier in the thread. I don't know how familiar you have yet become with Tracktion (I have been a registered user for around three years now), but you will find that it, too, does a full VST scan when you open it up... unless (as with Sonar) you delve into the settings and tell it not to. Once again, you will see all the VSTs listed as it does its scan, and it takes considerably longer to do this than Sonar, in spite of the wrapper.

I think that you are making a big deal about the Sonar wrapper, and from your comments I can only assume you are talking about some previous version of the software, as the current version is not probalatic at all in this respect.

Perhaps I am talking about a previous version... I certainly hope it would have improved. I stopped upgrading sonar when cubase sx came out. So I am probably out of date. I dont have the money for the new stuff anymore.

[bduffy]

Hey Grymmjack: you're going to find that plenty of us have had hundreds of VST's go in and out of our folders. I have 544 dll's in my VST folder right now. No big deal(that reminds me; I do have too many demos installed...). Some of us like having tons of options, as is our right in this market-driven world. You can't give someone a hard time for the way they like to work, that's just unfair, IMHO.

And as a user of SX and Sonar, I can tell you the Adapter does not do a scan every time; Sonar still opens faster than a word processor, and that is one area where it kicks the living hell out of Cubase; it drives me nuts having to scan and load each and every possible plugin and codec each and every time! Totally embarassing! Steinberg has to fix that, soon.

That being said, I don't like the interface at all for the VST-DX Adapter, total PITA. Anyway, I don't think it's worth getting in fights over, especially if you haven't tried the latest version. There are more fundamental differences between the two apps that would make more interesting, less adversarial conversation, no?

[whyterabbyt]

So what does that say about the quality of the wrapper implementation? If the plugs work ok in other hosts without the wrapper?

It says that your naive if you dont think other hosts have had to adapt their version of host-side VST handling....

You have a lot of free time eh?

Are you having difficulty with past tense versus present?

500-600? Well picking which to use for starters. Heh.

I can manage fine.

I like a clean system with no needless stuff hanging about in the registry Sure there are lots of things outside of the audio domain that modify things, what we are talking about here is Sonar. Stick to the topic eh?

You were trying to imply that registry changes were 'system level modifiucations' which they are not. You try sticking to the topic, huh?

Other hosts don't do this, because they dont need to.

Sonar doesn't 'do' this. Its how DX plugins are implemented. It something Sonar uses.
And Cubase. And Soundforge. And FL. And absolutely anything else which uses DirectX plugins, audio domain or not.

The code isn't cakewalks though, which is the point.

Which code isnt Cakewalk's? The VST handling code within the wrapper is

The DX adapter isn't the same as the wrapper?

ARe you delibee=rately playing dumb?. The GUI is not the wrapper.

Unless something has changed in v5, the adapter was an external app from sonar itself.

Yes it has. But the GUI was always separate from the wrapper anyway.

I am not being inconsistent. I am trying to make sense of this whole mess.

Yes it is what you asked, read your post again. You asked if I could do that in other hosts, or if it was just a red herring. My reply is pointing out that indeed I can do it in other hosts.

Then if you can do it, why did you say it was a problem that you cannot do it? Its your mess that makes it inconsistent.

Where is the communication breakdown here? Heh.

Your inconsistency:

What bothers me more is that as a side-effect I have no way to disable the presence of an adapted plugin within other direct-x aware apps -- for example I do not want soundforge scanning and detecting certain plug-ins that I don't use inside of soundforge, etc.

versus

Yes. In FLstudio and T2 both. I can disable them or exclude them. Same with the latest incarnation of Soundforge

[grymmjack]

Hey Grymmjack: you're going to find that plenty of us have had hundreds of VST's go in and out of our folders. I have 544 dll's in my VST folder right now. No big deal(that reminds me; I do have too many demos installed...). Some of us like having tons of options, as is our right in this market-driven world. You can't give someone a hard time for the way they like to work, that's just unfair, IMHO.

Honestly I wasn't giving him a hard time. Did it seem that way? I was just shocked because of the sheer amount of stuff that 500-600 plugs involves. I mean it's overwhleming /to me/. I wasn't implying that he shouldn't do it or he's a goofball or anything. Did I seriously come off like that? If so (to rabbyt: i apologize if this is how it sounded. I was being sincere about the free time because I would think it would take tons of time to manage all of that stuff and try it out, etc.)... Dudes I am all for trying new shit believe me! I just dont have the time, and I'm in no way trying to say that if you do, you suck or anything. I am envious if anything

And as a user of SX and Sonar, I can tell you the Adapter does not do a scan every time; Sonar still opens faster than a word processor, and that is one area where it kicks the living hell out of Cubase; it drives me nuts having to scan and load each and every possible plugin and codec each and every time! Totally embarassing! Steinberg has to fix that, soon.

Shit, maybe I should try v5. I've been on the fence about it after seeing the movie in CM for V-vocal. I haven't tried sonar since XL and the v2 demo (which I was evaluating but decided not to go for for the VST issues I am mentioning) aside from watching at a distance or researching things from afar I am not an expert. If the VST adapter really works as you guys are saying that rocks many socks and it's freaking light-years better than the old one I had tried out. And yes cubase startup blows chunks. Agreed.

That being said, I don't like the interface at all for the VST-DX Adapter, total PITA. Anyway, I don't think it's worth getting in fights over, especially if you haven't tried the latest version. There are more fundamental differences between the two apps that would make more interesting, less adversarial conversation, no?

I'm not trying to pick fights. If anything I feel as if the fight has been picked with me if there is even a fight to begin with. We are being civil and I am desperately trying to keep things that way but I didn't even consider v5 VST adapter evolving, so yes probably 90% of what you dudes are saying is true and renders all this a waste of time.

[whyterabbyt]

It's the point of "ADAPTING" that is annoying. Other hosts dont need this.

Yes they did. Once upon a time, Acid, CoolEdit et.c. had no VST handling. Thats why there have been at least three companies making wrapper software.

Now, most of them have internalised routines which translate between VST (and possibly DX) calls and their own 'internal' plugin calls. That is what a wrapper does. Logic used one, FL uses one, Orion uses one. All of these apps have their own 'native' plugins, as well as support for more open formats. All of them 'wrap' or 'adapt' external plugin API's to conform to an internal API. Everything gets abstracted to the internal mechanisms of the audfio engine. That abstraction is wrapping or adapting, nothing more or less than that.

[Meffy]

I honestly never had any trouble even when the VST adapter was separate. It was a non-issue for me, and for most users I know. Now it's a complete non-issue, extinct. :-)

Just upgraded to version 5, and that's not one of the things that really knocked my socks off. (A few other features did that.)