VSTs - Sync to different (but proportional) BPM?

[B7 Music Studio]

I've been lurking on these forums awhile, finally registered since I couldn't find an answer to this question (so HI!).

Is there a script/plugin I can use to PROPORTIONALLY modify the clock/bpm that is sent to the VST on a certain track?

Context: I sometimes use built-in loops (usually in Kontakt 4). Kontakt automatically synchronizes to the track, which is great, except that sometimes the track is in, say, 220 bpm and I want the loop playing at 110bpm. I KNOW I CAN SET THE BPM IN KONTAKT manually, but then it doesn't take into account any changes in the playrate. Sometimes I write rubato phrasing into the master track "playrate", and I frequently render different speeds of a track (fullspeed, 90percent, etc) for my students to practice with. If I manually enter the bpm, I have to go in and recalculate it each time, and certainly it can't take into account the master playrate automation curve.

What I need is a script that essentially changes the overall position in the track proportionally. Expressed kind of crudely:

Input Global Time --> multiply by factor (.5, .6666, 1.25,...) --> Output "fake" Time


Lastly: I posted this in the right place, right?

[B7 Music Studio]

Soo... anyone? It's very quiet here. Sorry to bring the thread back, the issue is just a regular annoyance to me and I imagine I'm not the only one who has encountered it.

[BRBWaffles]

Use a BPM/millisecond conversion chart and program it yourself. Most plugins that sync to BPM or notes also allow you to sync to milliseconds. Using one of the many conversion charts online could accomplish what you're asking. Personally, I use these charts to find my starting points for compressor release times mostly.

[B7 Music Studio]

BRBWaffles - thank you. I think I get what you mean, although my meager programming knowledge is making it hard for me to find the right thing.

In the mean time, a work-around that's good enough for me: Set Kontakt to output Script-generated MIDI notes and CC, then use reaper to "record MIDI output" to a new track. Now it's a plain MIDI track and I can circumvent the sequencer-script altogether.

[BRBWaffles]

Originally Posted by B7 Music Studio

BRBWaffles - thank you. I think I get what you mean, although my meager programming knowledge is making it hard for me to find the right thing.

In the mean time, a work-around that's good enough for me: Set Kontakt to output Script-generated MIDI notes and CC, then use reaper to "record MIDI output" to a new track. Now it's a plain MIDI track and I can circumvent the sequencer-script altogether.

http://www.sengpielaudio.com/calcula...mtempotime.htm

This is the site that I use. It even has a BPM to millisecond calculator. Just choose whatever tempo you want, find the correct note, and then it gives you that note in milliseconds.

For example, if you have a song in 180 BPM, but you wanted a VST to be operating at 1/3 that tempo, you could find 60 BPM and use the notes to set your plugin.

[B7 Music Studio]

Originally Posted by BRBWaffles

http://www.sengpielaudio.com/calcula...mtempotime.htm

This is the site that I use. It even has a BPM to millisecond calculator. Just choose whatever tempo you want, find the correct note, and then it gives you that note in milliseconds.

For example, if you have a song in 180 BPM, but you wanted a VST to be operating at 1/3 that tempo, you could find 60 BPM and use the notes to set your plugin.

Now that I see this, I'm pretty sure it's not what I need - I wanted something that takes the global time input (in real time), and converts it proportionally to relative time for a single track, so that the sequencer plugin spits out its music at a different rate.

From what I've read today, I don't think it's possible without editing the script of the plugin itself. Basically, time is global in most DAWs and you can't mess with it for individual tracks, so any adjustment has to be made within the sequencer/plugin and how it interprets incoming stuff (clock).

[BRBWaffles]

Originally Posted by B7 Music Studio

Now that I see this, I'm pretty sure it's not what I need - I wanted something that takes the global time input (in real time), and converts it proportionally to relative time for a single track, so that the sequencer plugin spits out its music at a different rate.

From what I've read today, I don't think it's possible without editing the script of the plugin itself. Basically, time is global in most DAWs and you can't mess with it for individual tracks, so any adjustment has to be made within the sequencer/plugin and how it interprets incoming stuff (clock).

Could you not just edit that single track in a different session with the different timing and import the stem into the original session? I guess I'm a bit confused.

[B7 Music Studio]

Originally Posted by BRBWaffles

Could you not just edit that single track in a different session with the different timing and import the stem into the original session? I guess I'm a bit confused.

I could, but it wouldn't help my work-flow. Concrete example:

I have a song (all MIDI) at 180bpm. I find a great pre-programmed djembe loop, but it's too fast - I want it half as fast. So I manually override the bpm in the plugin to be 90bpm. Works wonderfully!

Now the problem: I want to be able to (repeatedly, if necessary) render the piece at 180bpm and 162bpm. If I change the playrate of the project, Kontakt won't automatically go down to 81bpm. I can go in and manually change it each time, but I was specifically wondering if it could be automated. I could also change the original file into two files, but then if I make any edits, I have to duplicate them between the files. If I render to a stem, that wouldn't allow me to change tempo at all without time-stretching.

In short: Maybe the confusion is that I'm trying to find a way to automate something that's pretty simple to do in the first place. I just need it a lot because I render practice tracks for students at multiple speeds, and was hoping to streamline my workflow.

I think this issue is pretty much resolved though (I found the workaround mentioned earlier), so perhaps it's time to end this thread.