12.2.4 Released

[Heigen5]

The combi2 patch shifting took 7-8 seconds in the 12.2.3, but they fixed this in the 12.2.4
I'm Happy for that at least!

[MrBlue]

Is it just me or is this version saving project files noticeably slower than before?

Not just you, it's same here...

[avasopht]

Because the world has gone mad; particular the American humanities crowd. Unfortunately it seems like it's becoming evermore impossible to keep politics and political correctness out of the sciences and engineering. Thus perfectly sensible terms which are being used in a way which has literally zero racial undertone to them at all (and are being used explicitly to refer to the relationship that hardware, code or 0s and 1s have to each other) are being overthrown unnecessarily to win cheap political arguments. Bring back common sense.

Master/slave doesn't describe the behaviour. We use it because someone on a whim coined the term, and then like a snowball grew in adoption until it became an established term that barely resembled the abstract concept or concrete implementation it referred to.

Changing the term doesn't even need to have anything to do with political correctness. It's a poor term.

That being said, opposing the change is highly irrational since those old terms are poorly formed anyway, and the only reason to keep it is "just because ... let's not change terms ever" and "this sounds liberal ... I'm not liberal".

There are lots of terms like that in science and engineering:
1. Imaginary numbers
2. Object-Oriented Programming
3. Artificial Neural Network
4. Master/slave
5. Scripting language (programming languages are just specifications and could be used for "scripting" or compiled to machine code)
6. Funnybone (not a bone)
7. Floppy disk (they stopped being floppy a long long time ago)
8. Centrifugal "force" (it's not a force)
9. RISC/CISC
10. Coder (see The Mythical Man-Month)

Now, the whole master/slave debate should have been a non-issue. IIRC Guido van Rossum made the decision. It didn't come from any complaints, nor did it come from the humanities crowd. He explains in great detail his reasoning, and while the change does address his concern about inclusion, there are intrinsically useful technical reasons for doing so. We should do the same with the term "imaginary numbers".

I am yet to see a well-reasoned or intelligent argument to not master/slave to what it actually refers to unless master/slave denotes a pure abstraction that perfectly generalises all of its applications (which it does not).

[plaamook]

Why?

Because the world has gone mad; particular the American humanities crowd. Unfortunately it seems like it's becoming evermore impossible to keep politics and political correctness out of the sciences and engineering. Thus perfectly sensible terms which are being used in a way which has literally zero racial undertone to them at all (and are being used explicitly to refer to the relationship that hardware, code or 0s and 1s have to each other) are being overthrown unnecessarily to win cheap political arguments. Bring back common sense.

I recently had to order some male/female screw sets. As far as I know that's still an acceptable term. If it isn't, I wish I'd known. I would have enjoyed using it more! (power to the people, stick it to the man)

[rootwheel]

That being said, opposing the change is highly irrational since those old terms are poorly formed anyway

If they were poorly formed then the language would have evolved naturally into something that made more sense to engineers. That never happened and that isn't what is happening here. Arbitrary and artificially prescribed language changes are being mandated through political activism - the changes aren't being driven through any need to solve a technical problem, just the imaginary issue of 'offensive language'. It has nothing really to do with engineering and shows no respect for the heritage of engineering - which is exactly why it should be opposed.

[orthodox]

I recently had to order some male/female screw sets. As far as I know that's still an acceptable term. If it isn't, I wish I'd known. I would have enjoyed using it more! (power to the people, stick it to the man)

I read about the development of the docking port for Apollo-Soyuz spacecrafts in 70s. They did a great job back then of ensuring that it was symmetric, so neither part would feel themselves in some gender role.

[plaamook]

I recently had to order some male/female screw sets. As far as I know that's still an acceptable term. If it isn't, I wish I'd known. I would have enjoyed using it more! (power to the people, stick it to the man)

I read about the development of the docking port for Apollo-Soyuz spacecrafts in 70s. They did a great job back then of ensuring that it was symmetric, so neither part would feel themselves in some gender role.

[avasopht]

If they were poorly formed then the language would have evolved naturally into something that made more sense to engineers.

Says who?

And no, you are wrong. The 10 terms I listed are all poorly formed. You don't know because you simply don't know anything about the fields.

According to your logic, all of those 10 terms should have naturally evolved. Now, this isn't even a debate - they are objectively poor terms to use today.

You are making two erroneous propositions:
1. A term if poorly formed will always (or at least almost always) evolve naturally to make more sense to engineers.
2. (Implicitly) the barometer of whether a term is poorly formed should be determined by whether new terms have or have not naturally evolved.

Technical terms don't need to "naturally" evolve. What does that even mean? It's such a wishy-washy statement. Technical terminology doesn't have to naturally evolve. That's part of what differentiates it from spoken language.

You have also claimed it shows now respect for the heritage of engineering. That's utter bullshit. This has nothing to do with the "heritage of engineering". That's a ridiculous claim. I also gave 9 other examples of poorly formed technical terms.

You also falsely claimed that "the prescribed language changes are being mandated through political activism." That is a blatant lie. Guido van Rossum did so on his own accord. There was no political activism involved. Ditto for SQL. Unless you're now going to claim that the creator of Python is not allowed to decide naming schemes for the programming language he developed.

And the changes make more engineering sense as they actually describe the real relationships. And it does solve a technical problem - clear and accurate terminology. Master/slave is simply unclear. If you were an engineer, you'd understand that naming is a technical problem.

There's a bit of baggage in technical jargon, and as evidenced by the list of just 10 of them, it's actually quite hard to change (even when they make no sense). And no, they do not (as you falsely claimed) all naturally evolve to make more sense to engineers.

Inertia is a powerful "force".

Engineers have to deal with change all the time. You might have difficulty with that, but that's why you're not an engineer.

Why you oppose attempts to remove "offensive language" (which serves no practical purpose) speaks a lot about your values as a human being - and no, it's got jack shit to do with respecting the so-called "heritage of engineering."

And no, I don't care much about these terms on an emotional level. Whether they stay the same or change doesn't elicit an irrational response to keep or change it. I just find it revealing when people make the effort to oppose it. It's very revealing, because there is NOTHING of value to preserve, and the change comes at no cost while increasing clarity. The only rational and intelligent thing to do is to accept it, because the clarity is a cost-free benefit (even if you don't care about social justice issues).

