What about the super combinator?

[selig]

Here are a few of my Combinator suggestions.

Combi knobs can't send CV, so that's something I'd add. Four CV outs on the back should do it, one for each knob. 

I would also add CV I/O to the back of the rack that you can label so you can build Combinators that use external CV inputs and be able to plug these in (just like the main audio I/O) without opening the Combi. 

Additionally, I'd like to be able to sum Combi controls internally. Why? So that multiple sources can control a single destination. As it is, the Combi controls the KNOB, which of course can only be in one position at a time - two sources will "fight" for control. But if you sum the signals first, THEN send them to that knob all will be well. 

I'd LOVE some simple metering available on the front panel so you can bring internal displays to the front panel in some form.

And FINALLY, a very long time ago I suggested these on every programmer slot:

[electrofux]

I would just like double the number of rotaries, buttons and CV-Ins. But i doubt we ever see an update on any legacy device :/

[Hydrosonic]

Don't bother asking Props to do it, they are far to head in the sand and stuck in the mud to bother. 

Remember that little thing called backwards compatibility, yeah that rule kicks into play on this.
Also bear in mind that Props won't release anymore legacy devices only REs now, so if they could do it so could any other Dev

In all honesty PH have lost the plot along with all my faith in them.

[Grinder One]

I would just like double the number of rotaries, buttons and CV-Ins.

Exactly this. Combinator was designed many years ago, long before RE's and I used to run out of rotaries even back then.

Mart.

[ncurry]

Remember Dr. OctoRex? I think it's possible that Props could come up with a solution that would allow for backwards compatibility, but offer new possibilities for further customization. I haven't given up hope yet.

[jappe]

If we really want more knobs and/or more buttons in the combinator, I think that can be arranged, sort of:-)

Years ago, I experimented with dividing one knob into several intervals, and implementing a switch mechanism to have the different intervals control different things, using a button as an enter button.
Tbh it was so long ago, I have cached it out from my tiny brain so I don't remember details here. But I used subtractors to generate sine waves, and a BV-512 connected to the devices to control with the knob sections. Sweeping the sine wave from low to high would then cause the signal to be switched between the band level outputs of the BV-512.

I actually had a problem that was a showstopper for me at the time; vaguely remembering it as a CV polarity problem.

Perhaps someone wants a good friday therapy work, and can do what I didn't finish:-)

[jfrichards]

I support this only because everyone else seems so passionate about it, but I have no idea how people need more than 4 knobs to modulate a sound. Have you guys tried lumping parameters together? I can't imagine separately automating 4+ knobs that each do something different. At that point I'd rather just make separate devices!

In designing the X-Wah with Giles, we came up against the limits of the Combinator fairly quickly, and had to invent a workaround converting knobs into switches.  Yes, you could make such a setup with separate devices and wire them up differently as needed, but the Combinator is supposed to reduce back-of-the-rack tweaking, making complex things simple for the user.  The X-Wah would easily benefit from more knobs and switches, like for EQ filtering tailored to single-coil vs humbucker input signals, adding envelope-generated wah (auto-wah), adding Fuzz types, etc.

 

https://www.dropbox.com/s/9rqujm8qtnndl ... h.cmb?dl=0

I have hit the CV in limit of 4 numerous times also where I wanted to have more than 4 CV signals be available in the programmer for routing, and for adjusting on the front.

Maybe an expanded Combinator is in conflict with the Rack Extension philosophy, where money is to be made?  Just groundless speculation here.  Although I'd love to see a monster wah Rack Extension, with curve adjustment.

[PadShifta]

Hi all!

A new Combinator would be awsome. But what I often want to do is, to combine two or three combinators into one combinator without rerouting dozens of devices along with their fx-chains ect.ect....

To simply highlight all of the desired combis and select "combine combis" or "merge to one" from the right-click-menu and Voilá, you have combined a couple of combis in no time at all. I´ve been wishing for this option for a loooong time now and I think we could all benefit from it in terms of workflow.

No need for combinators inside of combinators in my opinion. Just give us the option to weld 2 or more combis together and we´ll be all good.

Andy

[normal]

