The realities of being a coder: a story of enduring sympathy and hostility simultaneously

Steinberg Lounge
1

I am sorry for being a little uncomfortable these days in the forum, however, I am just trying to place criticism where it is needed to see the product being made better for everybody.

I actually love Cubase and want it to become truly reliable and worthy of the “Pro” tag. And after a couple of years spent with it, having done multiple upgrades and updates, I feel like there are some serious issues both with the software and the way it is being handled.

I own literally 12 different DAWs and could work with any, but Cubase has the most comfortable UI and ideal feature set for composing soundtracks. It is my DAW of choice, but right now, I just can’t use it. Not in the state it is in and has been released for years now.

To give you a recent example, I mean - I get it. There are bugs that are super specific, under very rare circumstances hard to reproduce. Stuff that only pops up for very unlucky people. But from this update: “Sampler Tracks were referencing to the wrong audio files.” - really? That would be one issue that should have never made it into a release version. And it is just an example.

Version 11 has been released during the availability of MacOS Big Sur. I know, I know. Apple constantly changes and breaks things, and it is both difficult and annoying to keep up with them. But Cubase itself was already compatible - the fact that Groove Agent and Retrologue were not was visible as clear as daylight. It’s true that it is both unprofessional on my side to upgrade to the latest OS when it comes out and not wait for companies like Steinberg to confirm compatibility, but did such a visible bug really have to make it into a final release? That completely ruined my first impression. Aside from the fact that the CPU overload warning still alerts by default…

2

We should not forget that it IS possible to stick to the release cycles and at the same time generate a substantial stability/reliability update.
I have never had the chance to get into Steinberg Development, but - as a substantial experience in that area I can share the following: Any software development team that is not regularily working systematically on improvement, esp. in the quality assurance aspect, has more than substantial room for improvement. Sometimes coupled to a significant investment (in conceptual, organisational and technical infrastructure), which always returns positively.

3

I know nothing about coding I’m curious how do you know if a coder is working at the speed they should or being slow? This is no judgement in steinberg whatsoever just curious as how it works in the coding world compared say to my Industry.

For example I know some tv editors who purposely edit slower just so they don’t finish cutting the show quicker and lose out on additional payment. If they finished the show quicker they would get paid less as they get paid for the time it takes to complete a project. You have fast editors and slow editors and yet they tend to get paid a similar rate. So can cause issues. Wondered how it worked in the coding world.

4

You know if someone is pulling their weight or not. It’s not really judged by the output of work per se (As bugs and testing can drastically extend times), but their willingness and ability to hit targets without reeling off a list of excuses is most paramount.

Having people who are easy to work with is as crucial as their ability to code. And therefore, if you have a team puling in the same direction, even working at different speeds it’s more progressive than having many fast, skilled coders who are going off down their own routes. Basically, the system that you work within is key to highlighting areas of concern.

From an individual perspective, There’s many times where a planned weeks work turns into months, due to bugs that are introduced based on the changes you’ve implemented. But with revision control, and good project management, in my experience, this is fed back to management who can make a decision on which way to go. Sometimes that can mean putting months of work on the back burner for the greater good,

In fact, many times i’ve been ‘put back’ to finish work that felt like we dropped 2 months ago, open it all up, and the source file last change date is 8+ months. It’s really quite scary at times how quick things move in development.

When you add in the debug and testing periods, It’s just not so obvious to view progress as it is someone building a house whereby you’re and continually laying bricks and can take a view on the progress by how it’s taking the form of a house. It’s the smaller less obvious tasks that can take the most time.

i.e. what most people don’t realise in development is that creating a routine to carry out a function is the relatively easy part. Getting that to fit into the existing framework of the software, creating it’s interface, then debugging it from a users and useability perspective takes far more time than applying the actual task itself.

This is why a DAW like Reaper can be developed and updated so fast with a small team, they don’t put so much weight on interface, and managing the DAW as a suite like Cubase.

As such the developers are able to create code for ‘actions’, and end-users can apply these actions and add to their interface as they please. It’s very modular, whereas Cubase is more integrated - and that does add additional overhead in development.

1 Like
5

