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

This forum is for discussing Reason. Questions, answers, ideas, and opinions... all apply.
User avatar
Creativemind
Posts: 4875
Joined: 17 Jan 2015
Location: Stoke-On-Trent, England, UK

12 Dec 2018

guitfnky wrote:
11 Dec 2018
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. 🤔
Yes that has occurred to me in the past. Is there any fundamental difference. Aren't they essentially the same thing?
:reason:

Reason Studio's 11.3 / Cockos Reaper 6.82 / Cakewalk By Bandlab / Orion 8.6
http://soundcloud.com/creativemind75/iv ... soul-mix-3

User avatar
Creativemind
Posts: 4875
Joined: 17 Jan 2015
Location: Stoke-On-Trent, England, UK

12 Dec 2018

EnochLight wrote:
11 Dec 2018
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). ;)
So we will never see universal readings as in frequency cutoff on the Subtractor in Hz?

We still see wrong readings on current devices though such as the Reverb on Europa decay amount in %. % of what?
:reason:

Reason Studio's 11.3 / Cockos Reaper 6.82 / Cakewalk By Bandlab / Orion 8.6
http://soundcloud.com/creativemind75/iv ... soul-mix-3

User avatar
Creativemind
Posts: 4875
Joined: 17 Jan 2015
Location: Stoke-On-Trent, England, UK

12 Dec 2018

:?
Last edited by Creativemind on 12 Dec 2018, edited 1 time in total.
:reason:

Reason Studio's 11.3 / Cockos Reaper 6.82 / Cakewalk By Bandlab / Orion 8.6
http://soundcloud.com/creativemind75/iv ... soul-mix-3

User avatar
Creativemind
Posts: 4875
Joined: 17 Jan 2015
Location: Stoke-On-Trent, England, UK

12 Dec 2018

chaosroyale wrote:
12 Dec 2018
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.
Like not being able to drag a midi clip onto an existing midi track but you can with audio?
:reason:

Reason Studio's 11.3 / Cockos Reaper 6.82 / Cakewalk By Bandlab / Orion 8.6
http://soundcloud.com/creativemind75/iv ... soul-mix-3

antic604

13 Dec 2018

Creativemind wrote:
12 Dec 2018
guitfnky wrote:
11 Dec 2018
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. 🤔
Yes that has occurred to me in the past. Is there any fundamental difference. Aren't they essentially the same thing?
Well, no:
- bypass lets the sound go unprocessed through the device, but it still "works" and takes up CPU
- off doesn't let any audio out of the device and uses no CPU

User avatar
esselfortium
Posts: 1456
Joined: 15 Jan 2015
Contact:

13 Dec 2018

Creativemind wrote:
12 Dec 2018
chaosroyale wrote:
12 Dec 2018
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.
Like not being able to drag a midi clip onto an existing midi track but you can with audio?
???? You actually can do that, though.
Sarah Mancuso
My music: Future Human

botnotbot
Posts: 290
Joined: 26 Oct 2017

13 Dec 2018

rcbuse wrote:
11 Dec 2018
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.
Non-developers don't tend to appreciate the idea of deprecated code, which is code that has hit dead-ends in various crucial ways, to the point where every developer involve takes a solemn oath to stop working on it for the sake of sanity and software both. This inevitably leads to a rewrite / replacement technology (in the Reason rack, this is the RE SDK) that is, at first, less feature-ful than the old code but designed to overcome the very obstacles that are blocking the old code.

Does it mean that nothing could be changed WRT the old code? No! The reason that the old code is never updated unless absolutely necessary (security and fatal bug fixes only) is that it is a waste of resources to improve a thing you are actively trying to kill and replace.

And we all know how upset forums get about wasted developer resources, right?

Much worse from the application's point of view, pushing a new feature with your deprecated code can ruin the feature you are trying to introduce by constraining it to only what is possible with the old code. (FWIW, I see the introduction of multi-lane editing as an indication that the pace of change in the sequencer might start to pick up).

