The Further Combinator Suggestions

[moofi]

Very good idea

I’m sure someone has already suggested this, but I’m too lazy to sift through everything to check, but they should add the ability to import .png files right into the combi editor. we should be able to add artwork and custom labeling without needing to tediously size stuff in a photo editor.

[dan_g]

Is a "filmstrip" a specific technical device in the design/programming world? I don't understand what that would mean in Combinator terms.

Here's an example of a PNG strip of a knob with only 10 frames:

just had this thought "what is a film strip" to myself. is there some sort of software to achieve this easier than creating it by hand?

[Loque]

...is there some sort of software to achieve this easier than creating it by hand?

I was thinking about this too and a quick search brought this up:
https://www.g200kg.com/en/webknobman/gallery.php

[dan_g]

I was thinking about this too and a quick search brought this up:
https://www.g200kg.com/en/webknobman/gallery.php

whoa yeah. got this too with a search.

that would be really crazy if one could add own controls this way.

[tominator_66]

I was thinking about this too and a quick search brought this up:
https://www.g200kg.com/en/webknobman/gallery.php

The name of that webpage though...

[sdst]

Combinator need at least 500 knobs and bigger size

[zoidkirb]

Right click add parameter to combi is absent in RRP.

[nemesjs]

A "filmstrip" is just RS's name for a sprite sheet used for device controls (an image containing a bunch of animation frames).
I could see it working, though I'd be concerned about wasting disk space for controls shared by a bunch of patches.

Well, I've been thinking about your concern and in fact it is rather crucial. But to overcome it I think Reason Studios could host the new PNG strip user creations under their servers by giving each a proper ID and offer them to be used by all users without the need for replicating them on each Combi patch. Just like any web image storage service like imgbb.com for ex.

I was thinking about this too and a quick search brought this up:
https://www.g200kg.com/en/webknobman/gallery.php

whoa yeah. got this too with a search.

that would be really crazy if one could add own controls this way.

Well, this gave me an idea for more trickery on my part!
Just check this new video I just uploaded:

[avasopht]

I doubt they're done with the Combinator.

[Creativemind]

Allow the rotaries to display in the same measurements as the parameter within the Combinator do so a sync'd delay amount displays 1/8th, 1/16th etc.

[nemesjs]

I doubt they're done with the Combinator.

I have a bad feeling about what the combinator will have in the next iteration. I'm afraid it is going to be just more of the same ("more templates", more different knobs, more backgrounds) but nothing technically major will be implemented. I don't even believe the 32 knob count will increase... But maybe I'm wrong... let's hope so. I've been doing what I can to spur attention to animation of elements in the panel but none of it seems to be of interest to those who matter. One can clearly see it in the last video of Ryan and Mattias "Reason Combinator Livestream!" between minutes 43 to 50 where the lack of movement on the panel knob being fed a CV signal seems not to bother any of them and is not even mentioned but when you see the same CV signal sent to the Distortion RE the parameter 1 knob starts moving... I find that rather disappointing and majorly non intuitive. As I'm sure you know this knob odd behavior was implemented like that on the Combinator for years since it was first launched. But if you mapped it to an external controller then the knob moves! How did they implemented the movement of a knob from an external source but left it motionless when it comes from an internal CV? It baffles my mind... I am a dev. myself on another field of programming and I would never do that on what I develop - for me it's a major lack of consistency... it's unclear to users because you don't see feedback in some cases but on others you do???? Makes no sense to me and should have been addressed long ago.
I have also sent the list of suggestions I've collected here and in the Beta forum to the dev. team via e-mail thru the dev. channel to help them not need to scout the "webs" for the most referred ones. Because I love the Combinator concept so much I'm doing what I can to help show how it could be made to be the real power tool it's been promising to be. But it still needs a big push!

[Loque]

I doubt they're done with the Combinator.