Note: not changing terms is not the same as opposing. Nobody is judging a team/company for continuing to use the terms, though master/slave is now a bit archaic.

And as an engineer, it gets my thumbs up for increasing clarity (while sometimes adding new terms to my lexicon, such as ingress and egress).

[rootwheel]

If they were poorly formed then the language would have evolved naturally into something that made more sense to engineers.

Says who?

And no, you are wrong. The 10 terms I listed are all poorly formed. You don't know because you simply don't know anything about the fields.

According to your logic, all of those 10 terms should have naturally evolved. Now, this isn't even a debate - they are objectively poor terms to use today.

You are making two erroneous propositions:
1. A term if poorly formed will always (or at least almost always) evolve naturally to make more sense to engineers.
2. (Implicitly) the barometer of whether a term is poorly formed should be determined by whether new terms have or have not naturally evolved.

Technical terms don't need to "naturally" evolve. What does that even mean? It's such a wishy-washy statement. Technical terminology doesn't have to naturally evolve. That's part of what differentiates it from spoken language.

You have also claimed it shows now respect for the heritage of engineering. That's utter bullshit. This has nothing to do with the "heritage of engineering". That's a ridiculous claim. I also gave 9 other examples of poorly formed technical terms.

You also falsely claimed that "the prescribed language changes are being mandated through political activism." That is a blatant lie. Guido van Rossum did so on his own accord. There was no political activism involved. Ditto for SQL. Unless you're now going to claim that the creator of Python is not allowed to decide naming schemes for the programming language he developed.

