VST~ ReaktorFX and Tempo Sync
Sep 28, 2009 at 1:53pm
VST~ ReaktorFX and Tempo Sync
The docs on the VST object don’t seem to detail this aspect other than to generally say that the VST object does sync to the transport. Can anyone shed some light on this?
Sep 28, 2009 at 3:35pm
Apparently it’s not just isolated to Reaktor as I’ve tried a few more plug-ins that can sync externally, multi-tap delays and such, and I can’t get anything to lock up. So I must still be doing something wrong or maybe this just doesn’t work, perhaps?
Still hackin away at it.
Sep 28, 2009 at 6:55pm
First, I’ll tell you why it didn’t work, and how you know that. Then, I’ll tell you what does work.
If you stick a print object on the output of the tempo object and look at what’s coming out, you’ll see why nothing’s happening (since I don’t have a copy of your patch, I’m presuming you’ve just plunked a transport object down in your patch and turned it on). As the help file demonstrates, you’ve got have a way to have the transport clocked to get current output.
If you *have* done that, then the print object should show you what the transport object’s sending out whenever it gets a bang – the current tempo as a number. If you just connected that outlet to the inlet of the vst~ object, you might want to compare that to the messages that the vst~ object expects to get (which you can do by positioning your cursor over the inlets to the vst~ object and clicking to see the list of messages. If you’ve got your Clue Window visible, positioning your cursor over any one of those messages will tell you what the message does, even], it should be clear why nothing’s happening – you’re choosing the preset whose number corresponds to the current tempo.
That’s why it’s not working.
Try just turning the Global Transport *on* (under Extras > GlobalTransport). Works fine here (Guru into Echomania II). Looking at the help file suggests why you started connecting things as you did. I think that could be clearer, and I’ll see about modifying it.
I typed all of the rest of this to suggest that there are ways of finding out WHY what you had didn’t work. That knowledge might be of some use to you even while you’re waiting for the answer to your question, and even more use to you if you don’t GET an answer. Max is pretty nice in the sense that when it comes to the interaction of objects, you have the message that an object sends out, a list of the messages that any other Max object understands, and (I hope) some sense of how to turn one kind of message into another [floats > ints, prepend, append, pack, etc.]. When things don’t work as you expect, that’s a good place to start. Always.
Sep 28, 2009 at 9:33pm
Thanks Gregory . . .
That’s what I thought, since the description of “objects that Support Time Values” states:
“vst~ no time-based values accepted, but listed here because it synchronizes plug-in with transport”
Makes sense since it’s the “Global Transport” that it would just provide sync behind the scenes, so to speak. But so far I’ve had no luck with getting things to sync to that. I’ll keep futzing with it though.
I appreciate that and yes, I have been looking at that stuff carefully. My test patch is very simple for now, consisting of just a file player, the VST and DAC objects.
Sep 28, 2009 at 11:03pm
I’m not doing anything exotic.
I’ve got a vst~ object with the Guru plug-in in it.
Output of that into the Reaktor 5 FX plug-in.
The Reaktor FX plug-in’s got the Echomania II ensemble loaded.
When I start audio and turn on the GlobalTransport, Guru reports the same Tempo as I have set in the GlobalTransport. If I wiggle the tempo, the drumbox tempo changes.
When I look at the Echomania II front panel, the tempo used for setting values is the same as what Guru uses. The delay lines change when I change the GlobalTransport, as above.
If I put a phasor~ object into my patch with a note value selected, it runs at the same tempo as the drumbox and the echo stuff.
If I want to use that tempo data to control something else in the patch, I figure out what parameter I want to control by getting a dump of the parameters in the plug-in (see the vst~ helpfile), check the range of the values, and then use the translate object to convert tempo to milliseconds or hz or whatever, then scale format that value as a plug-in parameter message and send it in (by scaling the number maybe, and using the usual Max message tools to construct a message the vst~ object will understand).
Sep 29, 2009 at 12:29am
Ha! Restarted Max and created a new patch, now it’s working fine! I must have gotten Max confused by creating an actual transport object in the patch, rather than just invoking the global transport. So I guess it’s not a good idea to cable a transport into a vst~! It made the global transport go wonky even after deleting the one in the patch. I’ll know better now.
You must be logged in to reply to this topic.