In a similar vein to the welding idea above, I could imagine a CV in/out to daisy chain one(or more) combinators together, having the master's devices appearing in the slave's mod routing panel, allowing you to continue routing assignment, but without the need to create new assets(other than the aforementioned CV in/out, and perhaps icons denoting the 'Master', 'Slave 01', 'Slave 02', etc., relationships).

Ugh, I just realized that would complicate patch saving, unless saving the Master would also save its subordinates, but then it seems complicated to a point that a redesigned, expanded combinator would be the best course of action altogether. My attempt to contribute to this topic seems to have come up empty-handed; my apologies.

[sdst]

the combinator is reached its limit, I want this

 

[jfrichards]

Yes, yes, yes.  And with a right click menu item added for Track Color which changes the faceplate to whatever track color you choose.

[A.Skelton]

 

[selig]

I'm going to (continue to) go a different direction here, as I have long wanted a simple customizable interface for Combinators rather than trying to put all the things one 'might' need into an interface (and end up with more NOT being used than used IMO). Another issue with a full "preset" interface is the lack of ability to organize things logically for each concept/device you build.

At the simplest, you would drag basic knobs, buttons, sliders, and displays to the empty front  panel. At the most complex, you could choose to create an "alias" of any existing knob/slider/display etc. in Reason (not including custom RE controls, of course) and place it on the front panel any where you want. 

There should also be support for MIDI scripting, control merging so you can control a single destination from multiple sources (not currently possible), and more sophisticated programmer options to allow (among other things) non-linear control mapping.

[joeyluck]

I'm going to (continue to) go a different direction here, as I have long wanted a simple customizable interface for Combinators rather than trying to put all the things one 'might' need into an interface (and end up with more NOT being used than used IMO). Another issue with a full "preset" interface is the lack of ability to organize things logically for each concept/device you build.

At the simplest, you would drag basic knobs, buttons, sliders, and displays to the empty front  panel. At the most complex, you could choose to create an "alias" of any existing knob/slider/display etc. in Reason (not including custom RE controls, of course) and place it on the front panel any where you want. 

There should also be support for MIDI scripting, control merging so you can control a single destination from multiple sources (not currently possible), and more sophisticated programmer options to allow (among other things) non-linear control mapping.

Or maybe instead of dragging, users could change modules like Thor... 

But I agree, too much is too much. 

[A.Skelton]

Giles I do agree with a lot of what you say.. I think MIDI scripting would be great. But maybe If props built a separate utility like in a "recycle style" , but specifically for building custom combinator style devices. Then this device can be filled with presets and locked. ready for use in the reason rack. If we had that with a Reaktor style "add and drag knobs and sliders as you need them" to the interface... Possible way of going about it?? 

[sdst]

I like the way of putting singles knobs and buttons. and changing the background as now. 

[Exowildebeest]

I'm going to (continue to) go a different direction here, as I have long wanted a simple customizable interface for Combinators rather than trying to put all the things one 'might' need into an interface (and end up with more NOT being used than used IMO). Another issue with a full "preset" interface is the lack of ability to organize things logically for each concept/device you build.

At the simplest, you would drag basic knobs, buttons, sliders, and displays to the empty front  panel. At the most complex, you could choose to create an "alias" of any existing knob/slider/display etc. in Reason (not including custom RE controls, of course) and place it on the front panel any where you want. 

There should also be support for MIDI scripting, control merging so you can control a single destination from multiple sources (not currently possible), and more sophisticated programmer options to allow (among other things) non-linear control mapping.

