Raveshaper wrote: ↑11 Sep 2019
I've already shouted enough but here's one last "why" response.
Other software allows you to enter exact values for parameters. Seems like a simple difference at first. Horses for courses some have said, and maybe so. But what that means is, internally, the other software has the capacity to calculate based on custom, fine grained values on the fly. If you can enter specific values, it's because that's true behind the scenes. I've got bad news for you. Reason doesn't have this feature because it only has fixed discreet values contained in arrays. There's no allowance for values outside of the ones you can select. It's stable for what it is. But... those other packages can do all of that calculation of exact values efficiently
plus have all those added "bell and whistle" features too? Wow. Suddenly, huge difference.
That's one seemingly small thing, but it turns out to be a spotlight on how the software was designed and how
the programming principles are lacking, not necessarily the software itself.
For example, those new automation curves. Can you see a vertical line of intersection aligned to your mouse pointer with a display of the curve's amplitude at that exact location? And does that amplitude show in the correct format of Hz or dB? I haven't seen that, and there are no points to use as a way to guess. What are users supposed to do? Curves indicate the need for precision, but instead the feature simply manages to exist at all.
Speaking of curves and fixed number of values in arrays, there's this huge elephant in the room about sequencer tracks. Everybody wants folders and collapsibility. It's an admirable desire and I agree it should be there. But in the case of automation lanes, every lane uses a discreet value based on the format displayed in the user interface, meaning
every value for automation is computed in reverse from the displayed value and added to an internal array where it is then iterated, adding to the load on the CPU. What should be happening is that every automation lane is nothing more than a floating point value on the unit interval (between 0 and 1), where it is then efficiently multiplied by the range of value for the thing it automates to display in the sequencer. Instead, a lot of computationally expensive stuff involving slow arithmetic operators like division and/or modulo is going on.
This is why you can't drag automation clips freely between any automation lanes you want. So, again, just like the limited number of values for knobs and stuff, every lane is treated as its own discreet entity, like a child class, that only contains a pointer back to the device it belongs to. That said, it should be easy to make track folders and collapsibility. Since it isn't here yet, it's because the entire internal structure of the sequencer was rolled out as re-skinned inefficiency under the hood. Because of competing projects or other situations, it hasn't been updated since.
All of this brings me back to the whole core idea behind why I'm leaving this app behind. It's like this software is one of the world's oldest running "pre alpha" releases. It looks good, but if you took the graphics out and focused the experience purely on sound without the need for visual appeal, like Ableton does, Reason simply isn't designed or built well. It hides behind that pop and flash of its "visual inspiration".
I think that other software has made as much progress as they have because they aren't trying to reinvent the wheel. That old line of limitations breed creativity also applies to software design, but in that context it's more accurate to say "clearly defined rules for a program make for an achievable project". I think Reason is too freeform to allow for progress. Seriously, research something like PostgreSQL and then treat Reason like an API. Get a white board or go on draw.io and try to map out what's going on. If you manage to map out a picture of what you think the internals look like, now imagine having to wade through all of that to move it all forward to where people want it to be.
Ouch.
But that's my point. I don't think that this should be publicly funded through retail purchase. I think that a core of loyal people who see the promise and potential should be backing it on kickstarter somewhere and everyone else should have it as donation ware. It's just not on par with other packages from an honest business perspective. For the same price of Suite you can get Cubase Pro. Yeah there's an iLok on top of that but that is the direct feature comparison.
Endless amounts of money are going in, but nothing much is coming back out. I can partially see why, as I stated above about trying to design an API (there's a ton they have to re-do), but... it would be the honest thing to admit "hey, we don't know what we're doing, we have to rip everything out and rethink things so we can move forward, consider backing us on Patreon or somewhere while we figure this out and thanks for sticking with us if you're doing that", followed up with live streams of sprint meetings every 3 weeks and stuff like that, so people can at least have the offer of involvement and see confirmation of where their money is actually going.
In a nut shell, I don't respect what the company is doing and I know enough about how programs are built that everywhere I look, I see signs that the product is a broken mess. Like how the file browser uses "hot loading" to update and show a USB stick when you plug it in, but you have to restart the application for a theme to take effect or for your audio drivers to reflect changes you've made. That's a case of the file browser being "bolted on" around the edges. Everything should hot load like the file browser does, but bolting something in is quicker than doing it right.
That's why every answer to "simple question" threads about "how do I do basic thing x" always have ten items in a list. Everything is just sort of bolted together enough so that the app starts up. As long as it runs at all, job done. That's not worth my investment if that's the state of things after 20 years.
Compact was built from the ground up and there's no gesture zoom to see your entire arrangement, only horizontal scroll. There's no follow playback you have to do it manually. There's no coloration of black and white keys in the piano roll. And there's a limit on the number of devices because they either can't figure out how to write multi-core performant code or the DSP code for their new engine can't be ported to iOS. So, my point here is that even software they build more or less from scratch is a barebones "pre alpha" that shouldn't command a price tag. It's bolted together from the beginning, perhaps by stitching bits of code from the standalone together in a smaller Frankenstein.
For those who don't know, "bolting on" features is a term that refers to jamming a new piece of code into an old release and calling it a new release. Instead of properly implementing it by altering the surrounding code base to truly unify all aspects of the application, it's just sort of stitched together so that it "works", the major release number gets bumped, and the team hits the release target. It's a "close call" or "cut corner".
I don't want to pay for bolts. I'm not a sucker for those tricks. At least, not on this scale. The entire application is made of bolts and the very processes and paradigms that are unique to the brand obstruct my ability to create. That's why I'm leaving.