And the changes make more engineering sense as they actually describe the real relationships. And it does solve a technical problem - clear and accurate terminology. Master/slave is simply unclear. If you were an engineer, you'd understand that naming is a technical problem.

There's a bit of baggage in technical jargon, and as evidenced by the list of just 10 of them, it's actually quite hard to change (even when they make no sense). And no, they do not (as you falsely claimed) all naturally evolve to make more sense to engineers.

Inertia is a powerful "force".

Engineers have to deal with change all the time. You might have difficulty with that, but that's why you're not an engineer.

Why you oppose attempts to remove "offensive language" (which serves no practical purpose) speaks a lot about your values as a human being - and no, it's got jack shit to do with respecting the so-called "heritage of engineering."

And no, I don't care much about these terms on an emotional level. Whether they stay the same or change doesn't elicit an irrational response to keep or change it. I just find it revealing when people make the effort to oppose it. It's very revealing, because there is NOTHING of value to preserve, and the change comes at no cost while increasing clarity. The only rational and intelligent thing to do is to accept it, because the clarity is a cost-free benefit (even if you don't care about social justice issues).

Note: not changing terms is not the same as opposing. Nobody is judging a team/company for continuing to use the terms, though master/slave is now a bit archaic.

And as an engineer, it gets my thumbs up for increasing clarity (while sometimes adding new terms to my lexicon, such as ingress and egress).

TL;DR - fine you use that language but don't force it onto me

[EnochLight]

Yikes - had no idea that my comment was going to go this direction. Sorry about that! OK, let's please get things back on topic. Take discussions regarding political hot topics into PM, please.

[moalla]

R12 gets better, finally. After 5months no Vst or M1 update what´s sad but okay, haven´t found the time to play with comb2 editing possibilities.
Now R12 is usable and more stable, no freezes or shutdowns in the last two sessions, also the graphics are now fast enough after opening saved songs, autposcale are welcome, but when comes a browser update where only the written expression, without click the category effect/instrument/player tap... still shows up the Re or Vst device in the browser!?

Some small improvements and Reason feels finally more like an software from these decade

[plaamook]

Yikes - had no idea that my comment was going to go this direction. Sorry about that! OK, let's please get things back on topic. Take discussions regarding political hot topics into PM, please.

Shit, I read your post and I had to check to see what thread I was on!
Bloody 12.2.4 Release!!!

[Tinnitus]

It nice to see that this also fixed an issue where my refills were not accessible ( you could only open some).

[DNGmaestro]

Better stability overall but still crashes with VPS Avenger in some instances, can't figure out when exactly. But when it starts crashing with Avenger in a project, it always crashes. The pattern is maybe in bigger projects or with several instances of Avenger in the track.

[Emian]

I think the main focus of RS at the moment as to address the usability of their product.

IMO HiRes was only dealt with because of the RRP, and some users unable to actually use the vst given it's size. Similarly, the main highlight of this 12.2.4 update is auto scale of VST within Reason Standalone - as the autoscalling previously made some vst's unusable in size.

There's probably more ground to cover with respect to performance, before they start addressing and tidying up UI defects.

Don't forget HD graphics was one of the main selling points for Reason 12.

[kitekrazy]

Never amazed anymore how something like an update can go in an extreme off topic direction.

[plaamook]

Never amazed anymore how something like an update can go in an extreme off topic direction.

Yeah.
Kinda suits the state of Reason though.

[earwig83]

They KINDA fixed the scaling issue but not really. First, it requires a restart each time to open a vst, realize it is too small and then go to switch it to auto-scale, which just makes them look blurry. The blurry part I get, not so simple. But the implementation seems rather buried and unfriendly. Anyways I'll take it but it is ghetto. VSTs looked fine before they introduced the RS hires version.

Reason icons in browser are still low res. not a huge issue.

