CV control of song tempo

Have any feature requests? No promise they'll get to Reason Studios, but you can still discuss them here.
househoppin09
Posts: 536
Joined: 03 Aug 2016

16 Mar 2017

I've long wished for some way to modulate the overall song tempo algorithmically, instead of having to produce automation curves to do it. If I'm not mistaken, no such ability currently exists in Reason; certainly there is no way to use standard CV signals to modulate song tempo. Now, it may be tempting to say "househoppin09, you silly goose, of course you can't do that! CV signals can only take one of 128 possible values", etc. Well, I don't see why that should be a problem at all. Even in the worst case, one crude but perfectly workable solution would be to simply have a CV input for the part of the tempo on the left side of the decimal point, and another for the part of the tempo on the right side of the decimal point. The CV value for the left side, if centered around 120, would allow for a range of 56 to 183, for example; not too bad. Further range could easily be obtained by adding a third "offset" CV input, yielding a total range of, say, 0 to 255 for the left side of the decimal point. Not bad at all. The CV value for the right side of the decimal point would give you 1/128 BPM resolution, or else only 100 values could be used and it could provide two decimal places of precision; either option would provide for excellent control. And of course, those CV scaling knobs that so many devices use could add even more breadth and flexibility to this scheme.

So, given all of that, I see no reason why this should be at all problematic to implement. And as far as why it might be desirable, that should be obvious. Tempo modulation can make for some very cool (and very basic!) effects. For those of us who do a lot of that, having to painstakingly graph everything out as automation is awkward, time-consuming, and very limiting. Imagine being able to simply run an LFO right into the song tempo, or randomize the tempo in interesting ways, or whatever. It would open up a ton of seriously exciting new possibilities. Please add this, Props! I'll be e-mailing them to formally request this feature, and if anyone else here agrees that it'd be nice to have, please take a minute to do the same. :)

User avatar
Raveshaper
Posts: 1089
Joined: 16 Jan 2015

16 Mar 2017

This currently possible as of Reason 7 or newer. Among other implementations, you can calculate 1:1 recording speed for samples as they change playback rate to get some strange stretching and frequency shifting without losing timing. But a better and more official way to do it would be nice.
:reason: :ignition: :re: :refillpacker: Enhanced by DataBridge v5

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

16 Mar 2017

Actually this is most like possible using the EMI (it has CV input) and virtual midi. You would assign the EMI knob to the bpm.

I wouldn't expect an "official " way of doing it since it's not common to automate tempo with a continuous curve.

househoppin09
Posts: 536
Joined: 03 Aug 2016

17 Mar 2017

Raveshaper: I'm not sure we're talking about the same thing. I want to be able to manipulate the overall song tempo within Reason, as though with an automation curve, except using CV signals. There wouldn't necessarily be any samples or audio files involved at all. Are you just saying that I could approximate the tempo modulation I want by first exporting the final mixdown as an audio file and then modulating its playback somehow in a new Reason song? I'm not really clear on the process you're describing, but it does sound interesting, even if it doesn't really fit the bill of my original request.

QVprod: I thought of that, but it seems like it'd be too much of a hassle to bother with. I think you're right that it's an uncommon enough requirement that the Props probably won't bother implementing it in a self-contained way within Reason, but I really think that's unfortunate. If there's one thing I love about Reason, it's the near-total limitlessness of routing possibilities and such. There may not be much demand for algorithmic tempo manipulation currently, but the whole point of Reason is to give people options and room to explore and try new things, things that have potential that no one has bothered tapping yet. I really hope someone from PH is reading this and will consider adding this, as it probably wouldn't be too hard to do, and could make some very cool effects possible.

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

19 Mar 2017

househoppin09 wrote:QVprod: I thought of that, but it seems like it'd be too much of a hassle to bother with. I think you're right that it's an uncommon enough requirement that the Props probably won't bother implementing it in a self-contained way within Reason, but I really think that's unfortunate. If there's one thing I love about Reason, it's the near-total limitlessness of routing possibilities and such. There may not be much demand for algorithmic tempo manipulation currently, but the whole point of Reason is to give people options and room to explore and try new things, things that have potential that no one has bothered tapping yet. I really hope someone from PH is reading this and will consider adding this, as it probably wouldn't be too hard to do, and could make some very cool effects possible.
Virtual midi is pretty simple to set up. (Looping back audio is where the complications generally lie). And you'd only have to set it up once. Then you could easily use it whenever you need to with simple remote overrides. I'd say it's worth looking into if you really want to do it.