No one outside the teams can be certain whether the fixing naming issue (Rotary 1 or whatever instead of a combi's real label for the knob is an example similar to the 0,1,2 thing) is an example of something avoided out of principle or instead a symptom of some inadequacy that led to the deprecation of the old rack code in the first place.

User avatar
thx
Posts: 46
Joined: 18 Sep 2016
Location: UK

13 Dec 2018

I enjoy reading all these types of threads but after about 5 or 6 posts something happens: suppositions that get repeated and rephrased a couple of times quickly turn into 'factoids'. No genuine evidence is presented, they are just baked into a kind of reality through restated assumptions and 'group mind'. It's trippy but maddening.

Things that look like old and abandoned to newcomers are in fact working just like they always did for veterans. But that doesn't mean they are abandoned, vestigial bits of code. Or some sort of wild, no-go zone in the codebase. The forbidden zone! In fact way before rack extensions all the stock devices had already been reimplemented at least once, in Reason 3 if my memory serves. This had zero noticeable effect to the user but had a major benefits to managing and building the codebase. (Thrills!)

User avatar
Creativemind
Posts: 4875
Joined: 17 Jan 2015
Location: Stoke-On-Trent, England, UK

13 Dec 2018

antic604 wrote:
13 Dec 2018
Creativemind wrote:
12 Dec 2018


Yes that has occurred to me in the past. Is there any fundamental difference. Aren't they essentially the same thing?
Well, no:
- bypass lets the sound go unprocessed through the device, but it still "works" and takes up CPU
- off doesn't let any audio out of the device and uses no CPU
Ahhh ok. Makes sense.
:reason:

Reason Studio's 11.3 / Cockos Reaper 6.82 / Cakewalk By Bandlab / Orion 8.6
http://soundcloud.com/creativemind75/iv ... soul-mix-3

User avatar
Creativemind
Posts: 4875
Joined: 17 Jan 2015
Location: Stoke-On-Trent, England, UK

13 Dec 2018

thx wrote:
13 Dec 2018
I enjoy reading all these types of threads but after about 5 or 6 posts something happens: suppositions that get repeated and rephrased a couple of times quickly turn into 'factoids'. No genuine evidence is presented, they are just baked into a kind of reality through restated assumptions and 'group mind'. It's trippy but maddening.

Things that look like old and abandoned to newcomers are in fact working just like they always did for veterans. But that doesn't mean they are abandoned, vestigial bits of code. Or some sort of wild, no-go zone in the codebase. The forbidden zone! In fact way before rack extensions all the stock devices had already been reimplemented at least once, in Reason 3 if my memory serves. This had zero noticeable effect to the user but had a major benefits to managing and building the codebase. (Thrills!)
Some stock devices were re-coded in Reason 3? if so, how d'ya know that?
:reason:

Reason Studio's 11.3 / Cockos Reaper 6.82 / Cakewalk By Bandlab / Orion 8.6
http://soundcloud.com/creativemind75/iv ... soul-mix-3

User avatar
thx
Posts: 46
Joined: 18 Sep 2016
Location: UK

13 Dec 2018

Creativemind wrote:
13 Dec 2018
Some stock devices were re-coded in Reason 3? if so, how d'ya know that?
Good question, cause otherwise I'm just adding to the guesswork and rumour mill. I don't think it's mentioned on the box or in press releases, rather it was in those old Props staff proto-blogs (remember those?) where they were talking about how making a full build of Reason took something like a day to crank out. So they had to do the least sexy work ever imagined to refactor the codebase, including modularize/harmonize the stock devices.

I only remember all this because the initial version of 3.0 had really dreadful performance at the outset. It was so sluggish and stuttery, it felt like Ableton had coded it. So I hastily figured that they had somehow optimized it to death. I ignored future developments for years, or read about them with disdain. Turns out it was only a minor bump in the road, as years later I saw 3.04 and it was perfectly fine, even on old 'puters.

User avatar
Creativemind
Posts: 4875
Joined: 17 Jan 2015
Location: Stoke-On-Trent, England, UK

13 Dec 2018

thx wrote:
13 Dec 2018
Creativemind wrote:
13 Dec 2018
Some stock devices were re-coded in Reason 3? if so, how d'ya know that?
Good question, cause otherwise I'm just adding to the guesswork and rumour mill. I don't think it's mentioned on the box or in press releases, rather it was in those old Props staff proto-blogs (remember those?) where they were talking about how making a full build of Reason took something like a day to crank out. So they had to do the least sexy work ever imagined to refactor the codebase, including modularize/harmonize the stock devices.

I only remember all this because the initial version of 3.0 had really dreadful performance at the outset. It was so sluggish and stuttery, it felt like Ableton had coded it. So I hastily figured that they had somehow optimized it to death. I ignored future developments for years, or read about them with disdain. Turns out it was only a minor bump in the road, as years later I saw 3.04 and it was perfectly fine, even on old 'puters.
:thumbs_up:

Interesting.
:reason:

Reason Studio's 11.3 / Cockos Reaper 6.82 / Cakewalk By Bandlab / Orion 8.6
http://soundcloud.com/creativemind75/iv ... soul-mix-3

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

13 Dec 2018

thx wrote:
13 Dec 2018
I only remember all this because the initial version of 3.0 had really dreadful performance at the outset. It was so sluggish and stuttery, it felt like Ableton had coded it. So I hastily figured that they had somehow optimized it to death. I ignored future developments for years, or read about them with disdain. Turns out it was only a minor bump in the road, as years later I saw 3.04 and it was perfectly fine, even on old 'puters.
Strange, how we all remember things very differently. ;) I was also present at 3.0's launch, yet have ZERO recollection of it having dreadful performance. Worked fine, as far as I can remember. That said, there were a couple of maintenance fixes released (3.04, and 3.05 - which was Mac-only). Maybe those fixes affected only some users? ¯\_(ツ)_/¯

