Reason's (not so?) "kludgy" code

[chaosroyale]

Something that has been bothering me a little, related to comments by various users who said they feel that Reason is kludged together under the hood and that's why optimization is so difficult.

In combinators, new devices (after about R8 I think) display options like "enable, off, bypass" in English. Whereas old devices show only "0,1,2" for the same options.

Are there really 2 completely different pieces of display code for bypassing devices in a combinator? Why not update the combinator display defaults so that state "0" automatically displays the word "off" or whatever, instead of leaving it alone and then making a completely new display mode that only affects newer devices. It doesn't make any sense from either a UI point of view or a programming point of view. This is a small detail but that makes it even more worrying to me. If such an obvious thing doesn't get addressed in an optimized way, what is the situation with the main parts of the program?

I hope that the delay in the performance update is due to the "kludgey" code being completely rationalized and streamlined and that this makes all future updates easier for the developers. That might be a big undertaking for a smaller developer like Props, but I hope they pull it off.

edit: this is all speculation based on how Reason "feels" to use, compared to more streamlined programs.

2nd edit: It seems like this particular issue is a UI issue rather than a coding issue and I was drawing connections between unrelated things. Lack of standardization in the UI still annoys me though. Enochlight's explanation about legacy MIDI and the changeover to RE's is pretty interesting for anyone interested in the history of the software.

[dioxide]

Reason's rack devices use two different type of tech. The first was native devices, and more recent devices are all Rack Extensions. That's why there is a difference between devices.

As for performance, I'm sure they can improve, but it is partly due to Reason's completely free audio and CV routing, which makes multi-threading tricky.

I doubt very much that their code is "kludgey".

[Undistraction]

Why do you think it's taking them so long to release the performance update or upgrade to modern resolutions, or do anything really other than pump out Rack Extensions? Because they are struggling to update an ancient codebase that they have allowed to rot through neglect. All they can do is build on top, and that doesn't address the fundamental issues buried underneath. This is my guess based on recent events of course, so no need for any outrage at my 'wild speculation',

[aeox]

[MrFigg]

Kludgy or more correctly cludgey is the old Scots name for a toilet . Just so’s you know .

[aeox]

this is all speculation based on how Reason "feels" to use, compared to more streamlined programs.

Personally, Reason is much better to use than other DAWs I've used (Ableton, bitwig, fl studio) Maybe it's just not the right DAW for you?

I really don't know what you mean by "kludgey". You're assuming that something dire and wrong is happening under the hood based on a inconsistency in text characters. I think it's wild for music producers to try to speculate on the codebase. No one knows anything about it, only speculation, which is unhealthy.

edits: multiple typo fixes

[dioxide]

Oh. So your opinion is based on your feelings rather than something you can demonstrate? NEXT!!

[EnochLight]

Kludgy or more correctly cludgey is the old Scots name for a toilet . Just so’s you know .

cludgey .jpg (103.36 KiB) Viewed 3004 times

[rcbuse]

Its my experience that the more kludgy the code, the more fragile the software is. Things that are all hacked together under the hood show though with weird ass behaviors or crashes across platforms. Reason could easily be the most rock solid piece of software I've ever owned. I would be willing to bet money the codebase giving that behavior is extremely well maintained and a probably an example of best practices.

[aeox]

Oh. So your opinion is based on your feelings rather than something you can demonstrate? NEXT!!

That's sounds like a quote straight out of a gender identity debate

[motuscott]

Themz fightin' words.
Oh shit. Banned again.

[EnochLight]

In combinators, new devices (after about R8 I think) display options like "enable, off, bypass" in English. Whereas old devices show only "0,1,2" for the same options. This really looks like a kludge, and one that will come back to bite the programmers in the ass.

Are there really 2 completely different pieces of display code for bypassing devices in a combinator? Why not update the combinator display defaults so that state "0" automatically displays the word "off" or whatever, instead of leaving it alone and then making a completely new display mode that only affects newer devices.

No, there is no different code, and it's certainly not a "kludge". For the record, since many here were never a part of the old Propellerhead User Forum or may have missed discussions like these in the past, the only reason this is like this is because at one point in the past (beginning with Reason 1.0), all pop-up dialog displays were displayed with standard MIDI 0-127 numerical values only. The Rack Extension SDK was developed with the option to include new data, allowing devices to display more useful information (such as db, frequency, percentages, etc).

For legacy devices, it's a laborious and time consuming process to convert older MIDI 0-127 data to meaningful decibels, etc. They just never got around to doing it because reasons. One could say the RE SDK addressed a lot of the original shortcomings (while introducing its own issues, obviously).

Fun fact: The Echo, Alligator, and Pulverizer were all RE's.

[KirkMarkarian]

Its my experience that the more kludgy the code, the more fragile the software is. Things that are all hacked together under the hood show though with weird ass behaviors or crashes across platforms. Reason could easily be the most rock solid piece of software I've ever owned. I would be willing to bet money the codebase giving that behavior is extremely well maintained and a probably an example of best practices.

Agreed. Solid performer. Issues have only arose from the Rack Extensions I choose (and rarely, I might add), and not from Reason alone.

[Ostermilk]

Another master software developer able to cast the first stone.

I'll tell ya, nothing here presently makes me as nauseous as the amount of expert pwogwammaz that infest this board lately!