househoppin09
Posts: 536
Joined: 03 Aug 2016

13 Apr 2017

QVprod wrote:
househoppin09 wrote:QVprod: I thought of that, but it seems like it'd be too much of a hassle to bother with. I think you're right that it's an uncommon enough requirement that the Props probably won't bother implementing it in a self-contained way within Reason, but I really think that's unfortunate. If there's one thing I love about Reason, it's the near-total limitlessness of routing possibilities and such. There may not be much demand for algorithmic tempo manipulation currently, but the whole point of Reason is to give people options and room to explore and try new things, things that have potential that no one has bothered tapping yet. I really hope someone from PH is reading this and will consider adding this, as it probably wouldn't be too hard to do, and could make some very cool effects possible.
Virtual midi is pretty simple to set up. (Looping back audio is where the complications generally lie). And you'd only have to set it up once. Then you could easily use it whenever you need to with simple remote overrides. I'd say it's worth looking into if you really want to do it.
Having thought about it some more, I suppose you may be right about this. However, before I start installing things and messing around trying to get it all to work, one obvious problem occurs to me: it sounds like the process you're suggesting will map the EMI knob's 0-127 value range directly to the song tempo's entire possible value range. If so, this will make useful tempo modulation impossible, as each EMI knob value click will equate to a jump of many BPM. I don't really have any experience manipulating song tempo or other transport bar controls with a MIDI controller, so I'm hoping that I'm just missing something obvious here. Can you clarify how this issue would shake out in practice?

User avatar
Oquasec
Posts: 2849
Joined: 05 Mar 2017

13 Apr 2017

Oh. I'd just right lcick and assign a knob to tempo when in the mood for that :P
Producer/Programmer.
Reason, FLS and Cubase NFR user.

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

13 Apr 2017

househoppin09 wrote:
QVprod wrote:
househoppin09 wrote:QVprod: I thought of that, but it seems like it'd be too much of a hassle to bother with. I think you're right that it's an uncommon enough requirement that the Props probably won't bother implementing it in a self-contained way within Reason, but I really think that's unfortunate. If there's one thing I love about Reason, it's the near-total limitlessness of routing possibilities and such. There may not be much demand for algorithmic tempo manipulation currently, but the whole point of Reason is to give people options and room to explore and try new things, things that have potential that no one has bothered tapping yet. I really hope someone from PH is reading this and will consider adding this, as it probably wouldn't be too hard to do, and could make some very cool effects possible.
Virtual midi is pretty simple to set up. (Looping back audio is where the complications generally lie). And you'd only have to set it up once. Then you could easily use it whenever you need to with simple remote overrides. I'd say it's worth looking into if you really want to do it.
Having thought about it some more, I suppose you may be right about this. However, before I start installing things and messing around trying to get it all to work, one obvious problem occurs to me: it sounds like the process you're suggesting will map the EMI knob's 0-127 value range directly to the song tempo's entire possible value range. If so, this will make useful tempo modulation impossible, as each EMI knob value click will equate to a jump of many BPM. I don't really have any experience manipulating song tempo or other transport bar controls with a MIDI controller, so I'm hoping that I'm just missing something obvious here. Can you clarify how this issue would shake out in practice?
You're right. Hadn't thought about that. you can control the amount with the level rate of cv source (just tried it out with Pulsar) but to really fine tune it you would need to put the EMI in a combinator and route the cv to a combi knob. There you would assign the combi knob to the cc knob on the EMI. I the programmer you can set the range of values you want the knob to work between (which would set the BPMs it cycles though.

The only thing though is there are jumps and it's hard to be completely accurate because of the 0-127 midi as you mentioned as well as it being a continuous CV curve, so this might only useful if you assign it to the decimal portion of the tempo instead of the whole number for subtlety.

househoppin09
Posts: 536
Joined: 03 Aug 2016

13 Apr 2017

Oh, interesting. So, using the combi programmer method as you say, it would be possible to have EMI knob position 0 map to, say, 100 BPM, and EMI knob position 127 map to 120 BPM? That would offer a resolution of 128 steps over 20 BPM = about one-sixth of a BPM per step. That would certainly be very usable. Have I understood correctly, and are you sure that it is indeed possible to use the combi programmer to "squash" the 0-127 MIDI CC value space into any arbitrary subset of the tempo space? Also, I hadn't realized that the decimal portion of the tempo had a separate input--are you sure about that? So there are two totally separate MIDI inputs for the song tempo, one for the left side of the decimal point and one for the right side?

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

16 Apr 2017

It's hard to be exact with the tempo but yeah you can limit the range so that it doesn't go all the way in the 900s. The only thing is the EMI knob would not be using it's full range of 1-127. At least that's as far as I got in experimenting. The decimal portion of the bpm is an interesting surprise but it indeed has a separate remote input from the whole number. You can control them independently of each other

househoppin09
Posts: 536
Joined: 03 Aug 2016

16 Apr 2017

When you say "the EMI knob would not be using its full range", that's what worries me--for example, if I limit the tempo range to, say, 100-120 BPM, does that mean the EMI knob's range would be limited to a correspondingly tiny portion of its own range, like 14-16 or whatever, giving me only two or three clicks for that entire 20 BPM range?

Very cool about the decimal portion having its own input, just as I had suggested at the beginning of this thread. So I guess the Props and I think alike, sort of... ;)

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

