6 thoughts on “Inside The Propellerhead Reason Rack Extension Format”

1. i am using the propellerhead apps and after downloading one of the later ones i begun recieving an ungodly amount of propellerhead spam. every other day i would get some idiotic email.
   suffice to say i unsubbed and will never get a software or an app from them.

   buh-.bye

   1. What does your “spam” email have to do the with presentation?

      1. just saw propellerhead in the title and decided to vent about propellerhead.
         wild non-sequitur i know.

2. That presentation was great. I love the platform and its great to see they thought long and hard about the future and what they want to achieve. I cant wait to see what hardware devs will do with this going forward. Hope interesting things appear in 2019. Great job Propellerhead.

3. It really does seem like Propellerhead really are thinking long and hard about the long game far into the future. Very smart guys indeed. I love how they are looking to really branch Reason and REs out onto other platforms and make it easy to develop for all of them. One thing that I have always wondered is, how have they succeeded in creating a lock tight licensing and copy protection scheme where almost all else have failed? This has always been kind of a thing of wonder and, frankly, something I have admired in them. That, to me, is fantastic software engineering. Bravo PH on that one along with everything else they have done.

4. To someone who is a non-coder, the video above is all gobbledegoop.

   My understanding is that Propellerhead’s RE Development tool in their SDK only takes care of a third of the process – (a) Blob creation. The process/task of (b) creating a GUI and then (c) “attaching” or “matching up” the module’s parameters to it – is – to a non-coder – clunky, complex and cumbersome. And the claim Propellerhead originally made – that the process of creating an RE takes little or no coding – was and remains misleading and not accurate.

   As far as (b) GUI design – I can layout and create GUIs in Adobe Photoshop all day long. But it doesn’t mean it is usable in the creation of an RE. And the GUI tools and creation process that Propellerhead describes in its Jukebox GUI Designer Manual and Jukebox GUI Design Guidelines is clunky and hard for a non-coder to understand clearly. The library of 3D parts they provide is very nice – but I do not understand the process of harnessing them to create a GUI. My understanding is that the GUI design process is one of building a coded script – and part of that script process is describing – in code – where the actual GUI widgets reside on the front panel – a completely arduous task. The 3D viewer that is included is just that – a viewer – and can only be used to review one’s script – and is not usable in the design process itself. It would appear that creating a GUI is an unnecessarily long process of trial and error – and necessitates designing the GUI in the abstract without the benefit of a “What You See Is What You Get” (WYSIWYG) environment. And I am not really clear about the 2D GUI design methodology at all.

   And so taking a Photoshop GUI design and converting it into something that can be used to create the actual RE – (by creating a script) and then (c) matching up the parameters to it – takes CODING – and that is where people like myself have a huge disconnect. I am not a coder – I am a visual person – and so trying to make sense of the process, and developing a GUI by using the method explained in Propellerhead’s Jukebox GUI Designer Manual and Jukebox GUI Design Guidelines is a stumbling block – and remains the main reason why I have no products in Propellerhead’s online store at this time. And it’s probably why out of the entire planet Earth – and the entire world of Reason Users (what is it – 100,000 people + or – ?) – only 150 people have been successful at creating only 500 REs.

   And Propellerhead has basically left people like me to their own devices when it comes to RE Development training and education. They have no online tutorials, no videos, no courses, no online or live seminars – no educational materials at all, save the ones that were created in 2012 – training and tutorial materials that are very poorly designed. As a training development professional myself – with a quarter century of hands-on career experience developing training programs for Fortune 500 global corporations in the Energy industry – I can kind of tell that the person who developed Propellerhead’s training materials was an engineer – a coder – like you – not a learning and development professional with instructional design knowledge.

   Why doesn’t Propellerhead have on its staff a true instructional designer (like myself) who creates LEARNING and TRAINING – not like those 90 minute “deep dives with Mattias and Ryan” that were created for the rollouts for Europa and Grain that are now on on YouTube – All that was accomplished was the creation of a useless promo video – not an actual course – because the final product is a 90 minute long rambling, stream-of-consciousness, run-on sentence with zero instructional design structure to it.

   What would have been most helpful to potential non-coding RE developers such as myself – would have been to have full-blown templates to use and modify – for example – a template of a 2-oscillator synth with a filter, two envelopes, a couple of LFOs etc – and with a GUI that already has the parameters matched up to it. And a couple of other templates, perhaps – for example – a drum machine template. And then simple, step-by-step instructions on how to modify them. A real view from “behind the scenes” and “under the hood.”

   Additionally – and eventually – what Propellerhead might want to consider – in addition to your web-based browser idea – is taking the RE Development tool one step further – and develop another screen in it where the user can actually design the GUI in a WYSIWYG environment. How difficult would it be to create an algorithm where the Gorilla Engine-based RE Dev tool looks at the Modules created in the Module and Mapping Editors – and then creates a rudimentary GUI in this new GUI Design screen that the user can edit and modify – perhaps with a library of customizable parts (knobs, etc) that the user can import, re-color and re-size? And this new GUI Design screen makes all the connections automatically between the GUI and the parameters – and then with a click of a button, outputs all the necessary scripts – Lua and otherwise – in the necessary folder and file architecture? So that all that is left to do is to run the “build_universal_45.py” script to generate the new “.u45” file” to test and upload to Propellerhead.

   THAT would be truly groundbreakingly clever and deserving of a pat on the back.

   As it stands right now, the GUI process is a stumbling block. Which is why I am sure the support of the RE has been lukewarm – especially by other major synthesizer manufacturers. Korg was the only major player to port over their products – and they stopped at two. No other major synthesizer MFG bothered to follow their lead. They all waited until Propellerhead acquiesced and adopted the VST standard. Perhaps – as you say in your talk, there were other reasons (no pun intended).

   As far as VSTs – I downloaded and looked at Steinberg’s VST SDK – to see how it was different and whether or not it was less complex than building REs – and it makes even less sense to me than Propellerhead’s RE SDK. It would appear that creating any kind of sound module – RE or VST – is a very complex task – especially if you have little or no coding background or experience.

   Propellerhead needs to hire an EDUCATOR as its next RE Product Manager. Someone (like me) who can EDUCATE people like me on how to develop REs.