I wonder if Steinberg could do it like some Linux distributions and offer a Long Term Support (LTS) version of Cubase, something everybody can point at for people who need Cubase to earn their income. Like, all eyes on creating a rock solid, super stable, everything works as intended version. Then offer support for this version for 3 years, backporting any bugfixes from future releases, where applicable. And the normal release would put new features into people’s hands as usual. Just hopefully being developed and tested more carefully. And I am still for doing extensive public betas. People should be able to test and use the next version months before release, if they own the latest stable version. If bug reports are taken serious and properly fixed before the release, it would be a win-win for everyone.

1 Like
6

Fascinating. Thanks. So maybe steinberg could follow a more modular route from here on out. An example being for those that want session view, add it via Groove Agent full version (an idea @vncvr had)

7

Totally agree with this post. Genuinely feel like 5.5 was the last rock solid release. Have had loading, hanging, crashing, UI issues, cpu spikes, pops and cracks and other problems of some nature on virtually every release since. 8.2 wasn’t bad!
I downloaded 11.1 today to check it out and low and behold it’s messing up something with the elicencer :smiley: so I can’t open 10.5 anymore! A scroll through the forums says to rename an extension somewhere in program files! Temporary fix but didn’t last long for me.
Steinberg simply don’t release versions that are ready.
Their “support” is genuinely appalling. 2 months for a ticket? Of course they’re overwhelmed, they’re #1 understaffed and #2 they sell broken software.
Good on you folks that it works for though :+1:
Demoing Studio One 5 and haven’t had any problems so far, it’s good . Trying to convince myself to finally jump ship, we’ll see :laughing:

8

Well,

first of all: The delivery rate of a development team is not determined by the speed of the individual programmer. We can assume that in a professional team (which e.g. Steinberg for sure has) there are programmers with excellent skills.

Second: It was already in the 1980s when studies proved that the difference in speed between individual programmers is usually a factor of 10 (!) – so not just “a little bit”, but a FACTOR. Well – this might be true for other industries as well – but here comes the surprising finding: There is a strong correlation between speed and bug probability – in other words: The programmers that were faster – times 10 (!) – also were the ones who made less mistakes, created less bugs. Please note: This is not a statement about individual programmers, but a statistical finding.

Having said all that: No, I don’t think that there are “bad programmers” at work – not at all. Speed in this industry is so much determined by the “legacy” (the product that already exists and its age – including the loss of knowledge about what already exisits) and the processes. Focus is key, feature creep is a problem. Conceptual weaknesses are (complex systems require modelling which is an art in itself) as well. And – last but not least: The testing – especially regression testing including test automation.

There is much more to all that .

I have studied, explored and experienced so much in that area that I can hardly tell. Complexity is often overwhelming and I have a high respect for all the guys who perform the “programming job” and all the disciplines around it. Optimizing things is a great challenge. But there is always room for it.

image001.jpg

9

This is sort of off topic and way beyond our understanding to even bother speculating on or analyzing.

Cubase is significantly more complex than any of the DAWs currently on market. For example, other DAWs don’t have a Project Logical Editor, which needs to communicate to various parts of the program, in which changing one thing, could break PLE.

Any small feature add, that appears small to us, could require months of planning, coding, implementing, and testing. And it might not be discovered until months after completion that it broke something else in the program no one noticed… And then months more will be spent re-coding what was already coded + some more code to avoid breaking the other thing.

10

Something I always feel gets lost in discussions about updates: I fully understand that some bugs can be very complex to fix and it can take some time. Other bugs might be quick fixes and done in minutes. What I’d would like to see, and I’m sure many with me, is more frequent updates. No need to wait until all (or most) bugs are fixed; let the complex ones take their time and in the meantime get fixes out for other stuff. Waiting months for a fix for a bug that broke your workflow will only create unhappy customers.

11

believe it or not, that’s probably what they’re already doing.

But even if not, what you describe has its own risk of complexity. In the end, it may be better to compile a number of changes together

12

Perhaps. But looking for example at the issue that people are having with the zoom being backwards suddenly (which actually hasn’t happened for me), I think that should be sorted with a hotfix.

Personally I was crippled by Ctrl not restricting direction when you add in new automation points, which is something I really depend on. It made me stick to 10.5. I would have loved to jump on using 11 but I just couldn’t. It’s fixed in 11.0.10 but it took a long time.

