Set AudioPlayHead position

Is there a simple way to derive from AudioPlayHead that allows us to set the DAW’s playhead position, while still retaining the DAW’s ability to start/stop playback natively? Ideally, I would like to be able to call something like setPlaybackPosition once, and the playhead continues moving from that point automatically.

It seems like if I tell the AudioProcessor to use a custom AudioPlayHead, I have to fill out the CurrentPositionInfo myself, without the possibility to get the current playback position provided by the DAW and change it only if I need to. Is this assessment correct? Do I really need to take control of the entire Playhead, incrementing the current sample time etc. myself?

1 Like

I don’t think seeking in the host’s timeline is part of the standard plugin APIs (at least most of them), so it would not be supported by JUCE.

Forgive me if I’m wrong, but to me it looks like the JUCE implementations for each format use getPlayHead()->getCurrentPosition() to modify the host parameters accordingly, at least for VST and AU plugins:


Those are the implementations in JUCE for hosting those plugin formats, not the plugin client code. (Which allows JUCE AudioProcessors to run as VST, AU etc plugins.)

The plugin client codes are located at :

1 Like

Thanks for the clarification. Wouldn’t the code inside the hosting code imply that manipulating the host’s timeline position would be possible at least in VST and AU plugins?

Waves plugins (e.g. Waves Tune) pull this off using their “ReWire” technology. I’m not sure how that works, but it shows that it’s possible in one way or the other.

Edit: I just realized that ReWire is not a Waves technology. I got confused by them having a “Waves ReWire” utility plugin. I’ve researched this a bit, and according to Jules, getting it to work is a “PITA”, so I probably won’t bother with that for now.

The vstHostTime struct that is manipulated in the JUCE VST2 plugin hosting code is the struct that is passed for the hosted VST2 plugin when the plugin requests for it. The time position info is never read back from the struct, so even if the plugin tried manipulating the data, nothing would happen in the JUCE hosting code. It is theoretically possible some other host could detect the position info was changed by the plugin and then seek on its timeline but I would not expect that to happen with any commonly known host. (If that actually was something that could be expected work, JUCE probably would have added support in the AudioPlayHead class.)

1 Like

That makes full sense. Thank you for your help!

This is the best implementation I could find online of getting bpm without errors!

1 Like

Update: I’ve implemented setting the playhead position using the ReWire protocol. Yes, it was a PITA. No, I can’t recommend it to anyone unless they really really need it.

Did you still use JUCE or did you work in the ReWire stuff outside the JUCE ecosystem?

I’m looking at a use case which probably only ReWire can solve so I’m wondering if you would share your experience to help me pick the right path and reduce the PITAness :wink:


I did it without JUCE. You need a developer license from Propellerhead to get access to the SDK. It’s really not nice to work with, but I can help you if you really wanna go that route.

Hey @nonlethalapplications and @CrushedPixel what about how Neyrinck goes about doing it? creating a virtual control surface that some process can communicate with…

What exactly are you on about?

I had his Vcontrol app for iPad a few years ago. To use it, you install an app on your desktop computer that acts as a virtual control surface for your DAW. The iPad app talks to this control surface, which controls the DAW. No idea if they use the HUI protocol or what. Maybe OSC protocol can be used?