RUN BUTTON: The worst thing about Players

[challism]

I love players but I absolutely hate the RUN button. It makes me crazy. Why can't it be automated? The work around is to automate the ON button, but even then, the run button is DISENGAGED half of the time - on what appears to be its own whim. It just really seems unpredictable and uncontrollable.

I don't even see the point of this button, Wouldn't an ON/OFF button be enough? Especially given the headache of having to wonder if the run button will be engaged when you automate the on/off button. Maybe I don't know what I'm doing, but the run button seems totally uncontrollable. Any advice? Is there something I'm totally missing here? How do I ensure the run button is always engaged?

This is what I'm talking about

[buddard]

It’s because when the Run button is engaged, the device immediately starts playing back. And when you automate a parameter in Reason, the value is changed due to the position of Reason’s playhead, regardless of whether the main sequencer is running or not. So clicking in the song ruler or even loading a song could cause the device to start playing back immediately, which is of course not what you want.

The Run button is useful in that you can use it to preview the sequence of a single device without having to solo it in the mixer..

[WaxTrax]

This makes me think, if Reason had a modern clip launcher-type feature a la Ableton or Logic Pro Live Loops, I probably would never need to look at other DAWs. To me, a good implementation of this kind of functionality is one of the key missing features of Reason right now.

In the context of this thread, it would be nice to be able to initiate a player's Run button via clip launcher.

[challism]

It’s because when the Run button is engaged, the device immediately starts playing back. And when you automate a parameter in Reason, the value is changed due to the position of Reason’s playhead, regardless of whether the main sequencer is running or not. So clicking in the song ruler or even loading a song could cause the device to start playing back immediately, which is of course not what you want.

The Run button is useful in that you can use it to preview the sequence of a single device without having to solo it in the mixer..

I get why the run button can be useful if you are trying to isolate the player, I just don't get why it can't be automated. That is at the core of my frustration. It would be nice if there were a toggle for the run button to make it always be on (in sync) with the transport.


The on/off button is automated (video shows the automation lane). The run button was engaged before I started recording the video.

@0:06: The very first time the transport gets to the on button automation, the run button is disengaged and I have to enable it. BAD
@0:22: Double stop the transport and play again - the run button is engaged. GOOD
@0:25: I back the transport up and play - the run button is still engaged. GOOD
@0:30: Double stop and play again, the run button is disengaged. BAD (also WHY?)
@0:40: Double stop and play - run button engaged. GOOD
@0:50: Double stop and play - run button engaged. GOOD
@1:00: Double stop and Play - run button engaged. GOOD
@1:08: Double stop and play - run button disengaged. BAD (and why?)
@1:25: Double stop and play - run button engaged. GOOD
@1:35: Double stop and play - run button engaged. GOOD
@1:40: Double stop and play - run button engaged. GOOD
@1:50: Double stop and play - run button disengaged. BAD (why?)

[buddard]

It’s because when the Run button is engaged, the device immediately starts playing back. And when you automate a parameter in Reason, the value is changed due to the position of Reason’s playhead, regardless of whether the main sequencer is running or not. So clicking in the song ruler or even loading a song could cause the device to start playing back immediately, which is of course not what you want.

The Run button is useful in that you can use it to preview the sequence of a single device without having to solo it in the mixer..

I get why the run button can be useful if you are trying to isolate the player, I just don't get why it can't be automated. That is at the core of my frustration. It would be nice if there were a toggle for the run button to make it always be on (in sync) with the transport.

I tried to explain this in my first paragraph: It's because automation values are sent to the device even when the main transport is standing still. So moving the playhead to a locator (or moving it its position in some other way) where RUN is automated to "enabled" would cause the RUN button to suddenly be activated.

The on/off button is automated (video shows the automation lane). The run button was engaged before I started recording the video.

@0:06: The very first time the transport gets to the on button automation, the run button is disengaged and I have to enable it. BAD
@0:22: Double stop the transport and play again - the run button is engaged. GOOD
@0:25: I back the transport up and play - the run button is still engaged. GOOD
@0:30: Double stop and play again, the run button is disengaged. BAD (also WHY?)
@0:40: Double stop and play - run button engaged. GOOD
@0:50: Double stop and play - run button engaged. GOOD
@1:00: Double stop and Play - run button engaged. GOOD
@1:08: Double stop and play - run button disengaged. BAD (and why?)
@1:25: Double stop and play - run button engaged. GOOD
@1:35: Double stop and play - run button engaged. GOOD
@1:40: Double stop and play - run button engaged. GOOD
@1:50: Double stop and play - run button disengaged. BAD (why?)