https://www.propellerheads.com/download ... isplaymain
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

botnotbot
Posts: 290
Joined: 26 Oct 2017

13 Dec 2018

thx wrote:
13 Dec 2018
Things that look like old and abandoned to newcomers are in fact working just like they always did for veterans. But that doesn't mean they are abandoned, vestigial bits of code. Or some sort of wild, no-go zone in the codebase. The forbidden zone! In fact way before rack extensions all the stock devices had already been reimplemented at least once, in Reason 3 if my memory serves. This had zero noticeable effect to the user but had a major benefits to managing and building the codebase. (Thrills!)
Sorry, but what you have said is actually evidence of what I've said. They deprecated the old implementations and provided new ones. The new ones were even less capable than before (your performance issues).

They didn't patch the old code to fix your performance issue. They patched the "new" stuff, which is now all the deprecated rack implementations (if we see a spiffy new rack, we will be seeing either new versions or re-implementations).

How do we know the old code is deprecated? Because Props repeatedly says they haven't done anything that wasn't SDK-based since they introduced the SDK.

The annoying details that are sticking around are sticking around because the code is deprecated but not yet replaced.

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

13 Dec 2018

botnotbot wrote:
13 Dec 2018
How do we know the old code is deprecated? Because Props repeatedly says they haven't done anything that wasn't SDK-based since they introduced the SDK.
This is not entirely true. RV7000 MK2 was created, and had nothing to do with the RE SDK. Also, what about actual core Reason changes/updates that happen at every release? New features in the sequencer, the main mixer, etc? Asking for a friend.
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

botnotbot
Posts: 290
Joined: 26 Oct 2017

13 Dec 2018

EnochLight wrote:
13 Dec 2018
botnotbot wrote:
13 Dec 2018
How do we know the old code is deprecated? Because Props repeatedly says they haven't done anything that wasn't SDK-based since they introduced the SDK.
This is not entirely true. RV7000 MK2 was created, and had nothing to do with the RE SDK. Also, what about actual core Reason changes/updates that happen at every release? New features in the sequencer, the main mixer, etc? Asking for a friend.

I wasn't around back then, so I didn't realize that this was added afterwards, but again wouldn't this be a bit of an exception that proves the rule? One item gets an upgrade out of all the pre-SDK devices?

Also, I feel like I often read around here about how slow the sequencer updates have been in arriving, but maybe that's just observation bias. I'm not aware of any upgrades to the mixer in my time using the software but again, the same thing applies.

I'll stop arguing the point though, that non-devs don't understand what deprecated code means. I'm not saying the code is terrible, I'm saying that there are specific features and things we would call "bugfixes" which are not being addressed specifically because they decided as a team to address the issue in a way that doesn't involve touching the old code.

Do any developers feel like that's a controversial position / conclusion? Asking for myself.

User avatar
thx
Posts: 46
Joined: 18 Sep 2016
Location: UK

13 Dec 2018

@Enochlight - yeah 304 on Windows was solid, it was the initial v3 demo that scared/scarred me. I recall scrolling through the rack up and down, and the CPU hit caused the audio playback to slow down - like a Technics SL-1200 varispeed controller. Okay I tried finding some confirmation for any of this. The old website's Crew / Plan files aren't cached by the Internet Archive so unfortunately this is prehistory now. I feel like, I'm not saying it's aliens, but...