I have a bad feeling about what the combinator will have in the next iteration. I'm afraid it is going to be just more of the same ("more templates", more different knobs, more backgrounds) but nothing technically major will be implemented. I don't even believe the 32 knob count will increase... But maybe I'm wrong... let's hope so. I've been doing what I can to spur attention to animation of elements in the panel but none of it seems to be of interest to those who matter. One can clearly see it in the last video of Ryan and Mattias "Reason Combinator Livestream!" between minutes 43 to 50 where the lack of movement on the panel knob being fed a CV signal seems not to bother any of them and is not even mentioned but when you see the same CV signal sent to the Distortion RE the parameter 1 knob starts moving... I find that rather disappointing and majorly non intuitive. As I'm sure you know this knob odd behavior was implemented like that on the Combinator for years since it was first launched. But if you mapped it to an external controller then the knob moves! How did they implemented the movement of a knob from an external source but left it motionless when it comes from an internal CV? It baffles my mind... I am a dev. myself on another field of programming and I would never do that on what I develop - for me it's a major lack of consistency... it's unclear to users because you don't see feedback in some cases but on others you do???? Makes no sense to me and should have been addressed long ago.
I have also sent the list of suggestions I've collected here and in the Beta forum to the dev. team via e-mail thru the dev. channel to help them not need to scout the "webs" for the most referred ones. Because I love the Combinator concept so much I'm doing what I can to help show how it could be made to be the real power tool it's been promising to be. But it still needs a big push!

The behavior with the CV is correct and makes sense. Combinator works inside via automation, thats why the knobs move.

If something is connected via CV, it's changing the signal comming from a control, so it cannot be reflected in the control.

[gullum]

I have a bad feeling about what the combinator will have in the next iteration. I'm afraid it is going to be just more of the same ("more templates", more different knobs, more backgrounds) but nothing technically major will be implemented.

totally agree for now combinator 2 is just combinator 1 with more controls to to the the same not so much new things

[nemesjs]

The behavior with the CV is correct and makes sense. Combinator works inside via automation, thats why the knobs move.

If something is connected via CV, it's changing the signal comming from a control, so it cannot be reflected in the control.

I understand what you are saying Loque but don't forget that a knob turned by hand on another controller (albeit an external one) mapped to a knob on a combinator also makes it turn, not only automation, as is so clearly demonstrated in my examples. There is no automation (recorded) but the knob moves! That is perfect in itself!

As to the CV signal not being appropriate to do this kind of digital control of a combinator knob rotational position I do understand that it has to be converted and I have no problem with that. The MIDI Out device already converts (virtual) CV signals ("analog") to MIDI CC Values (digital). So much so that I'd be happy enough to only have available in Reason a simple Virtual MIDI Router/Controller as an embedded resource to allow the following:



But this is not an elegant solution in my view. I'd rather like to have an option to convert CV inputs to MIDI CC values directly inside the combinator itself that could in turn be mapped to the panel elements via programmer/editor for example.

[Loque]

The behavior with the CV is correct and makes sense. Combinator works inside via automation, thats why the knobs move.

If something is connected via CV, it's changing the signal comming from a control, so it cannot be reflected in the control.

I understand what you are saying Loque but don't forget that a knob turned by hand on another controller (albeit an external one) mapped to a knob on a combinator also makes it turn, not only automation, as is so clearly demonstrated in my examples. There is no automation (recorded) but the knob moves! That is perfect in itself!

As to the CV signal not being appropriate to do this kind of digital control of a combinator knob rotational position I do understand that it has to be converted and I have no problem with that. The MIDI Out device already converts (virtual) CV signals ("analog") to MIDI CC Values (digital). So much so that I'd be happy enough to only have available in Reason a simple Virtual MIDI Router/Controller as an embedded resource to allow the following:



But this is not an elegant solution in my view. I'd rather like to have an option to convert CV inputs to MIDI CC values directly inside the combinator itself that could in turn be mapped to the panel elements via programmer/editor for example.

