05 May 2015
Others' results may vary, but those are my thoughts. My experience differs from those of other users.
The amount of workaround wizardry that is required to approximate easier methods in other software is the simplest way I could explain my feelings.
It also does not help that there are multiple redundant ways of doing the same thing because while there are subtle differences, they're often so minute that the multiple paths just present the obstacle of too many choices. Look up "the power of undecision" for more on the concept of getting more done through fewer choices. This flexibility is acceptable, however, because it permits an organic approach to producing that allows different kinds of people with different types of thought processes to still make music "their way" among the available paths that lead to a shared destination. Admittedly, this comes down to allowing people to equally flail and call for a lifeguard, just in different parts of the pool. That premise also holds the curse that someone's understanding or ways of working won't translate over to someone else when disseminating knowledge. It won't make sense to them because those decisions within the abundance of available choices that Reason permits wouldn't be the ones that they would make. Effectively, the degree of catering to individuality can cause a closed loop around each user in addition to the already layered onion of closed loops surrounding Reason as a platform. The whole "you're somebody because you're a member of 'The Loop'," culture is one that is self-destructive in its worship of isolation in my opinion. But I digress.
What I was talking about was linear processes that impose on the user, like having to select each note, then go up to the top of the edit mode window, select the tiny text box for velocity, either numerically enter a value or drag up or down to the desired value, then move on to the next note and repeat. That's editing velocity in Reason 7.1. You used to be able to drag the velocity bars by clicking on them, but now they are just for visual reference. This specifically is a very linear and monotonous effort of note after note adjusting velocity with deliberate and needlessly mechanical precision, as if making these adjustments is highly unusual or catastrophic and should be treated with extreme care rather than ease of use. Extreme care that favors deliberate and specified input from the user in a arduous case by case basis is the meat of what I meant by "linearly programmed". I don't mind programming my beats that way, but I do mind my interaction with the program itself operating that way.
Another thing is having to alt+click a control, switch to the sequencer, go into edit mode, resize the window to see the automation lane if necessary, then drag the default value marker on the left (with almost microscopic text) to manually adjust with superfine resolution if you prefer to not edit every control with fine mouse adjustment set to max all the time. Numeric entry for control values should replace this. What about being able to ctrl+shift+click multiple controls all over the rack or on the mixer and then adjust them all while dragging? I would love that.
Drawing in actual curves for automation instead of straight lines requires a lot of trickery, and even using LFOs limits you to four bars in length if snapping to subdivisions of the tempo is essential to your project. Maybe Synchronous is different; I don't have it.
Even if you only setup a patch once so you can reuse it later, or if you develop template systems full of things you just want to be there, you still have to wade through figuring out that stuff, then building it, then troubleshooting unexpected behavior, coming here to ask why it isn't working, then finally achieving the result that you were after. If it's in a template, it's a feature you wish was available from the word go. That's why people put stuff like that in templates. My point is that if you're trying to develop things before you get started, yeah it's nice to have that leeway, but it gets in the way of getting started. I'd rather post about my accomplishments rather than my confusion.
Again, I do respect that we actually can do all this stuff, and I'm working very hard to help provide new solutions that will broaden what is possible in Reason, but just because something takes a long time to do does not make it worthwhile. As someone who takes music creation and music technology very seriously, I value my time more than I value an excess of options. The greats of the past had far less to work with and they made all those classic tracks.
That's my tl;dr version.
I just want this to be more of a collaborative effort between myself and the program, and often times it feels like I'm fighting to get stuff done.
Speaking of accomplishments over confusion, that's why I'm relatively scarce here now. I read more than write to take my mind off my projects here and there. What has launched me into this many weeks long journey of hard work has been the desire to get as much of the mechanical feel of composing digitally in Reason out of the way up front. One massive push to build the methods of free expression that I want at my disposal. One massive push to remove the jerky, methodical vibe and open up Reason to as higher potential than it has had up until now. Rather than abandon Reason, I am fighting to create a solution to my frustrations that can also provide benefit to others suffering from the same dissatisfaction. Even though I'm a nitpicker, I should thank Reason for being imperfect, seeing as how it has lead me to develop things I haven't seen anyone else doing.
Since some of the stuff I'm working on could literally change the game for a lot of people, I don't want to be considered a whiner. I accept that some features just won't ever exist in Reason. But some features that seem impossible, aren't. I hope I can prove that.