How are people simulating AudioPlayHead playback in their dev environment?

Hi there,

Because JUCE’s AudioPluginHost is designed just to simulate audio/midi buffer inputs, the AudioPlayHead::CurrentPositionInfo passed to the plugin is defaulted (but not null).

I’m looking to simulate PlayHead playback, i.e. calls to getCurrentPositionInfo() return increasing ppqPositions at every audio callback.

There’s a number of ways this could be done, I’m wondering how people are doing it (most likely someone is doing it better than using a full DAW everytime a build occurs) - have you made your own AudioPluginHost, or have you modified JUCE’s implementation, etc. ?

Also, are there any plans to upgrade AudioPluginHost to include a transport or playhead?

This would be much appreciated especially for iOS/AUv3 dev where using something lightweight like AudioPluginHost can make a big difference over testing with cubasis, etc.


+1 to add transport functions! I‘m using Reaper to debug for this reason because it is really light.


Agreed, transport controls in the Plugin Host Demo would be nice.

1 Like

I wrote my own controls for that, that only appear when you’re in standalone mode.

The actual positioning is quite easy to implement, unless you apply some more complicated looping.

Anyway I agree that it would be very handy having it built in in the standalone plugin host, but maybe as a flag or just a component you can add manually?


+1 This would be a big time saver

1 Like

Shooting myself in the foot perhaps by playing devil’s advocate but I think it’s worthwhile to think this through out in the open. Because although it’s quite easy to implement, I can understand why it’s not there (much effort, low priority).
After implementing it myself for my specific needs, I can imagine many different cases to account for covering many different needs. If I have time, and it really is looking bleak to expect any action from JUCE, I’ll post my implementation.
And the unfortunate reality (imho) is that if the implementation is “basic” then user’s (me) will just revert back to building using a heavyweight daw (and deal with Ableton’s annoying crash notifications at every build).

My needs are no way advanced or complex but I already require the following just to have my plugin feel “at home” in Ableton:

  • BPM (using limits that account for all mainstream DAWs, Ableton requires 20 - 999)
  • synced seeking (with option for no sync), simulating Ableton’s different launch quantize options that are applied when jumping to different arrangement points during playback
  • Looping (making use of relevant looping members in CurrentPositionInfo)
  • Play, Restart Play, Continue Play, Stop/Pause and rewind.
  • Negative ppq_positions to simulate count-in.
  • (Optional) playback jogging.

That list shows already, why it’s not there. I implemented the sample counter, which was straight forward. But then BPM is already a can of worms:

  • how about tempo changes?
  • different beat signatures?
  • cue points?
    There are different paradigms for different workflows…

Todays pop producers always assume a track goes along in one tempo, that is actually an exception…


Very understandable, but then again on the other side of the argument, there are other JUCE examples/extras more complex than what we’re talking about here with even less usage than the Plugin Host.

I guess the best I can hope for is that JUCE realizes how ubiquitous and essential the Audio Plugin Host extra has become to the overall JUCE experience and upgrade it (at least in conceptual consideration) from an “extra” to a “main tool” in the JUCE framework. I argue that comprehensive playhead/transport features is a worthwhile step in this direction.

I think in that regard, the Audio Plugin Host is rather a proof of concept, that hosting plugins works relatively easy. The reference implementation is rather Tracktion (now Waveform).

But I would encourage you to implement that feature in a fork and send it as pull request. If you adhere to the Juce Coding Standards and write clean code, maybe you get good feedback and eventually it moves into the codebase.
The minimum you can get is a good code review, that gives a lot of experience…

I’d be happy to review as well, in case they are too busy… just give me a shout

What do you mean by this?

Contributing to JUCE in some way has always been on the radar for me some time after finishing up my current project, this is probably the most up my alley so I’m certainly considering it seriously.

I am speaking here as an outsider, but JUCE and Tracktion were written at the same time, so by implementing Tracktion they (or Jules that is) made sure, that JUCE is fit to create a full feature DAW.

I shouldn’t raise too many hopes, they can be quite specific, how they want the code base to be written (which is a good thing, all other users will appreciate that). But it can give a starting point for a movement…

But simply by trying and hopefully getting feedback, there is a lot to learn.

Understood. This implementation was likely to be the next tutorial I posted on my github which would combine my previous tutorial on Ableton Link integration. So it will be out there anyways even if not merged into JUCE.

1 Like

Hi, just wondering if there was any further progress on this before i go reinventing the wheel

was actually thinking about it this week after forgetting about it for many months. The main components are already done in my current project, the hard part is reimplementing it without any dependencies (I heavily use boost). I’m looking to set aside time to do this not too far away actually, in a month or so.