Striking a nice balance between easy and deep, between Appleish and Reaktorish, is what's needed - luckily, that's what Propellerheads is good at (not counting Kong and the MIDI out device where they've missed that sweetspot imo).

So it's a fair bet that some of the cool things we want for the next Combinator will be implemented, including possibly some sort of modularity. But non-linear control mapping and other obscure features don't seem like something they would fit in there without making it too complex.

The one thing I don't hope is that they play it easy and just add a few more knobs and sliders. That would be adding of quantity, not quality.

[esselfortium]

I'm going to (continue to) go a different direction here, as I have long wanted a simple customizable interface for Combinators rather than trying to put all the things one 'might' need into an interface (and end up with more NOT being used than used IMO). Another issue with a full "preset" interface is the lack of ability to organize things logically for each concept/device you build.

At the simplest, you would drag basic knobs, buttons, sliders, and displays to the empty front  panel. At the most complex, you could choose to create an "alias" of any existing knob/slider/display etc. in Reason (not including custom RE controls, of course) and place it on the front panel any where you want. 

There should also be support for MIDI scripting, control merging so you can control a single destination from multiple sources (not currently possible), and more sophisticated programmer options to allow (among other things) non-linear control mapping.

This would be ideal!

MIDI scripting, if I'm understanding your meaning correctly, would be fantastic for things like keyswitching (currently doable to a limited degree via Thor) and custom scripted articulations as seen in Kontakt instruments, where sequences of MIDI events can trigger a programmed event (for instance, guitar slides being auto-replaced with a sample of a slide between the designated notes).

I think a system like this could be far more attractive than IDT, both for the ease of development and for the ability of power users to customize the patches they own, like they can with any of the stock patches in Reason.

Another thing I'd really like to see is a way for Combinator patch sets with matching controls (for instance, many of Tom Pritchard's combis that have consistent programming for ADSR, arpeggiator toggles, etc.) to be able to remember user-modified controls when changing patches. If I'm browsing the arps folder and I've turned off the arpeggiator in favor of my own sequencing, for instance, it gets really clunky having to toggle the button off again every time I audition another patch. So it'd be super great if, when switching patches, it could optionally check for matching parameter names and preserve their current values if I've changed them from the patch's defaults.

Now that I think of it, I feel like some sort of "sub-patches" could be the most user-friendly way to handle the above issue, so you would set up your backdrop, buttons/knobs, and any other consistent pieces in one place rather than having them duplicated in every patch (which becomes a nightmare if you need to change them all later). Sub-patches could swap out the devices within, but have some or all of the programming mapped to the same controls as their mother patch.

Another killer feature, while I'm dreaming, would be the ability to virtualize Distributor-like behavior to make a subset of the signal chain behave as entirely polyphonic (i.e. a single Subtractor routed to a single Scream4 would behave as multiple virtual Subtractors and Scream4s, so each voice is being distorted individually).

As an aside, the Combinator knobs and buttons (especially the buttons) are kind of hideous and I've always wanted to be able to reskin them, or at least pick from some better options.

[Lunesis]

I think I'll put this in the main forum, just because I think it would need to be a core feature if anything.

[Gorilla Texas]

IMO it's time to really think outside the box because some of these ideas on this thread is primitive to what else is out there. First,I would love this new combi to get rid of the whole cable paradigm and replace it with an more  clear intuitive signal path design like S1 multi-instrument. Even after just one video of  NI massive the signal flow is very easy to understand imo,far easier to understand than thor's matrix this just my opinion. I know massive is a synth but I like that you have the ability to set macro's in massive that control knobs, faders etc..and control them from midi. Not to mention the control you have with vector automation. 

PH really fell behind imo and need to work hard to catch up.

[Raveshaper]

The concept of a super combinator is possible to achieve, theoretically, through the use of analog loopback in combination with Remote. I have approached avasopht about collaborating on such a project, although both of our schedules prevent us from diving into such a demanding build at the moment.

The trade offs are obvious, such as latency introduced into the process, hard-coded parameter ranges, and the necessity of understanding code well enough to make manual edits to get desired results. But still, it is a very powerful concept that has yet to be explored.

Rather than focusing on the contents of a single container device, this approach using Remote/EMI focuses on creating relationships between multiple devices (including combinator instances).

For those who are tech savvy in Remote, this is the gist of how it would work. Create two sets of remote overrides: one set is defined in the map file and is automatically assigned during surface lock to device, the other is left undefined in the map file and allowed to be bound to any control in the rack. Use globals to store the state of each override that responds to surface lock, then ferry the data of each to its freely assignable counterpart.