There's nothing in the 304 release notes to suggest resolved performance issues, but there definitely is for 302 and 303 (beowbeowbeow). Linkage:

https://fr.audiofanzine.com/sequenceur- ... ready.html

https://www.mixonline.com/news/propelle ... 303-419823

@botnotbot I just feel things aren't quite so stark, or clear-cut to outside observers, to be framed that way? Problems get fixed (including the ones I reminisced on), new stuff gets added, older stuff persists, but older stuff also gets refreshed (another example: Redrum hardware control support added a while back). Personally I agree with you about there being a lot of repackaging and reinvention nowadays, but that's true across the industry. "Deprecated" doesn't really fit or explain much of anything. It just reminds me of that old Pulp song.

User avatar
artotaku
Posts: 652
Joined: 09 May 2015
Location: Munich, Germany
Contact:

13 Dec 2018

Having not seen any source code or architecture it is all speculation. Of course, if a software is unstable and has a lot of bugs you can conclude that it may be hacked together by unexperienced developers, did not adhere to fundamental code quality principles or the test team does not do their job properly. I also think that it would not survive very long when there is competition. It´s not uncommon that developers leave such software projects soon.

So this is not the case with Reason IMHO, also based on what I learnt from the plan files they published a decade ago (search for old propellerhead site with wayback machine).

Sure, a software architecture and decisions of the past may not fit to the present which does not mean they were wrong. You always have some legacy in software you have to deal with which needs to be refactored from time to time. I´m quite confident they know what they are doing.

User avatar
fieldframe
RE Developer
Posts: 1037
Joined: 19 Apr 2016

13 Dec 2018

EnochLight wrote:
13 Dec 2018
botnotbot wrote:
13 Dec 2018
How do we know the old code is deprecated? Because Props repeatedly says they haven't done anything that wasn't SDK-based since they introduced the SDK.
This is not entirely true. RV7000 MK2 was created, and had nothing to do with the RE SDK. Also, what about actual core Reason changes/updates that happen at every release? New features in the sequencer, the main mixer, etc? Asking for a friend.
It seems at least plausible that the RV7000 Mk2 was the first port of one of Reason’s hard-coded devices to the SDK. It would be the place to start, right? Much simpler than porting a synth like Subtractor, and almost certainly the most-used stock effects device.

User avatar
ScuzzyEye
Moderator
Posts: 1402
Joined: 15 Jan 2015
Contact:

13 Dec 2018

fieldframe wrote:
13 Dec 2018
It seems at least plausible that the RV7000 Mk2 was the first port of one of Reason’s hard-coded devices to the SDK. It would be the place to start, right? Much simpler than porting a synth like Subtractor, and almost certainly the most-used stock effects device.
I believe it was actually stated that the Mk2 was not a SDK port. There's enough evidence to that fact too. It can change rack heights when you expose the programmer, and patches are don't use the .repatch extension. It even got wave loading before any RE could (that being the whole purpose of the Mk2 update).

botnotbot
Posts: 290
Joined: 26 Oct 2017

13 Dec 2018

ScuzzyEye wrote:
13 Dec 2018
fieldframe wrote:
13 Dec 2018
It seems at least plausible that the RV7000 Mk2 was the first port of one of Reason’s hard-coded devices to the SDK. It would be the place to start, right? Much simpler than porting a synth like Subtractor, and almost certainly the most-used stock effects device.
I believe it was actually stated that the Mk2 was not a SDK port. There's enough evidence to that fact too. It can change rack heights when you expose the programmer, and patches are don't use the .repatch extension. It even got wave loading before any RE could (that being the whole purpose of the Mk2 update).
Ah, that makes a lot of sense and indeed the wave loading seems to prove it, as that doesn't show up in the SDK until a fair while later. It's clear that Props has access aka dogfoods new SDK features before they arrive to the public but it doesn't seem likely that even their version of the SDK could do it back then.

Thanks for mentioning that, I really enjoy such historical details and I doubt I'm the only one.

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

13 Dec 2018

botnotbot wrote:
13 Dec 2018
Also, I feel like I often read around here about how slow the sequencer updates have been in arriving, but maybe that's just observation bias. I'm not aware of any upgrades to the mixer in my time using the software but again, the same thing applies.
The speed and frequency that the sequencer updates (we're talking new features here) occur have always been a complaint around here, and everywhere else - but that's just par for the course. ;) :lol: :lol:

