The Super Combi Explained

Have an urge to learn, or a calling to teach? Want to share some useful Youtube videos? Do it here!
User avatar
Raveshaper
Posts: 1089
Joined: 16 Jan 2015

Post 28 Jun 2015

There has been a lot of discussion recently about the desire for an update to the Combinator. Requests have been made for an overhaul, for new features, and for extensive new capabilities. Opinions and attitudes vary, but overall they lean toward "would be great, but probably won't happen."

Wrong. It just did.

This is not an official release announcement from Propellerhead themselves, but rather a homebrew solution that allows you, the independent user, to build and shape a new way of working in the Rack that is exactly the way you want it once you set it up.

The way this works is very simple. It is the starting point that you can build off of to craft your own highly specialized production tool for your future projects. Here is how it works.
  • Download the attached Zip file, extract anywhere.
  • Place the folder "MIDI Node Beta\Remote\Lua Codecs\Raveshaper" into Reason's "Remote\Lua Codecs" directory.
  • Place the folder "MIDI Node Beta\Remote\Maps\Raveshaper" into Reason's "Remote\Maps" directory.
Here is Propellerhead's instruction on locating those directories:
Propellerhead Software wrote: OS X
Macintosh HD/Library/Application Support/Propellerhead Software/Remote
Windows Vista/Windows 7
C:/Program Data/Propellerhead Software/Remote
Windows XP
C:/Documents and Settings/All Users/Application Data/Propellerhead Software/Remote
Please note that on Windows, the files are stored in hidden folders, so youʼll have to go into the Folder and Search Options of Windows Explorer and make sure that “Show hidden files, drives and folders” is selected, in case you havenʼt done so already.
  • Open Reason.
  • Go to "Edit > Preferences > Control Surfaces > Add".
  • Select "Manufacturer > Raveshaper".
  • Select "Model > MIDI Node Beta".
  • Configure the in port and out port to use the physical or virtual MIDI port you will be using to achieve MIDI loopback.
  • Open the Reason song file "MIDI Node Beta Test.reason" included in the Zip.
  • Configure the External MIDI Instrument's output to use the same physical or virtual MIDI port you are using for loopback.
You're now ready to start making devices and connecting them using the surface script.
To connect two controls together, follow these steps:

  • Right-click the first control (which will act as master).
  • Select "Edit Remote Override Mapping... > Control Surface > Raveshaper MIDI Node Beta".
  • Choose your desired source ("Src") control from the "Control" dropdown menu, example: "Src 1".
  • Right-click the second control (which will act as slave).
  • Select "Edit Remote Override Mapping... > Control Surface > Raveshaper MIDI Node Beta".
  • Choose the destination ("Dest") control from the "Control" dropdown menu that has the same i/o number as the source "Src" control, example: "Dest 1".
  • Move the first control and the second control will also be manipulated.
If both controls do not move, go back through the configuration steps to make sure you didn't miss anything, and check in "Options > Remote Override Edit Mode" to make sure you're moving the right controls before you start ripping your hair out (like I do).

What this basic script allows you to do is create something that I'm calling "branched automation". Basically, you can automate a single control on a device, but then create a network of other controls that respond to the current state of the automated control. Imagine synchronized manipulations of multiple device controls that only require the original automation lane in order to happen. The cpu priority that would be given to the sequencer to analyze and carry out all of those automation lanes is prevented from occurring and is instead deferred to the much more sparse and quick to execute surface script(s).

I say "script(s)" because you can load in multiple instances of this script if you want/need more i/o, or have made different modded versions of it that each have special behaviors.

I know some of you are probably saying that this is too difficult and is counter productive when put into practice. But let me counter that by saying you can do nearly anything you want using this approach, whereas the Combinator trades off possibilities in favor of graphic interface. Let me put that another way:

Using this method allows you to learn new ways of working in Reason that no one has ever used before. The limits of mathematics, modern devices, and your own creativity are your only obstacles.


You can mod this so one control spiders out to sixteen, you can expand its capabilities to include support for multiple MIDI channels, notes, velocities; almost anything you want to do in terms of controlling the front face of devices, you now have the power to do. It's in your hands.

