Using players within blocks, what's your workflow?

[crimsonwarlock]

Blocks was one of the things that has drawn me to Reason, so it is an integral part of my composing workflow. Now I'm starting to include several generative players (ChordSQ, ScaleMatrix, BeatMap, BLG, etc.) into my composing strategy. However, merging players with a blocks-oriented workflow does throw up some limitations, as blocks are basically tied to the sequencer, while players work mostly in the rack.

Fore example, using BLG for the bass lines, it is possible to set certain patterns inside a block with automation, but having just eight patterns makes that a very limited option. Stacking several BLG players on top of one instrument and switching those on and off for certain blocks is also cumbersome, and having separate player-instrument combos for each block makes the rack an unmanageable mess. The same goes for almost every other player, even more so for those that lack patterns.

So if you use blocks and players together, how do you manage your workflow in this regard?

[jam-s]

"Send to track" is quite useful when working with players and blocks.

[crimsonwarlock]

"Send to track" is quite useful when working with players and blocks.

Yes, but that means you lose the possibilities of changing your player during composing. As soon as you send to track, you're back at editing MIDI, which is precisely why I like to use players instead.

[jam-s]

"Send to track" is quite useful when working with players and blocks.

Yes, but that means you lose the possibilities of changing your player during composing. As soon as you send to track, you're back at editing MIDI, which is precisely why I like to use players instead.

You can still mute the midi track/clip create an alt lane and re-activate the players when you want to try out other variations. It's not too much of a hassle imho.

[crimsonwarlock]

You can still mute the midi track/clip create an alt lane and re-activate the players when you want to try out other variations. It's not too much of a hassle imho.

That goes back to one of the initial problems I described, specifically for bass lines. In most cases, I have one bass synth playing all the parts in a song. So I need to have a copy of that bass instrument together with BLG for every block in my song. Or send to track the bass line inside a block, then go to another block and do another bass line with the same BLG and instrument, send that to track, rinse and repeat. Keeping the BLG in place deactivated, means it must hold all patterns for all the blocks, and then we don't have enough patterns available in BLG.

Obviously, when you can keep the player in place, you don't have to send to track and deactivate, as the player is still there.

[artotaku]

One thing I do when using players and blocks is I add a pattern lane for the player in the block and select e. g. pattern 1.
When switching to Song mode and after having added the block I cut the block e. g. at the last bar so the pattern gets also cut. Then I disable/mute the remainder pattern part or add a another pattern select (e. g. 2) clip on top of it to do a transition with a different pattern or muting it. This ofc works also with any clip (automation etc).

blocks-player-pattern.png (5.21 KiB) Viewed 1005 times

[crimsonwarlock]

One thing I do when using players and blocks is I add a pattern lane for the player in the block and select e. g. pattern 1.

Yep, using player patterns is currently the only way to go afaics. The problem with that is that eight patterns (some have only four) is not enough when you use several blocks, meaning you will only have one or maybe two patterns available for each block, which is definitely not enough for my kind of music. Besides that, there are several that still have no patterns available.

I think this is a serious oversight in the players design. The solution would be if players would be blocks-aware, meaning that the complete player-state would be stored inside a block, and you could have completely different player settings, loaded presets, etc. for each block. But I'm pretty sure the current architecture doesn't support this, and might never do.

[artotaku]

One thing I do when using players and blocks is I add a pattern lane for the player in the block and select e. g. pattern 1.

Yep, using player patterns is currently the only way to go afaics. The problem with that is that eight patterns (some have only four) is not enough when you use several blocks, meaning you will only have one or maybe two patterns available for each block, which is definitely not enough for my kind of music. Besides that, there are several that still have no patterns available.

I think this is a serious oversight in the players design. The solution would be if players would be blocks-aware, meaning that the complete player-state would be stored inside a block, and you could have completely different player settings, loaded presets, etc. for each block. But I'm pretty sure the current architecture doesn't support this, and might never do.

The RE SDK supports up to 32 patterns just like the stock pattern devices (Matrix) have so there is more selection possible as is offered in the devices. It seems that 8 patterns are the unwritten standard for player devices when RS started selling pattern based REs. And it is just followed by the 3rd party devs. Maybe they thought 8 are just practical and enough for most cases. I have a further suspicion why it´s just up to 8 patterns. Automation. Since RE SDK does not have the notion of a pattern scope for properties and there is a limit on how much properties you can have and how many you can automate devs stick with 8 patterns. You also notice that in pattern players not all properties are automatable and provided in combi programmer.

[crimsonwarlock]

The RE SDK supports up to 32 patterns just like the stock pattern devices (Matrix) have so there is more selection possible as is offered in the devices. It seems that 8 patterns are the unwritten standard for player devices when RS started selling pattern based REs. And it is just followed by the 3rd party devs. Maybe they thought 8 are just practical and enough for most cases. I have a further suspicion why it´s just up to 8 patterns. Automation. Since RE SDK does not have the notion of a pattern scope for properties and there is a limit on how much properties you can have and how many you can automate devs stick with 8 patterns. You also notice that in pattern players not all properties are automatable and provided in combi programmer.

Great info. Having 32 patterns would help a lot indeed, but my suggestion (and why I said I don't see that happening) was to have blocks encapsulate the whole state of a player. That way, you would have just one player instance, but it would behave as separate instances within blocks. This would be a logical solution, as there never can be two or more blocks playing at the same time.

[Eclipxe]

Feels like the best workaround is multiple players routing to the same instrument stack and then using something like LaunchEon to manage scenes of multiple players enabled/disabled state?

[crimsonwarlock]

Feels like the best workaround is multiple players routing to the same instrument stack and then using something like LaunchEon to manage scenes of multiple players enabled/disabled state?

Yep, I was already thinking about stacking players for this (when needed). Not the most manageable or clean solution, but it will work.

I also realized that having a copy of the instrument with its own player might actually be the better way to do things. In case I have the same instrument and patch running in different blocks, I do tend to have little changes in the sound by using automation. Having separate instances with the changes made on the patch itself is maybe a better workflow for this.

Using and changing one instrument instance with one player instance comes from trying to reserve as much CPU as possible. Lately I'm moving to a new workflow where I do the mixing phase with all tracks rendered to stems, so saving CPU cycles is less of an issue.