Tempo automation, endless discussion and the reason-way
Ok, today I've time, so I can post again my idea to implement tempo-automation in reason.
1 : Automation of tempo-device
We need a new (old) device for that. The device is already here: You see it at the bottom of the window. Now assume, it's a reason device, like every other.
We have now the possibilities we need: Every controller in that device can be controlled by the tracker or via midi.
That's just cool. And this is really easy to implement, cause the hole functionality is already in here, it must just be automated, that's all.
2 : You are able to change all settings!
Cause you are able to change all settings in the tempo-device, you are also able to change the loop-points or the song position and so on. So you can create very complex songs, just by moving the pattern repeat. Or set the song position.
But this makes only sense, if you have a second sequencer, which has a more or less constant speed.
With a "second sequencer" I mean: You can create a new sequencer window, and you have the control over all devices in your rack, like in the first sequencer, but this sequencer has consequently it's own tempo-device. That's the only distinction between the two sequencers.
You can of course change the speed of a tempo device of another sequencer with this second sequencer.
3 : A second (third, fourth...) sequencer.
Now think about alltogether:
If you have the ability to create new sequencer-windows, all with it's own speed, you are easily able to make "african music".
But that's only one of the simplest tasks.
You can make extremly complex music, because you can create setups, where the speed and positions of the sequencers controlls the speed of another sequencer-window and that controlls the speed of a third sequencer-window.
4 : Add "arpegiator" functionality
Remember: Every sequencer has the full controll over all devices in a song.
So you can make a complete song with it, or just make a small pattern. You can make a pattern-sequencer with as many channels as needed for example. Or a drum-pattern which has 256 beats.
And all is MIDI, so you don't need to handle complex cables and CV values.
But to implement arpegiator patterns we need another device.
Assume we have an easy setup: one sequencer is the song, and the second sequencer should be the arpegiator-pattern.
Then the arpegiator-device gets as input signal the cords from the song-sequencer. (A-major cords, d-moll and so on). The arpegiator device is routed to a sequencer and will automatically modify the tracks in the sequencer.
For example: To play C-dur you send the notes C3, E3 and G3 to the arpegiator device. The arpegiator device now modifies the first track in the arpegiator-sequencer, so that it dosn't change (cause you said, the base tone for the first track is C3), the second track is advanced by 4 halfnotes (cause also basenote is C3) and the third is advanced by 7 halfnotes.
So we have a fine arpegio with unlimited features.
There are of course some other algorythms thinkable, to modify the signals, but I think the prinziple is clear.
All signals which have not modifier-rule (pitch bend etc.) can have a default device, where it should be routed to.
Think of the possibilities:
- every sequencer has the ability of full controll over all devices in a rack (and the tempo-devices too).
- Arpegios are not limited to one device. They can split over as many devices as needed.
- There is no difference between sequencer-pattern and drum-pattern
- extremly complex music (think about a modification rule, which will play only every second, third, ... note)
- Think about negative tempo? Play your song backward? Could have strange effect like scratching.
How to implement?
My four points above could be implemented step after step. For a Reason 3.5 I think, that step 1 is really easy to implement, cause all you need to add, is the possibility to create a track for the tempo-device and controll all the controls in it.
I also think, that step 2 is easy to implement, if you don't forbid to change the speed for the second sequencer (but not the positions/loops etc).
So step 3 and 4 is in my eyes more complex, but I think with reason 5 that could be implemented at all.
All times are GMT +2. The time now is 11:00.