Reason is a product much like a fridge. You either dig it or you don't, who on earth ponders on how the moulded inserts are made, let alone wonder on the background technology used to make them?

Armchair expertese seems like a much more common phenomenon lately and yet it achieves/proves nothing. If one really can see the faults then come up with something better, or as Frank would have said "Shaddup and play yer guitar"...

[guitfnky]

sort of tangential to the topic, but I was wondering about the bypass/on/off switch the other day...what is the use case for needing an off option? it’s been more annoying than anything, in my experience, when I accidentally turn a device off when I really just wanted to bypass it.

[ScuzzyEye]

Fun fact: The Echo, Alligator, and Pulverizer were all RE's.

Proto-REs. The Echo has an annoying "feature" that's actually pretty closely related to this topic (displayed values in Combinators). Something that was changed for the final RE SDK release. The time knob has two modes, free and sync. Many devices do this, so you can either use ms, or beats. On REs when a knob has two functions it actually behaves as two different controls (as visible in the Combinator or automation lane). The sync on/off button chooses which control is active. Not so on The Echo. The knob is one control that has two different ranges? I don't know how to describe what happens, but it's definitely odd. Try putting The Echo in a Combinator, and using programmer to map the time control. Set a range for it to cover. Now toggle the sync button, and adjust either the top of bottom of the range. Odd, huh? It's most annoying when you set a time in ms, but change the sync to try something else, and don't like it, and turn sync off.

[ScuzzyEye]

sort of tangential to the topic, but I was wondering about the bypass/on/off switch the other day...what is the use case for needing an off option? it’s been more annoying than anything, in my experience, when I accidentally turn a device off when I really just wanted to bypass it.

"Off" stops all code in the device from running, to possibly free up DSP resources. Some things like free-running LFOs, may still take CPU time, even if a device isn't receiving audio. If Reason had a quick way to freeze tracks, automatically setting bounced devices to Off would be perfect.

[chaosroyale]

That's a very good point. I got distracted by an annoying feature and speculated without any real evidence. At most I should have just said "this lack of standardization is annoying" and left it at that. If I had waited 5 minutes I probably would have let it go and not posted anything at all.

Oh. So your opinion is based on your feelings rather than something you can demonstrate? NEXT!!

[guitfnky]

sort of tangential to the topic, but I was wondering about the bypass/on/off switch the other day...what is the use case for needing an off option? it’s been more annoying than anything, in my experience, when I accidentally turn a device off when I really just wanted to bypass it.

"Off" stops all code in the device from running, to possibly free up DSP resources. Some things like free-running LFOs, may still take CPU time, even if a device isn't receiving audio. If Reason had a quick way to freeze tracks, automatically setting bounced devices to Off would be perfect.

ah, that makes sense. that does sound like a good idea for freezing tracks...similar to the send to track functionality of Players, where it automatically bypasses the device(s).

[dvdrtldg]

If such an obvious thing doesn't get addressed in an optimized way, what is the situation with the main parts of the program?

Maybe for "obvious thing" substitute "tiny thing of next-to-zero relevance to the successful functioning of Reason whose non-existence as a serious issue makes it a low-order priority" and you've got your answer

[MrFigg]

Kludgy or more correctly cludgey is the old Scots name for a toilet . Just so’s you know .

cludgey .jpg

That one’s in Edinburgh. I’ve seen a lot worse in Glasgow...and Stockholm for that matter .

[motuscott]

Don't get me started about those "footprint toilets" I found while on tour in northern Italy. Luckily I was high as der Materhorn.

[synthetechsound]

Having used the RE SDK I can say with some level of certainty that the sdk was the most organised sdk I have ever used in 20 years of development. Not only was the code elegant and well organised but it was also extremely well documented. My impression from using their tools and the platform is that they know development. I see their approach as a step beyond best practice.

My .02

[chaosroyale]

That's really good to hear, and I am very glad that my bear-with-a-sore-head late night ranting was misdirected. I can certainly believe the documentation was excellent- Reason's manual is the best manual of any music technology product ever, hands down.

Given what you and others have said about the SDK, and the recent thread and video about the forward-thinking architecture behind the Rack Extensions which has apparently existed for years now....I wonder why Reason still feels so "last gen" compared to other software in terms of UI and workflow? It bugs me like crazy because I love the inspirational quality of Reason, and I feel like it has the potential to be a market leader. Right now it feels more like a quirky outlier slowly getting left behind. I'm not going to move over to the dreary spreadsheet that is Ableton just yet , but there are so many things left undone that leave me scratching my head in confusion.

Having used the RE SDK I can say with some level of certainty that the sdk was the most organised sdk I have ever used in 20 years of development. Not only was the code elegant and well organised but it was also extremely well documented. My impression from using their tools and the platform is that they know development. I see their approach as a step beyond best practice.

My .02

[Noplan]

It was not long ago when Reason was praised for its stability and everybody was hoping for VST support. Now the support is just here and reason is said to be the purest disaster under the hood. That's how fast it can go. And yet, I haven`t had a single crash yet to blame Reason. I don`t believe it's that bad. It's just a bit more complicated if you want to integrate everything into a virtual rack that is consistently upwards compatible. Reasons concept was not originally intended as a DAW. it has grown into one. If you already compare Reason with top DAWs with many years of VST experience, then everything seems to have gone well.