Not sure how long you've been using Reason, but the main mixer has had several upgrades since first appearing in 5.0 + Record:
  • 6.5: An additional option has been added in the Bounce Mixer Channels dialog: “Copy original channel settings”. This is available when you bounce to new tracks in the song and the “Apply Mixer Settings : None” option is chosen. The new mixer channels can then get the same channel settings as the original - useful for bouncing a CPU-heavy instrument track but keeping full mixing freedom.
  • 7.0: New spectrum analyzer with visual EQ controls for the main mixer; Group and parallel mix channels.
  • 7.1: Shift-dragging devices will now re-route them properly (this affected the main mixer).
  • 8.0: ‘overview’ panels in the sequencer and mixer have been removed.
  • 9.5: Added Delay Compensation functionality (this is accessed via the mix channels rear).
  • 10.2: Adjust faders, solo and mute across multiple mix channels at once; New context menu item, Route to New Mix Channel, on audio outputs (which obviously affects the mixer channels).
I'm sure we'll see refinements in addition to these as the years go on.
botnotbot wrote:
13 Dec 2018
I'll stop arguing the point though, that non-devs don't understand what deprecated code means. I'm not saying the code is terrible, I'm saying that there are specific features and things we would call "bugfixes" which are not being addressed specifically because they decided as a team to address the issue in a way that doesn't involve touching the old code.

Do any developers feel like that's a controversial position / conclusion? Asking for myself.
I'm quite familiar with what deprecated code is from a software development standpoint. I'm just fairly confident that the original code that services Reason as a whole (not the RE-portion) is still quite active and being developed. It kind of has to be. ;) And yes, there are functions and interdepencies that are part of the mix - this is what the RE SDK helped address to a great degree.

As a digression, for the uninitiated I've always loved this analogy: Reason - as in the main program - is the "operating system". RE's are the "apps" that run within said "operating system". The RE SDK is the embodiment of guidelines, rules, code, and tools needed to create said "apps" for the "operating system". While all three of those are written using the same language, they all have interdependencies and functions that they rely upon.

If Propellerhead were to "re-write" Reason from the ground up, they would still need to have things in place that allow the RE SDK/ecosystem to work with it, exactly like it does now. The VST performance update that is incoming at some point in the future is likely the largest re-write they've done for quite some time. /end speculation post :D :puf_bigsmile: :lol:
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
selig
RE Developer
Posts: 11685
Joined: 15 Jan 2015
Location: The NorthWoods, CT, USA

13 Dec 2018

botnotbot wrote:
13 Dec 2018
ScuzzyEye wrote:
13 Dec 2018


I believe it was actually stated that the Mk2 was not a SDK port. There's enough evidence to that fact too. It can change rack heights when you expose the programmer, and patches are don't use the .repatch extension. It even got wave loading before any RE could (that being the whole purpose of the Mk2 update).
Ah, that makes a lot of sense and indeed the wave loading seems to prove it, as that doesn't show up in the SDK until a fair while later. It's clear that Props has access aka dogfoods new SDK features before they arrive to the public but it doesn't seem likely that even their version of the SDK could do it back then.

Thanks for mentioning that, I really enjoy such historical details and I doubt I'm the only one.
I'm fairly positive the props don't have access to new SDK features/builds before devs do (what makes you think they do?), because it would also require new Reason versions to match. What they obviously DO have is more advanced knowledge of features in the pipeline, which they could possibly use to conceptualize new features before devs get the chance to do so. But at the current pace of the SDK, I'm not sure that's at all an advantage at present… ;)
Selig Audio, LLC

botnotbot
Posts: 290
Joined: 26 Oct 2017

13 Dec 2018

selig wrote:
13 Dec 2018
I'm fairly positive the props don't have access to new SDK features/builds before devs do (what makes you think they do?)
Players arrived for Props well before they did for third parties... right?

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

13 Dec 2018

botnotbot wrote:
13 Dec 2018
selig wrote:
13 Dec 2018
I'm fairly positive the props don't have access to new SDK features/builds before devs do (what makes you think they do?)
Players arrived for Props well before they did for third parties... right?
Nope. Some 3rd party Players arrived in the shop at the same time that the Props launched the ones in Reason 10 (Zvork's ST100; Lectric Panda's CV Player Tap and others)...
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

Post Reply
  • Information
  • Who is online

    Users browsing this forum: miyaru and 19 guests