Ahain CV is modulation and not automation or accessing a controll via MIDI. Its the same as synth or fx internal modulation, its just accessible from outside AFTER your controll setting.

I giess you never thought about any synth which has internal modulation, that the controls should move according its modulation?

I agree that some visual feedback in the control of CV would be nice here and there, but moving the control makes no sense. You never could touch it again. Just look how automated controls work.

If you really feel the need to make the controls move via CV, use a MIDI loopback, which are available for free. This way you also can record CV and use it as automation for controls.

[bigguy1]

Spectrasonics introduces Sonic Extensions yesterday. And the patches which come with one extension have custom controls für every patch. Reminded me on the combinator in Reason.
Cool thing they have are so called scenes in every patch, which is a parametrisation of these custom controls. This would be very nice to have some sort of presets for complex combinators.

[Loque]

I want to create a custom display in the Combinator, that mirrors a custom display from an internal device, for displaying AND controlling.

This way i could for example map a envelope display or filter display.

[Loque]

Another anoying sh!t are the Reason limitations, like limited number of parameters and no automation of backside properties. Guess its time to remove those limitations or at least increase them or allow mirrored or hidden front parameters of the backside properties.

[Billy+]

I would definitely like to see RS go back through the entire collection of devices stock and RE's and make any and all controls available for automation.

First thing I tried was using retro tape to build a combinator but some controls are still not available without RS going back and fixing it in each device.

I'm not convinced that a display is going to happen especially as your probably going to want a custom one rather than just a mirror of the device that is being used.

Even though it's a bit gimmicky I think having a gif / strip like animated feature would be fun so you could have then stupid one knobs like dadalife etc as it seems to be all the rage at the moment.

[dusan.cani]

First thing I tried was using retro tape to build a combinator but some controls are still not available without RS going back and fixing it in each device.

I noticed this problem after v10 upgrade when I was creating combinator patches for Europa and I found that approx 50% of the controls are not available as the Target in the combi programmer. I don't understand this implementation at all. Why they omitted those parameters ? It's not possible to control such a basic things like ON/OFF for various sections, Envelope Loop and sustain ON/OFF, etc. All very important controls in regards of patch design.

[zoidkirb]

I guess the RE SDK is the real problem then? What we need is consistent behavior across every aspect.
That means every parameter of every device should be capable of right click, map to combi.

There's new devices from RS themselves, e.g. Mimic where about half of the parameters are automateable.
Sometimes you can't right click to add to combi yet you can still find the parameter in the combi matrix.
Sometimes the parameter can't be addressed by the combi at all but it can be addressed within it's own mod matrix. Can't right click and map parameters to combi out of vst's even when using the vst wrapper cv programmer.
Can't right click and map to genetic cv combi input.
Why even is there genetic cv inputs and combi cv inputs? Surely there should just be only combi cv inputs? And 32 to match the 32 available rotary controls.

Like I said....inconsistencies.

[Loque]

I know that the Combinator control mapping works via MIDI and its limited to 0-127, but i also know that a lot of controls of devices support much finer control. I wish RS would come to a solution to have that finer control via a C2 mapped control. I think this is like entering a specific number, e.g. "type 0.0123Hz" if the device supports it.

I guess the problem is here, that its MIDI and functions like a macro...i know other devices have similar problems with their own macro controls. I am curious how this is solved in other "building" environments like Kontakt?

[Loque]

What about a 360° knob?

[jam-s]

Another useful control would be a regular rectangular XY pad and a diamond shaped 4 source blending module (like we know from some famous synths).

[Tweak]

I'd like to be able to expose a chosen section of any of the underlying devices. Imagine being able to transparently add a custom control from an internal sequencer/player device, or the visualisation from an EQ directly to the front panel of the Combinator. You'd allow it to be interacted with as if it were on the actual device itself. You'd select what you wanted to display with a simple rectangular lasso tool.