"Backwards Compatibility" shouldn't be that important

Hey guys

One of the most used argument against Feature Requests and Suggestions is "they want it to be backwards compatible. In my opinion this is a bad motto for a product that keeps updating. It’s simply not possible to keep all versions backwards compatible, so why bother that much?

I think many feature request aren’t in the current version because of this reason. They tend to add features instead of upodating the existing features. Like the insert slot count. We waited so long, now we finally got 16. But we still got only 8 sends and quick controls. We still got a rather minimalistic Channel EQ. Why not implement the Frequency EQ in the strip? They just added the frequency EQ as a plugin instead of implementing it right.
I know sometimes they add features like a completely new channel strip or vari audio 3. And those aren’t backward compatible. But they surely wait with alot of upgrades because of backward compatibility.

In my opinion they shouldn’t focus a lot on Backwards Compatibility. They should upgrade and make Cubase better as much as possible. I wouldn’t be mad at all if they wait 2 years and release a really big update like other DAWs.

What are your thoughts on this? Is Backwards Compatibility important for you? Do you really use it often? Or do you think the same way as I do?

Greetings :slight_smile:

Backwards compatibility is just the ability to open older projects in the newer Cubase, which Cubase tends to be pretty good at. Yes I know some projects will open in older releases but that’s really a game of luck.

As for enforcing new features such as Frequency replacing Channel Strip EQ, frequency takes a lot more CPU, and there’s lots of hardware out there (Yamaha consoles for instance) which have physical EQs which match the software one in Cubase and Nuendo, what we should have is the option to use Frequency as the default EQ - but making that mandatory would not be welcome for people who have spanked £50K on a console (or the guy who spent £350 on a c121!)

I’d love the channel strip to be completely customisable - if you can replace any (or all) component(s) with a third party one(s).

As for enforcing new features such as Frequency replacing Channel Strip EQ, frequency takes a lot more CPU, and there’s lots of hardware out there (Yamaha consoles for instance) which have physical EQs which match the software one in Cubase and Nuendo, what we should have is the option to use Frequency as the default EQ - but making that mandatory would not be welcome for people who have spanked £50K on a console (or the guy who spent £350 on a c121!)

There are many solutions for this. Frequency or a 3rd party plugin could be optional. So you could change in the settings which EQ you want in your strip.
Or they just implement the frequency to keep it simple. Then the existing controllers could simply use 4 bands instead of 8.
On top of that they could add a shortcut for switching between the first and second 4 bands. So even the guys witch consoles or little controllers like C121 or CMC QC (I own this contoller) could use the frequency EQ.

The same goes with the send effects or quick controlls. The existing controllers simply use 8 parameters. Or more than 8 are optional. It isn’t rocket science :laughing:

I’d love the channel strip to be completely customisable - if you can replace any (or all) component(s) with a third party one(s).

Yeah that would be awesome! :smiley:

This is incorrect, that would be forwards compatibility. Backwards compatibility is older versions of cubase able to open new versions.

This is important for various reasons - some people don’t update unless they absolutely have to. Some people can’t afford to. Some people are running legacy systems for specific tasks or projects, etc, etc. It’s really actually a software and computer ethics thing.

This is important for various reasons - some people don’t update unless they absolutely have to. Some people can’t afford to. Some people are running legacy systems for specific tasks or projects, etc, etc. It’s really actually a software and computer ethics thing.

But do some people really send projects back and forth all day so this is that important? I mean after every release of a new version there is at least some new features which aren’t backward compatible. So people who upgrade and work a lot with artist who don’t use a up to date version can’t use all the new features?

And by the way, Steinberg could add features which are backward compatible. Like 16 sends instead of 8. The person with the newer version has to know that he can use only 8 for older versions to work. The same goes with a new channel eq. Just use 4 bands instead of 8 or what ever. Sometime I think Backwards Compatibility is just an excuse.

Don’t you think it would work with a lot of features which are requested since many years?

Well, I’ve been a software engineer for 35 years and that’s the first time I’ve see “backwards compatibility” to mean that. Maybe it’s German humour?

Well I’ve always taken it to mean the ability to open a project that has been worked on in the new version in the previous version. I think it goes without saying that projects started in Nuendo7 for example are going to be loadable in Nuendo8 - that is forward compatibility.

Right.

There are many people who don’t upgrade their Cubase for a number of reasons - one could be finances, ie some people in some parts of the world might save money for years just to buy - a - version of Cubase, and you wouldn’t want their program to become obsolete to the rest of the world who can afford to upgrade. Other reasons might be, some people need to run and maintain an absolutely stable zero chance of hiccups rig and don’t risk updating for features they don’t need.

The way I’ve always used that phrase, saying “Cubase 10 is backwards compatible” would mean that it can look back and open project files created in older versions of Cubase. This is of course essential.

However, since new versions of software add features and properties that did not exist in older versions, the reverse is always trickier to define. But if its files could be opened in older versions, I would state that as: “C10 creates project files that are backwards compatible”. Not sure if that ever is particularly definable, since what happens to attributes of the project that are specific to features that did not yet exist in the older software? I’m not saying that’s a bad thing. Just hard to define.

Whatever the phrasing, C10 being able to open files from older versions of Cubase is essential. I’m hoping never again to have to go through all my old, unfinished projects and walk them through intermediate Cubase versions to make sure everything is able to be opened in new versions going forward.

Well they have totally fucked up shuttle transport and they don’t give a shit about to fix it or document how it supposed to work. (It was working fine in Cubase 8, but they break it in 8.5 and they still don’t explain the change. So backward comparability is not anything they support.

^ This :exclamation:

What is the issue with the shuttle transport?

It has “random” behaviour when doing transition from one speed to a other. It is the same for both key events and midi events to my conclusion is that it is the shuttle control that has the problem.

Ok, I see.

On my jog wich I use over generic remote. The shuttle is smooth as far as the resolution will take it. But I do use it in not automated flag.
wich ignore the stop message. Might be that it is this message that is messing things up, switching speeds. I do have a vague memory, that I put the non automated flag on, caus there was some change made. It is a long time since I used key command to control shuttle. But im gonna check it out and see if this might be the source to the randome behaviour. Shift+shuttle is steady on my transport

Im not sure if I have tried that. But I will. Tnx!

Did not work either. The problem is not when the shuttle is moving, it is the transitions between speeds. Like from 1/8 to 1/4 etc.

It is the stop message/toggle that is killing the transition. That is quite clear for me, after trying it on key command and midi buttons.
You need an endles rotating controller and use shuttlespeed to run it smooth.

Might have to ask for a pref setting to take off toggle on these fixed speeds. As taking it off totaly, might make someone else go annoyed caus they have to use a other button to stop, insted of toggle on/off. There is always some strange reasond why things change.

I have tried to send new shuttle speeds without any “off”, it does not help either.

It only works on command suttlespeed not the fixed shuttlespeeds. If you have a hardware jog, you will get it working. As I said. Toggle is your issue. If you want to know what the fault/change is.

Toggle is toggle. The non automate im talking about, just prevents a stop message from the jog, to stop transport so you can play at a steady speed, instead of having to constantly change speed to keep transport going. Toggle on the other hand, is just that. The shuttlespeed has no toggle compard to the fixed speeds wich all have toggle.