Voluntary group for DAW improvements

[deeplink]

Probably will take more effort for RS to coordinate, integrate and secure, than to actually produce new work.

I recall RS was looking for some backend devs with C knowledge, perhaps it's better to apply to a position officially.

[Loque]

Probably will take more effort for RS to coordinate, integrate and secure, than to actually produce new work.
...

This.

[jam-s]

Adding extensive and deep Remote support for many hardware controllers including good default maps for all REs could be done as a collaborative effort using a common git repo and a permissive license (e.g. CC-0 aka public domain). That way RS could even include the mappings later on into new Reason releases.

[Tweak]

Adding extensive and deep Remote support for many hardware controllers including good default maps for all REs could be done as a collaborative effort using a common git repo and a permissive license (e.g. CC-0 aka public domain). That way RS could even include the mappings later on into new Reason releases.

A most excellent suggestion, I second this.

[moalla]

[bxbrkrz]

"Voluntary" is the name of an unfaithful time vampire diva you cannot trust.

[fullforce]

Adding extensive and deep Remote support for many hardware controllers including good default maps for all REs could be done as a collaborative effort using a common git repo and a permissive license (e.g. CC-0 aka public domain). That way RS could even include the mappings later on into new Reason releases.

Ok, what started out as a bad idea, has now turned into a GOOD idea. I like this thought, but other than that, I don't see it happening, you can't have "volunteers" just messing about with your code.

[avasopht]

Adding extensive and deep Remote support for many hardware controllers including good default maps for all REs could be done as a collaborative effort using a common git repo and a permissive license (e.g. CC-0 aka public domain). That way RS could even include the mappings later on into new Reason releases.

Ok, what started out as a bad idea, has now turned into a GOOD idea. I like this thought, but other than that, I don't see it happening, you can't have "volunteers" just messing about with your code.

Bitwig makes use of user-made scripts.

The open-source model seems to work best when tech companies are their users.

Of course, you don't want *volunteers* messing with your code, but it could open the door to pull requests that do fix problems. It could come from a Rack Extension or VST developer that just wants to see a particular change.

I happen to know a few Reason developers who are programmers - one of which is a world-class graphics programmer (currently for Sony, but has worked on many games as a contractor).

You'd be surprised how much assistance you can get from the world's best by just asking on Twitter.

Having worked with some of the top graphics programmers, it's fair to say that there is a huge gap between highly competent developers and the most skilled graphics programmers. There are decades of learned knowledge and experience with various GPU nuances.

I also know from experience that it can be hard to integrate one's knowledge without getting more deeply involved - so it could go nowhere.

I can't help but feel it wouldn't hurt, but then if it were that simple ardour would be creaming with features

[Tweak]

I had other thoughts about how the community could collaborate to improve the tool, but it would need support from RS with a new feature.

I'd like Reason to introduce macros, so that the action of hooking up two or more devices can be recorded outside of needing to save them as a patch in a combinator. If macros could be played back after recording them, you could save a wide variety of shortcuts to create useful sections of connected devices. Allow macros to be sharable and editable by others and you've got a powerful way for people to collaborate on workflow related things.

Imagine being able to select a Redrum and a Kong, use a right-click menu, and choose "Connect all gate CVs" to have the all the Redrum CV outs connect to Kong's CV ins, or to select a Kong, right-click and choose "Create mixer channels for all outputs" to have every separate Kong output channel route to a new mixer channel. There are hundreds of things I use frequently like this that could be automated and added to a menu system or bank of macros.

[Aosta]

I wonder how Reason would progress if RS one day just gave away the code to make it open source

[fullforce]

Bitwig makes use of user-made scripts.

The open-source model seems to work best when tech companies are their users.

Renoise is like that, there's hundreds of little coded tools, I think they do it in LUA. I'm not a programmer so I'm out on a limb here, and I don't even use those tools (some of them look like overcomplicated combinator like things) but yes it's definitely an asset.

[BRIGGS]

I wonder how Reason would progress if RS one day just gave away the code to make it open source

Like Linux or Android, we could have different flavors of reason.

[Tinnitus]

Adding extensive and deep Remote support for many hardware controllers including good default maps for all REs could be done as a collaborative effort using a common git repo and a permissive license (e.g. CC-0 aka public domain). That way RS could even include the mappings later on into new Reason releases.

A most excellent suggestion, I second this.

Of course, Pooh Bear has been doing this for years for the nektar controllers ( and such a good job too).

[iTrensharo]

Hey, I understand that a company has limited financially and personal capabilities, so, what do you think about some voluntarily group, which might help closing the gap to a better DAW for some months?

Good idea, stupid idea?

The group or the persons could do graphics, code or concept work - all coordinated in some way by a RS guy a bit. Even if its just one hour per week.

What do you think?

It would take RS a decade to "close the gap" at this point.

The key to keeping up with those other DAWs was active development in the areas where the DAW needed to grow out to keep pace with them.

Once you fall so many years behind, it probably isn't worth trying to catch up. That doesn't mean they shouldn't address the needs of their customers. It means "catching up to Cubase" shouldn't be an end goal because it's a practical impossibility at this point. They simply don't have the resources to do it quick enough - even if competitors stopped developing their DAWs (read: "adding features") for a few years.

This is why companies like Avid, MAGIX, etc. aren't trying to turn their DAWs into MIDI Composition powerhouses. The development pace of those products have already basically niched them to the point that they have now garnered users from specific market segments and the work needed to "bridge" the gaps to make their DAW attractive to those who gravitated towards competitors is simply too vast to bother, at this point.

Users are always going to dream about their preferred DAW becoming an end-all-be-all for everyone, but IMO the work to get there needed to be don in the 2005-2015 time frame.

The only DAWs that have been successful at developing up quickly were those that were developed much later (Studio One, Bitwig), and users still stay on established DAWs due to feature disparities and a lack of willingness to change and endure substantial learning curve or opportunity cost in migrating between DAWs. Also, those DAWs have done well becasue they were strategic in targeting development at areas of highest interest.

[iTrensharo]

A most excellent suggestion, I second this.

Of course, Pooh Bear has been doing this for years for the nektar controllers ( and such a good job too).

It's fine if you use a Nektar Controller - like a Panorama - with a larger screen that tells you what is mapped to what. For using other controllers (Launchkey MK3, Oxygen Pro, etc.) I just don't use the controller with Reason because the way things are mapped is not logical and doesn't really lend itself to operational efficiency.

I really just want mixer control out of the box similar to what other DAWs offer, and device parameters should only be touched if I switch the Faders or Rotary Knobs to Device Mode.

I just... really dislike how these controllers are mapped for Reason.

I do like that they have full MIDI Implementation Documentation available. That can make building Preset Maps for different controllers easy - for mapping different Reason Devices/Synths. More DAWs should do that.

Also, none of the knobs or Faders on any of my controllers pick-up in Reason, but do in other DAWs. So, they're basically unusable for that reason. I'd spend too much time fixing parameter jumps.