This particular case looks like a bug in mDSQ to me? All other players I have (including other panda REs) seem to handle this case correctly.

[buddard]

A good workaround for the mDSQ, and a pretty good solution all around, is to automate "Pattern Select" for the players that support it rather than "On". It also gives you the opportunity to offset the playback since each pattern automation clip contain an "anchor point".

[electrofux]

I hope some day they figure out a way to make run AND record on players automatable and remotable. The way it is right now is imho just not how it should be. It is not understandable to me why they went with that ( i know it is their SDK and no external devs fault).

And cliplauncher yeah.

[carvingcode]

Why not use the mixer's Mute button? Can that be automated?

FWIW: I'm a big "no" on the need for clip launcher in Reason. Reason is not a clip player. Never has been. Doesn't need to be. You have the RRP to use in DAWs which excel at clip launching, if that's your jam. Let Reason be Reason, man. Peace.

[crimsonwarlock]

FWIW: I'm a big "no" on the need for clip launcher in Reason. Reason is not a clip player. Never has been. Doesn't need to be.

+1

[electrofux]

I disagree on the Clip Launcher. Reason has its roots in Rebirth which basically is a clip launcher in that a clip is a pattern. Reason also heavily features pattern based devices. So to me it would be natural to create an overlay to control them all - a session view like clip launcher.

[buddard]

I hope some day they figure out a way to make run AND record on players automatable and remotable. The way it is right now is imho just not how it should be. It is not understandable to me why they went with that ( i know it is their SDK and no external devs fault).

There is no technical limitation that prevents us to make Run buttons automatable, but it's strongly discouraged (and I think it might even cause the RE to fail acceptance, but I'm not 100% sure), due to the reasons I gave earlier. Please refer to the chapter about the Run button in the SDK documentation:

Run

Rack Extensions that have an internal sequencer (what we call pattern devices), should implement the Run behaviour. In general, pattern devices should start and stop in sync with master sequencer transport. With Run, the user can start/stop the internal sequencer independently of Reason’s sequencer:

• When Reason is stopped, the user can Run the pattern device on it’s own to preview and edit patterns
• When Reason is running, the user can pause the pattern device

A good example of the Run behaviour is the Redrum, so give it a spin to get a feel for the behaviour! There are some issues to consider with Run:

• Run button should not be automatable. If you want the user to be able to automate the pattern playback, please use a separate property (Sequencer On/Off) or an empty pattern. The reason for this is that we do not want setting the Play position to a PPQ where Run is automated to On to start the device sequencer. Please note that even if the Run button should not be automatable, it should still be a remoteable item.
• In Bypass All mode, Players should stop and not listen to Run messages.
• The Combinator has a Run Pattern Devices button, that updates the /transport/request_run property to all devices in the Combi.

[selig]

I tried to explain this in my first paragraph: It's because automation values are sent to the device even when the main transport is standing still. So moving the playhead to a locator (or moving it its position in some other way) where RUN is automated to "enabled" would cause the RUN button to suddenly be activated.

This is how all automation works. If I had my PCM-70 holding infinite reverb and used automation to turn it on/off at various points in the song, if I move the play head to a place on the timeline where the PCM-70 channel is on I’ll hear the effect – even though the transport isn’t playing. Not sure how you would work around this for a Run button.

[buddard]

I tried to explain this in my first paragraph: It's because automation values are sent to the device even when the main transport is standing still. So moving the playhead to a locator (or moving it its position in some other way) where RUN is automated to "enabled" would cause the RUN button to suddenly be activated.

This is how all automation works. If I had my PCM-70 holding infinite reverb and used automation to turn it on/off at various points in the song, if I move the play head to a place on the timeline where the PCM-70 channel is on I’ll hear the effect – even though the transport isn’t playing. Not sure how you would work around this for a Run button.

Exactly.

[dvdrtldg]

A good workaround for the mDSQ, and a pretty good solution all around, is to automate "Pattern Select" for the players that support it rather than "On". It also gives you the opportunity to offset the playback since each pattern automation clip contain an "anchor point".

This. Problem solved

[challism]

A good workaround for the mDSQ, and a pretty good solution all around, is to automate "Pattern Select" for the players that support it rather than "On". It also gives you the opportunity to offset the playback since each pattern automation clip contain an "anchor point".

This. Problem solved

I'm going to have to remember this workaround/solution.