If you want to get even simpler, make a bunch of remote overrides, only check the state of half of them, then sends the states of those items as inputs using the other half. Use an empty map file and freely assign all overrides wherever.

Maybe I should just type it up and post it here.
It's incredibly powerful. I can't believe no one has tried this. Although, it's nowhere near as easy to use as something with a GUI.

[Gaja]

@gorilla texas
Getting rid of cables is precisely not what they should do imo. I'm not bashing your post, but really, since the cables are Reasons main selling point (because it's much more intuitive than drop down menues), it would be disastrous to discontinue that feature.
The programmer section of the combinator could certainly use an upgrade, if only for more slots, but it might have another button that unfolds a node style routing matrix (if that is possible at all).
Since they did upgrade the Reverb, I'd say they might actually have a plan for upgrading the old devices. They upgraded the dr.Rex, the combi and now the RV7000, so it might not be unplausible to believe in internal device upgrades, as upgrade options. With this 8.3 upgrade they even prove they're willing and able to upgrade core devices and generously shell out the upgrade for free.
But I agree, they'll have to work hard, which seems like exactly what they've been doing these last years.

[Gorilla Texas]

@gorilla texas
Getting rid of cables is precisely not what they should do imo. I'm not bashing your post, but really, since the cables are Reasons main selling point (because it's much more intuitive than drop down menues), it would be disastrous to discontinue that feature.
The programmer section of the combinator could certainly use an upgrade, if only for more slots, but it might have another button that unfolds a node style routing matrix (if that is possible at all).
Since they did upgrade the Reverb, I'd say they might actually have a plan for upgrading the old devices. They upgraded the dr.Rex, the combi and now the RV7000, so it might not be unplausible to believe in internal device upgrades, as upgrade options. With this 8.3 upgrade they even prove they're willing and able to upgrade core devices and generously shell out the upgrade for free.
But I agree, they'll have to work hard, which seems like exactly what they've been doing these last years.

I hate the whole cable system now you need total recall memory for old complex combi's or you'll be spending hours going through endless spaghetti in the back of the rack. How long does it take for most users to understand the signal flow of most presets or advanced refills? Imo the cable system and the old school matrix modulation slots is a hindrance and adds confusion, it's probably the main factor that so Reason users say they don't even try to sound design.

I know they won't change it though.

[Gaja]

Funny.
For me the cables are part of what makes reason intuitive.
Without the cables Reason is not Reason anymore, and I could switch to another daw as well.
I never had to spend hours so far going through endless spaghetti, because I remembered setting it up. Minutes have always been enough.
Of course many don't actively use complex routings, but take advantage of refills, which utilize it extensively, and don't care to find out how it works.
But if they really want to, cables imo offer a convenient way of finding out what's happening.
Anyway, to each their own and I'm sure props won't drop the rack paradigm anytime soon, as it is their unique selling point.

[Raveshaper]

Ok...

So I went ahead and typed up a very rough first draft of the method I was talking about.
It uses remote override pairs to create 128 i/o between devices. Multiple instances of the surface can be loaded at one time for more advanced i/o schemes.

The proof of concept is very basic, where the manipulation of each source control is reflected in its destination control. More advanced behavior would be easy to achieve, including but not limited to summing/merging, shaping, multiplexing/spidering, inverting, and arithmetic relationships between bindings.

The script requires a MIDI controller with analog loopback to function.
Inside Reason, you must send information out of the EMI to make this trickery possible. You will need:

Malstrom, Mod A set to sine with fastest free rate, Mod B set to final waveform type, any rate
CV Merger, Mod A scaled to 62, Mod B scaled to 63
EMI, CV Spider sent into Assignable CC, CC Assign set to on, CC number set to 119.

This will spam the MIDI in port with the offset sinewave, assuring no dropouts, so that the surface script can analyze changes in global variables in (more or less) real time.

What this means is you can now automate only one knob, then use this script to build very powerful systems of "branched automation" -- automatic behavior that is manipulated by the original control being automated, but does not itself require its own automation lane. Due to possible conflicts between types of controls, there could be unforeseen crashes of the script. But most likely this will be of minimal concern.

Anybody want to try it? I can create a new thread for it.