Someone in another thread said "why are RS responsible for making sure the VST looks ok in RS?" I don't really get that question though. I mean why make sure sound comes out? It's a third party sound device!! lol Point I am making is that is reason wants to support VST, even if the vst itself doesn't scale, Reason before the hi def version displayed VSTs just fine, which means something RS did is causing this issue. So fix it better, wills ya? For now, I will work with this though.

I'm on mac, so I can't test this. VSTs for us never had the scaling issue, so no fix needed. Can you post pictures of what you are seeing that is blurry?

I'm not currently at my production machine, but basically the blur is to be expected as a normal symptom of bitmap scaling. I just think the way windows and reason talk to each other makes these problems difficult to fix. For my general purpose, I have to use 125% on windows global dpi scaling for a nice balance between the 3 different sized monitors I use (all at different resolutions). The combination of this and the way reason treats it's hi res technique means that i can either choose to have all my other windows programs look too small or choose to have reason crisp via the zoom but all non-scaling VSTs look a bit blurry but at least readable now. As you know, before this newest update, they were simply too small. Most difficult to handle is VSTs like NI maschine and Komplete Kontrol, which are too small with the hi res version of reason prior to the fix. Still feel like the NI vsts looked better before hires reason came out.

It's really the fault of all three companies here. Reason, windows and Native instruments all somewhat clunkily implement their own approach to scaling. Companies need more neurotic bug testers and complainers working in house to keep these teams in check when it comes to QA. Most companies QA is simply not robust enough. A great example is how no one cared to push for a button or shortcut key so that I can zoom in and out of reason freely. Devs are really not thinking things through IMO. There should also be per window zoom setting as some people have different resolution monitors for each reason window. I sometimes use a screen vertically for the rack, in fact it is a touch screen too! I think I am an outlier here who is pushing the possibilities of reason and other use paradigms to the limits and there is simply a lack of creativity in the development world. As someone who works with developers, you should see they junk they push live for me to bug test. Anyways, I'm rambling now!

I can work with this most recent implementation, even if it isn't what I dreamed of.

[michael.jaye]

Is anyone else having the problem of in Rack view, "Duplicate Devices/Tracks" stacks the Mix Channels together then the Devices? When it should be Mix Channel/Device..... Mix Channel Device.... Mix Channel/Device?

[orthodox]

Is anyone else having the problem of in Rack view, "Duplicate Devices/Tracks" stacks the Mix Channels together then the Devices? When it should be Mix Channel/Device..... Mix Channel Device.... Mix Channel/Device?

Do you have "Auto-group Devices and Tracks" enabled in Options menu?

[michael.jaye]

Do you have "Auto-group Devices and Tracks" enabled in Options menu?

Good catch. I did have it enabled. However, now when I do it it only duplicates the track, no device (or vice versa)! It only duplicates the thing I click on.

If I press shift and select both device and track, it will duplicate normally. I'm sure this isn't normal behaviour.

[orthodox]

Do you have "Auto-group Devices and Tracks" enabled in Options menu?

Good catch. I did have it enabled. However, now when I do it it only duplicates the track, no device (or vice versa)! It only duplicates the thing I click on.

If I press shift and select both device and track, it will duplicate normally. I'm sure this isn't normal behaviour.

I actually thought it wasn't enabled. Now I checked it in Reason and it really does stack them when Mix Channel is duplicated. But if you drag it around so the associated devices stick to it, they will drop together.

[npinero1]

Did this most recent updated version delete our cache folder? I noticed that everything is saving so much faster.

Any one else have the same experience?

[moofi]

So why is it the default audioformat when exporting on PC AIF now?
Please default WAV on PC once again.

In this context I just realised we can export to mp3 now, though, coming from Reason 7 to 12, this could have already been impletemented quite a while ago.

[deeplink]

So why is it the default audioformat when exporting on PC AIF now?
Please default WAV on PC once again.

In this context I just realised we can export to mp3 now, though, coming from Reason 7 to 12, this could have already been impletemented quite a while ago.

The default export is a known issue which is being addressed.

MP3 export was added in Reason 11