Tell me what you think, tell me if it's awful and I'm full of myself, discuss!
You do not have the required permissions to view the files attached to this post.
:reason: :ignition: :re: :refillpacker: Enhanced by DataBridge v5

User avatar
Raveshaper
Posts: 1089
Joined: 16 Jan 2015

Post 28 Jun 2015

I should point out that no data is being sent through the MIDI loop at all. The midi loop is what determines the polling rate of the script, as determined by the free rate of Mod A on the Malstrom. All data is extracted from the "Src" controls, stored in global variables, compared with the previous data record, and sent back into Reason using the "Dest" controls if the two records don't match. At that point, the data that was just sent is recorded to the previous data record and during the time that the two records match the data is latched (nothing happens).
:reason: :ignition: :re: :refillpacker: Enhanced by DataBridge v5

sdst
Posts: 875
Joined: 14 Jun 2015

Post 28 Jun 2015

interesting thanks,  it gave me an error  I think i better wait.  :)

maybe because I'm with reason essentials

User avatar
Raveshaper
Posts: 1089
Joined: 16 Jan 2015

Post 28 Jun 2015

What error did you encounter? The file was made in Reason 7.1.1 and saved on PC in NTFS format. Are you on Mac?
:reason: :ignition: :re: :refillpacker: Enhanced by DataBridge v5

User avatar
Raveshaper
Posts: 1089
Joined: 16 Jan 2015

Post 28 Jun 2015

Nevermind, I see you're running Essentials.

Well, one more reason to get the full version I guess. Good to know.
:reason: :ignition: :re: :refillpacker: Enhanced by DataBridge v5

User avatar
FGL
Posts: 330
Joined: 23 Jan 2015

Post 29 Jun 2015

I don't get it. To make some Knobs or Buttons that control multiple Parameters is not really a problem. If something is really needed IMHO it is better adjusting of Parameters like in the Example from Selig:

http://www.reasontalk.com/post/show_sin ... stcount=26

Or some more Button and Knobs like some others suggested. Or some more programming slots with a little more flexibility.

Or did I understand wrong what you are trying to do?


User avatar
Raveshaper
Posts: 1089
Joined: 16 Jan 2015

Post 29 Jun 2015

This makes it possible to supplement or even eliminate the presence of the combinator.
It also makes what Selig posted possible.

The complexity of this method is only as limited as your skill in utilizing it. That's the beauty of it.
You can modify it and make it suit your needs in whatever way you like within the limitations of Remote.
A fully DIY alternative to the combinator, basically.

Rather than mapping a combi control to a nested device, this method allows you to map a control on one device directly to a control on another device.
It isn't one control controlling many devices (unless you want it to), it's literally device-to-device communication. Changes in one cause changes in the other.

The amount of these changes can be scaled or processed in whatever way you want. They can respond only to certain ranges of value exactly as you specify. It's all up to you to define it.

While there is no way of visualizing what you're doing and it is mostly mathematics and scripting at work, what you gain is nearly unlimited mappings and device-to-device i/o.
The shortest explanation I can give is that the combinator is a single instance of a device, whereas this method turns all devices in the entire rack into one giant network whose behavior resembles the combinator, but whose full capabilities dwarf what can be done in a combi.

Does that make sense?

Edit: I'll have to make a video about this I guess.
:reason: :ignition: :re: :refillpacker: Enhanced by DataBridge v5

User avatar
FGL
Posts: 330
Joined: 23 Jan 2015

Post 29 Jun 2015

A Combinator gives me more Control Buttons and Knobs. So for me it is not about control many things with one Knob. In my Opinion it is about easy comfortable Control. And it would be nice if I could do this a little more accurate and more comfortable

And alsocan stack as many Devices I want very easy inside reason with and play them like one Instrument thats no Problem. If I use something like the Mixer, Modpanel or Alias 8 or the cheap Ouadelectra Stuff I would have even more control and this very easy.

What most disturbs in estates but are actually the load times and therefore I find are the Re instruments the better way.

I would plead for a simple user Open RE Instrument.


  • Information
  • Who is online

    Users browsing this forum: CommonCrawl [Bot] and 0 guests