Reason 10.3 public beta is open!
-
- Posts: 155
- Joined: 18 May 2016
Does anyone know the release date of Reason 10.3 ? That's not a secret, I hope ?
Mid of April.Michaellos wrote: ↑28 Mar 2019Does anyone know the release date of Reason 10.3 ? That's not a secret, I hope ?
Reason12, Win10
when did they say mid-April? I thought they just said April... must’ve missed something.Loque wrote: ↑28 Mar 2019Mid of April.Michaellos wrote: ↑28 Mar 2019Does anyone know the release date of Reason 10.3 ? That's not a secret, I hope ?
Mattias said mid April on Instagram yesterday.
We could talk about what i think about that, but i think that's for other threads.Blast wrote: ↑26 Mar 2019Mix Engineer Andrew Schepps uses a lot of parallel processing (aux sends) in his mixes, and his mixes are BADASS. Attempting that style of mixing in Reason can get too cumbersome easily with only 8 sends, and or just using parallel channels, more so with no easy way to set up a template.I do understand the need for more aux sends(pre/post fader) on Reason's SSL channel which will make the work flow a lot easier for anyone who wants to persuit this style of mixing.
That being said, if you want to apply his approach to parallel compression, you can using the double group for post fader group parallels as i showed in my previous reply to Gullale - it really does work and it's not that messy. I can understand stems are not the best solution because of automation and the second group workaround "respects" the base group and original channels automation.
Hopefully Propellerheads will allow us to define post fader parallels in the future (and/or infinite sends, though in the context of the SSL mixer, that will be messier imho).
Cheers,
MC
Good news!!! A tad more than half a month!
I’m not sure if everyone is aware of this way of working, something Pro Tools users have been doing for decades now. By using sends instead of mix buses/parallel channels (both of which are possible in Pro Tools) you control the MIX of elements going into the parallel processing.mcatalao wrote: ↑28 Mar 2019We could talk about what i think about that, but i think that's for other threads.Blast wrote: ↑26 Mar 2019Mix Engineer Andrew Schepps uses a lot of parallel processing (aux sends) in his mixes, and his mixes are BADASS. Attempting that style of mixing in Reason can get too cumbersome easily with only 8 sends, and or just using parallel channels, more so with no easy way to set up a template.I do understand the need for more aux sends(pre/post fader) on Reason's SSL channel which will make the work flow a lot easier for anyone who wants to persuit this style of mixing.
That being said, if you want to apply his approach to parallel compression, you can using the double group for post fader group parallels as i showed in my previous reply to Gullale - it really does work and it's not that messy. I can understand stems are not the best solution because of automation and the second group workaround "respects" the base group and original channels automation.
Hopefully Propellerheads will allow us to define post fader parallels in the future (and/or infinite sends, though in the context of the SSL mixer, that will be messier imho).
Cheers,
MC
I know this was already explained earlier as the reason parallel channels won’t work regardless of where they tap their signals, but just wanted to clarify here. For example, if you use a parallel channel or a bus channel, the mix you get is the same for the parallel processing as for the “dry” path. Some prefer to be able to change the balance of the individual drum elements for the parallel processing, maybe increasing the snare a bit, pulling down the hats, etc.
Personally, after trying this approach may times years ago I found it quicker to adjust my parallel processing to correct any imbalances - but I still respect other folks’s desire to use this mix approach. My only confusion comes from wondering why they use Reason if this is important to their work?
Also, Reason doesn’t need more than 8 sends - Pro Tools only has 10 sends per channel. What Reason would need is more Aux Busses. This would be easier to add than more sends, but one thing you’d have to include is the ability to name the bus and see the name under each send, since with this approach you no longer have a 1:1 relation between the send position (send 1, send 2, etc.) and the effect that is receiving it.
The other Pro Tools feature you may want to add to Reason, which would greatly speed up the workflow in some cases, is “copy faders to sends”. This would allow you to quickly duplicate the channel balances of a group of faders on sends, for cases where you need pre-fader sends.
Selig Audio, LLC
awesome! didn’t see that.
Its great to learn things with you and i might have misinterpreted.selig wrote: ↑28 Mar 2019I’m not sure if everyone is aware of this way of working, something Pro Tools users have been doing for decades now. By using sends instead of mix buses/parallel channels (both of which are possible in Pro Tools) you control the MIX of elements going into the parallel processing.mcatalao wrote: ↑28 Mar 2019
We could talk about what i think about that, but i think that's for other threads.
That being said, if you want to apply his approach to parallel compression, you can using the double group for post fader group parallels as i showed in my previous reply to Gullale - it really does work and it's not that messy. I can understand stems are not the best solution because of automation and the second group workaround "respects" the base group and original channels automation.
Hopefully Propellerheads will allow us to define post fader parallels in the future (and/or infinite sends, though in the context of the SSL mixer, that will be messier imho).
Cheers,
MC
I know this was already explained earlier as the reason parallel channels won’t work regardless of where they tap their signals, but just wanted to clarify here. For example, if you use a parallel channel or a bus channel, the mix you get is the same for the parallel processing as for the “dry” path. Some prefer to be able to change the balance of the individual drum elements for the parallel processing, maybe increasing the snare a bit, pulling down the hats, etc.
Personally, after trying this approach may times years ago I found it quicker to adjust my parallel processing to correct any imbalances - but I still respect other folks’s desire to use this mix approach. My only confusion comes from wondering why they use Reason if this is important to their work?
Also, Reason doesn’t need more than 8 sends - Pro Tools only has 10 sends per channel. What Reason would need is more Aux Busses. This would be easier to add than more sends, but one thing you’d have to include is the ability to name the bus and see the name under each send, since with this approach you no longer have a 1:1 relation between the send position (send 1, send 2, etc.) and the effect that is receiving it.
The other Pro Tools feature you may want to add to Reason, which would greatly speed up the workflow in some cases, is “copy faders to sends”. This would allow you to quickly duplicate the channel balances of a group of faders on sends, for cases where you need pre-fader sends.
Anyway...
I get the leveling idea but isn't that also doable with bussed parallels? I mean if you wanted a parallel for drums with a different submix, couldn't you just create a parallel for each instrument , a new bus for these parallels with the compressor and you would then control the parallel sends level? Also, if you needed these to be post fader a group can be put In the middle and parallel the group. I get that it is messy but it's doable, and you could set these stuff to the end of the mixer and keep working as usual. And not trashing out (real) sends.
I don't know protools enough but how are these aux sends available in the mixer? I'm just thinking that adding this to reason's main mixer could be messy.
Selig I reread the part of the aux busses. A mixer section like the inserts section In red with routing under each knob would suffice but this couldn't be unlimited, right? The mixer is already huge...
You would only need to add text labels under each send knob, just like with the insert’s knobs, and additional outputs in the Master Section. There are 64 outputs in the Hardware Interface, and I think you would need no more than half that for Aux Busses - so it’s not something that would be that different from what’s already there in reason.
OR, you could further simplify things and just add a command to create a bus channel from a selection of sends rather than faders. As it is now, you can select multiple channels and “bus” them to a new Mix Channel. This would be the same thing, but would use sends instead, creating a unique path that bypasses the existing send. For example, if you selected 8 drum channels, and then command clicked on send 8 on one of the channels, a pop up could allow you to choose “Create New Send Bus” (or add to existing send bus). And like busses, the name you give to the bus master becomes the name that appears under the send. In this way you don’t have cables to deal with, and you only add the text label when sends are used this way. Make sense?
Selig Audio, LLC
-
- Posts: 1423
- Joined: 21 Sep 2016
I agree.CloudsOfSound wrote: ↑26 Mar 2019As a beginner Reason user, this goes a bit over my head, but wouldn't it be possible to just use the Mixer 14:2 Rack Devices to overcome this "limitation"?
I mean, they each have 4 stereo sends each and can be chained and combined in various creative ways.
If you then route these to the sends of the Master Mixer wouldn't this basically give you 4 extra sends for each of the 8 master send effects?
I'm just trying to learn, not educate in any way, so criticisms of my proposals are encouraged!
I usually have a reverb delay or any other time based effects for send effects.
But say I have the 8 slots filled with my choice of reverb delays and Chorus modules, then this is where the combinator with the line mixer, or combinator with the 14:2 mixer comes into play. I think of a send effect as the ability to mix a fully wet effect signal with the dry source sound. So by definition, if you use a smaller mixer that goes into reasons big mixer; then you are still adding the wet signal from what ever effect that’s plugged into the line mixer.
For this example, the reverbs and other effects take up the big mixer sends, and in a combinator the line mixer has a phaser hooked to the send.
All you are achieving is another blended signal of a wet effect and a dry signal.
So yes spot on o’l chap
Mayor of plucktown
For the first comment, yes that's the way most people use the sends for.scratchnsnifff wrote: ↑28 Mar 2019
I usually have a reverb delay or any other time based effects for send effects.
But say I have the 8 slots filled with my choice of reverb delays and Chorus modules, then this is where the combinator with the line mixer, or combinator with the 14:2 mixer comes into play. I think of a send effect as the ability to mix a fully wet effect signal with the dry source sound. So by definition, if you use a smaller mixer that goes into reasons big mixer; then you are still adding the wet signal from what ever effect that’s plugged into the line mixer.
For this example, the reverbs and other effects take up the big mixer sends, and in a combinator the line mixer has a phaser hooked to the send.
All you are achieving is another blended signal of a wet effect and a dry signal.
So yes spot on o’l chap
Second, the use of that option poses the same issues. Control of the amounts you send to the aux that doesn't break automation.
You make a valid statement, it's all wet and dry signals and to some extent what we've been talking here might be over complex and i have my doubts that this is that important.
However, if the aim of performance reviewing is to get reason on par with other Daws, there's nothing bad about proposing a new functionality to get Reason's mixer functionally on par with other daws too.
As long as usability + remote + automation + ssl likeness + effects + performance + a bunch of other things don't get broken in the process... These imho are far more important to me.
Hi there,
I had Reason 7.1 in mi MacBookPro 2014 and Cantabille via midi in order to use VSTs. Then I updated to 9.5 in order to have all VSTs inside Reason without Cantabille. This configuration, on the same MacBookPro, sometimes generates cracks and pops... (not only with VSTs, but also just using Reason regular instruments).
As a consequence, I returned to 7.1 but now I am very excited about Propellerheads statement: "...we found that Reason 10.3 improves performance even when not using VSTs too!...".
I am planning to take advantage of the offer to update until march for $99dls and wait until the release of 10.3. Hopefully that release will be on april that is among the one month trial... My question is if in the case that 10.3 does not solve pops and cracks can I get a money refund?
Thank you in advance/
I had Reason 7.1 in mi MacBookPro 2014 and Cantabille via midi in order to use VSTs. Then I updated to 9.5 in order to have all VSTs inside Reason without Cantabille. This configuration, on the same MacBookPro, sometimes generates cracks and pops... (not only with VSTs, but also just using Reason regular instruments).
As a consequence, I returned to 7.1 but now I am very excited about Propellerheads statement: "...we found that Reason 10.3 improves performance even when not using VSTs too!...".
I am planning to take advantage of the offer to update until march for $99dls and wait until the release of 10.3. Hopefully that release will be on april that is among the one month trial... My question is if in the case that 10.3 does not solve pops and cracks can I get a money refund?
Thank you in advance/
You can easily create a new email address and just do another Reason 10 trial that way if yours has already expired. I would wait and do a proper trial on 10.3 on your setup once it's been released to see if it provides a superior solution to 7.1 with Cantabile or 9.5 with VSTs in the rack.jpf wrote: ↑28 Mar 2019Hi there,
I had Reason 7.1 in mi MacBookPro 2014 and Cantabille via midi in order to use VSTs. Then I updated to 9.5 in order to have all VSTs inside Reason without Cantabille. This configuration, on the same MacBookPro, sometimes generates cracks and pops... (not only with VSTs, but also just using Reason regular instruments).
As a consequence, I returned to 7.1 but now I am very excited about Propellerheads statement: "...we found that Reason 10.3 improves performance even when not using VSTs too!...".
I am planning to take advantage of the offer to update until march for $99dls and wait until the release of 10.3. Hopefully that release will be on april that is among the one month trial... My question is if in the case that 10.3 does not solve pops and cracks can I get a money refund?
Thank you in advance/
I, like you, on a daily basis have gone back to using Reason 7.1 as I find it the best performing. I also prefer the old browser to the new one and I also really hate the super-flat transport graphics of 8+.
Out of interest, are you running Bootcamp on your Mac given Cantabile is Windows only?
The current browser is a joke. An abomination. It should be a detachable window.
This is a block of text that can be added to posts you make. There is a 255 character limit.
I don't think you're 100% addressing the lack of sends with this solution, because you'll end up with PRE fader, not POST fader sends with this approach (been there/done that, read on for more).scratchnsnifff wrote: ↑28 Mar 2019I agree.CloudsOfSound wrote: ↑26 Mar 2019As a beginner Reason user, this goes a bit over my head, but wouldn't it be possible to just use the Mixer 14:2 Rack Devices to overcome this "limitation"?
I mean, they each have 4 stereo sends each and can be chained and combined in various creative ways.
If you then route these to the sends of the Master Mixer wouldn't this basically give you 4 extra sends for each of the 8 master send effects?
I'm just trying to learn, not educate in any way, so criticisms of my proposals are encouraged!
I usually have a reverb delay or any other time based effects for send effects.
But say I have the 8 slots filled with my choice of reverb delays and Chorus modules, then this is where the combinator with the line mixer, or combinator with the 14:2 mixer comes into play. I think of a send effect as the ability to mix a fully wet effect signal with the dry source sound. So by definition, if you use a smaller mixer that goes into reasons big mixer; then you are still adding the wet signal from what ever effect that’s plugged into the line mixer.
For this example, the reverbs and other effects take up the big mixer sends, and in a combinator the line mixer has a phaser hooked to the send.
All you are achieving is another blended signal of a wet effect and a dry signal.
So yes spot on o’l chap
But first, a definition: Sends are a way of sending MULTIPLE sources to one destination, not just a way of mixing a fully wet signal with the dry source. A Mix/Blend knob also accomplishes that goal, as does a parallel channel. But neither of those solutions provide a way to combine multiple source into one FX device while providing a way to adjust individual send levels on each source.
So to REALLY get around the limitation of 8 sends, the only way is for the Props to add more sends. Why? Because 99% of the time you're taking about post fader sends being used, and since there is no way to tap the output of a channel post fader (without muting the output, using the direct out), there is no way of adding post fader sends to the SSL mixer in Reason. If this one limit was lifted, you COULD add sends of sorts with some creative routing.
The example of the line or 14:2 mixer doesn't take this into account. Adding a send from the insert means it is PRE fader, not POST. This was discussed many times in the past, I've even provided a Combinator that adds four more PRE fader sends, which is nice because the send/mute buttons are available from the mixer view without having to open the insert (since every insert in the SSL mixer has the Combinator's knobs/buttons/programmer). BUT, they are still PRE fader and won't be all that useful because every time you make a change to the fader, you'll also have to make a change to the send…
And this still doesn't create a send BUS, it creates an individual send - more routing would be required to create a send bus, including a summing section (14:2 mixers would work) for each bus, which would require LOTS of cables if you wanted to provide just a single additional send bus for every channel in a large mix.
Selig Audio, LLC
- CloudsOfSound
- Posts: 114
- Joined: 11 Aug 2015
- Location: K-Pax, Lyra
- Contact:
Yes, you'll get a refund within 30 days by contacting Propellerhead Support.jpf wrote: ↑28 Mar 2019I am planning to take advantage of the offer to update until march for $99dls and wait until the release of 10.3. Hopefully that release will be on april that is among the one month trial... My question is if in the case that 10.3 does not solve pops and cracks can I get a money refund?
I demanded to get the Drum Sequencer RE included when purchasing Reason 10 not so long ago, and had an argument regarding this and was told that the Drum Sequencer was a separate purchase after May 2018 or something, but if I wasn't happy with my Reason 10 purchase, they would fully refund it.
I ended up with a coupon code to use for purchasing the Drum Sequencer, so it would cost me like $15, so I settled with that.
I wouldn't have it refunded because of this, but some leverage is always good to have.
But, the short answer is, yes, you'll get a refund.
Reason 10 running on MacBook Pro 16" 2019
(6-Core Intel Core i7 / AMD Radeon Pro 5300M 4GB / 16GB RAM)
macOS Catalina v.10.15.2
Software Developer and Wannabe Musician
(6-Core Intel Core i7 / AMD Radeon Pro 5300M 4GB / 16GB RAM)
macOS Catalina v.10.15.2
Software Developer and Wannabe Musician
- CloudsOfSound
- Posts: 114
- Joined: 11 Aug 2015
- Location: K-Pax, Lyra
- Contact:
I see.
I was under the impression that the buttons on the top section of the channel strips for altering the signal flow was related to altering the PRE / POST fader signal flow, as is possible to do in the ProTools and Logic mixers.
I haven't yet had any reason to alter this, but assumed that this was the case, but this only affects the dynamics section in terms of what happens first, FX, EQ or compression, not related to the signal path pre or post fader.
If they had this function the scenario I mentioned would be possible to achieve using internal mixers in the rack and some simple routing and grouping / parallel processing, but now I at least understand the use-case that is problematic to fulfill with the current "limitations".
Never stop learning!
Last edited by CloudsOfSound on 29 Mar 2019, edited 1 time in total.
Reason 10 running on MacBook Pro 16" 2019
(6-Core Intel Core i7 / AMD Radeon Pro 5300M 4GB / 16GB RAM)
macOS Catalina v.10.15.2
Software Developer and Wannabe Musician
(6-Core Intel Core i7 / AMD Radeon Pro 5300M 4GB / 16GB RAM)
macOS Catalina v.10.15.2
Software Developer and Wannabe Musician
- CloudsOfSound
- Posts: 114
- Joined: 11 Aug 2015
- Location: K-Pax, Lyra
- Contact:
Ignore this post.
Something strange happened.
Probably time to go to bed...
Something strange happened.
Probably time to go to bed...
Reason 10 running on MacBook Pro 16" 2019
(6-Core Intel Core i7 / AMD Radeon Pro 5300M 4GB / 16GB RAM)
macOS Catalina v.10.15.2
Software Developer and Wannabe Musician
(6-Core Intel Core i7 / AMD Radeon Pro 5300M 4GB / 16GB RAM)
macOS Catalina v.10.15.2
Software Developer and Wannabe Musician
Thanks for your comments!CloudsOfSound wrote: ↑28 Mar 2019I see.
I was under the impression that the buttons on the top section of the channel strips for altering the signal flow was related to altering the PRE / POST fader signal flow, as is possible to do in the ProTools and Logic mixers.
I haven't yet had any reason to alter this, but assumed that this was the case, but this only affects the dynamics section in terms of what happens first, EQ or compression, not related to the signal path pre or post fader.
If they had this function the scenario I mentioned would be possible to achieve using internal mixers in the rack and some simple routing and grouping / parallel processing, but now I at least understand the use-case that is problematic to fulfill with the current "limitations".
Never stop learning!
-
- Information
-
Who is online
Users browsing this forum: No registered users and 7 guests