16 Apr 2017

Yeah, that exactly. Unless there's a way to scale it better. The decimal automating might be a great way to emulate "swing" or at least the slight off timing of real musicians

househoppin09
Posts: 536
Joined: 03 Aug 2016

16 Apr 2017

Hmm, okay. That's unfortunate. It's really weird that they'd give remotable access to the tempo, only to then make it impossible to actually use that access to set the tempo to anything in between fixed steps of about 8 BPM (give or take). So, regardless of the whole idea of using the EMI, and routing it back into Reason--if the MIDI tempo control is such that one MIDI CC value maps to 117 BPM and the next value maps to 125 BPM, there's really just no way to use a MIDI controller to set the tempo to anything in between those very widely separated values? Having the ability to set the decimal value is interesting, but only lets you close the gap by ~1 BPM, so if you wanted to use a MIDI controller of any kind to set the tempo to 120 or 122 or whatever, you just can't? It seems like that almost defeats the purpose of enabling tempo as a remotable parameter in the first place. Ah well, if you ever do discover a way around that limitation, I'd love to hear about it. Anyway, thanks for the info.

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

16 Apr 2017

No it's not the midi that's limited. It's the cv control of the midi. It works just fine for controllers. It's hard to accurately set the tempo with cv controlling it is what I mean. In order to prevent the bpm from going into the 900s you have to limit it's range with the combinator programmer .

househoppin09
Posts: 536
Joined: 03 Aug 2016

03 May 2017

QVprod wrote:No it's not the midi that's limited. It's the cv control of the midi. It works just fine for controllers. It's hard to accurately set the tempo with cv controlling it is what I mean. In order to prevent the bpm from going into the 900s you have to limit it's range with the combinator programmer .
Sorry to bug you again about this, but unfortunately it does not seem to work just fine for controllers. I'm not even trying to use CV at this point--for now, I'd be happy just to be able to manipulate the song tempo in real time with my controller. Sure enough, though, I'm running into exactly the problem I feared: the controller is sending MIDI CC data in the standard 0-127 range, and that's being mapped onto the entire 0-999 tempo range. It doesn't seem to matter which control I map to the tempo: mod wheel, knobs, faders, whatever. They're all moving the tempo in steps of 8 BPM, which of course is useless. For example, I'll map the mod wheel to the song tempo and one click will be 103 BPM, the next click is 111, the next is 119, etc. You seemed pretty sure that this shouldn't happen when using an actual controller, so I'm curious to know what you think I might be doing wrong here. Thanks again!

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

03 May 2017