13

I just started using 10.5 with 11 in my back pocket. I usually stay 6 months to a year behind.

14

Studio One - like many other competing DAWs - has many cool things going on, that make it appealing. BUT has its own set of problems. Let me give you examples of my personal experience with it, these may not apply to you though.

  • the UI is way too flat for me. I grew up with operating systems fake 3D borders around clickable elements and borders, and these “modern” flat UIs drive me crazy. I have a way harder time to find what is a “button” and what is just an icon to show me information.
  • the UI is also way too crowded with so many small text based elements and icons all over the place, I would call it messy. If you really work with it and take your time comparing, you may notice how comfortable Cubase is in comparison.
  • when I travel and have Studio One on a notebook or just use a trackpad or even trackball, I am annoyed that I can not right-click instruments in the list and put it on a new track that way. No, I have to navigate to the right side of the screen, click and hold the instrument and drag it aaaaall over to the left again to place it on a new track. This is a pain in the back with anything else than a mouse.
  • like Cubase with their offline processing, Studio One has fancy features that sometimes don’t work as intended. The layered instruments for me were extremely wonky and didn’t render the sound I created properly when exporting the song. They sounded differently when played back live and broken during offline export.
  • they have hardware controller profiles, but my AKAI MPD218, an affordable and probably wide-spread unit, isn’t there. I have to manually map that thing.

What I want to say is, before you jump ship anywhere, make sure to test things as thoroughly as you can.

1 Like
15

Yeah that’s the trouble with ‘hot fixes’. People forget that the in-house ‘live’ dev version is potentially months ahead of the version we’re running, and probably a way ahead of what the beta testers are running.

To apply a hot-fix to the current end user build you’d need to implement the fix, and run it through testing. But after that, you’d need to inject it into the new build and test also - so it’s maintained moving forwards. And being a ‘hot-fix’ you pretty much forego the beta test route and get it out ASAP.

Unless truly critical, you can see how a ‘hot-fix’ would be delayed until the next formal maintenance release.

I know most modern software development has much smarter tools for managing hot-fixes and syncing source file changes across multiple dev versions, but i’ve no experience of those - i’m quite old school, and whenever attempted to incorporate such frameworks it’s resulted in compile errors and hours of wasted time to the point where i’ve reversed out.

16

I was taught the half joke/half truth lesson of “nothing takes less than 3 hours” in a recording studio

in the coding world… nothing takes less than 3 months… or… 3 years.

17

I worked until recently in broadcasting as an operations manager. All the encoders we had were at least two to three generations behind the current version. This was all to do with stability. All of the other equipment like routers and switches, scramblers and such were again nowhere near the latest versions. When we did move to a newer version it was tested in house and even then we would still suffer teething problems in live.

I used to go to the new versions of Cubase on release but these days I wait and watch until there have been a few updates to iron out the biggest problems. I don’t see this ending any day soon with any software. Same with windows updates. If it works don’t move to the next version until it is fully supported.

18

Weeeell… Cubase right now is adding features that are a big deal for my workflow and productivity, mainly the Sampler Track. My workflow has a huge amount to do with samples, and having this built-in saves a lot of time loading plugins, putting samples into those plugins, fiddling with the settings of said plugin. I kinda need the latest features they are implementing, so running on an old version is not an option for me. That is why I am so frustrated, if they would release new versions properly tested and fixed, people could actually use the features they can buy from day one.

19

That’s good to know, thanks. I would still maintain though that the updates are less frequent with Cubase than with a lot of other software that I use. Firefox, Thunderbird, Steam and so on seem to have a new version almost any time you open them. :sweat_smile: Not a great comparison of course. But for example, DaVinci Resolve, just started using it some weeks ago and I think I’ve already gotten 3-4 updates.

20

You should get into Groove Agent - now that’s a damn impressive “bit” of code for a VSTi.

very quick and easy to use on the surface, but you’re also a few clicks away from some extremely deep complicated but cool tweakabilities.

drag and drop onto pads is nice, you can select 20 (or how many ever you want) kick samples in media bay and drag over to Groove Agent, and it will arrange them across pads automatically, or stacked as layers onto one pad depending on where you drop

ga