househoppin09 wrote:
QVprod wrote:No it's not the midi that's limited. It's the cv control of the midi. It works just fine for controllers. It's hard to accurately set the tempo with cv controlling it is what I mean. In order to prevent the bpm from going into the 900s you have to limit it's range with the combinator programmer .
Sorry to bug you again about this, but unfortunately it does not seem to work just fine for controllers. I'm not even trying to use CV at this point--for now, I'd be happy just to be able to manipulate the song tempo in real time with my controller. Sure enough, though, I'm running into exactly the problem I feared: the controller is sending MIDI CC data in the standard 0-127 range, and that's being mapped onto the entire 0-999 tempo range. It doesn't seem to matter which control I map to the tempo: mod wheel, knobs, faders, whatever. They're all moving the tempo in steps of 8 BPM, which of course is useless. For example, I'll map the mod wheel to the song tempo and one click will be 103 BPM, the next click is 111, the next is 119, etc. You seemed pretty sure that this shouldn't happen when using an actual controller, so I'm curious to know what you think I might be doing wrong here. Thanks again!
That's interesting. I can change the bpm as expected with my P6. Unless the P6 is doing something special, which I doubt, I figure it should be a normal remote mapping

househoppin09
Posts: 536
Joined: 03 Aug 2016

03 May 2017

Weird... how does that work for you, though? Say you map your mod wheel to the tempo. How are you getting more than 128 values out of the mod wheel? (And how many values are you actually getting from it?) Or are you only getting the normal 128 values, but somehow constraining them to map to only a subset of the 0-999 tempo range?

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

03 May 2017

There's a knob while in transport mode automatically assigned to tempo on the P6. I can try mapping to mod wheel and see what happens. Perhaps it may be an advanced Lua function. If so that could explain why the cv method has limited control if midi control is limited to begin with.

househoppin09
Posts: 536
Joined: 03 Aug 2016

04 May 2017

Oh, I see. That would explain a lot. I'll be interested to hear what you find out if you do any further digging into that, thanks! :)

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

04 May 2017

Yep it's as you suspected. The P6 is doing something special. Tried mapping to a knob and it jumps by 8. Even larger margins with the modwheel. Regular midi is too limited to control it accurately. It was worth the adventure of finding out though

househoppin09
Posts: 536
Joined: 03 Aug 2016

04 May 2017

Interesting, thanks for checking on that. I'll probably want to look into this further--can you tell me what steps you followed on the P6 to get the smooth tempo control? (i.e. which knob or slider you had to use, what mode the unit needs to be in, etc.) And, if you have any educated guesses as to what special magic the P6 is using to allow such a capability, that would be helpful as well. You mentioned a custom Lua script--do you think that's the most likely explanation here? Can you think of any other possibilities? (Sorry this is dragging on so much, and I hope I'm not wasting too much of your time with it!)

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

05 May 2017

I think it may be a custom lua script that allows it. The Panorama is automatically programmed to smoothly control tempo in Reason when in transport mode. It has to be something more advanced than just midi given the results we both got with manual remote assignments.

househoppin09
Posts: 536
Joined: 03 Aug 2016

05 May 2017

Which knob/fader/etc. on the P6 are you using to control the tempo smoothly, though? I don't have one, but knowing which specific control you're using would allow me to do the necessary further research into how it works. Incidentally, and possibly related: I've also noticed that, when looking at lists of all of the remote-override sources the Panorama controllers are supposed to have, most are MIDI CCs and the like, but one is actually just called "TEMPO". I'm fairly clueless on the ins and outs of MIDI, but I'm guessing this means there's a special non-CC type of MIDI parameter that's specifically set aside to allow one device to communicate tempo information to another, directly and precisely. Could it be that the Panorama firmware is simply implementing some type of special case handling that maps the knob or slider (or whatever you're using to get the smooth tempo control) to that special "TEMPO" parameter, rather than to one of the ordinary CC parameters? If so, there may not be any scripting involved--it could just be that Nektar has done that work for you right in their firmware. I can probably find out easily enough from Nektar support if I know how to describe what process you're using to get the smooth tempo control.

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

05 May 2017

The Panorama has 8 encoders on the right hand side that work across 3 modes for it's mapping. They change function depending on what mode you're in. In transport mode, one of them is assigned to tempo. Could be maybe the 6th knob. That's the deepest answer I can give you as the process is automatic. I assume lua (there is a lua codec) is the culprit as to my knowledge (could be wrong) a remote map just sets source and destination for regular midi mapping.

I understand midi routing, but the actual programing of the Panorama goes over my head as it's beyond a simple remote map.

User avatar
Oquasec
Posts: 2849
Joined: 05 Mar 2017

05 May 2017

A transport bar module would be nice.
Producer/Programmer.
Reason, FLS and Cubase NFR user.

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 6 guests