# Communication channels between audio-processor and its editor (instead of directly accessing objects)

**URL:** <https://forum.juce.com/t/communication-channels-between-audio-processor-and-its-editor-instead-of-directly-accessing-objects/31984>\
**Category:** Feature Requests\
**Created:** [February 26, 2019, 9:08am UTC](https://forum.juce.com/t/communication-channels-between-audio-processor-and-its-editor-instead-of-directly-accessing-objects/31984 "2019-02-26T09:08:04Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![yairadix](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yairadix/32/1114_2.png) [@yairadix](https://forum.juce.com/u/yairadix)\
**Post date:** [February 26, 2019, 9:08am UTC](https://forum.juce.com/t/communication-channels-between-audio-processor-and-its-editor-instead-of-directly-accessing-objects/31984/1 "2019-02-26T09:08:04Z")

</div>

Iiuc, SOUL-Lang based plugins, AAX DSP plugins, WPAPI plugins, and even old school Audio-Units distributed with [Logic Node](https://www.soundonsound.com/techniques/setting-logic-node)s, all require communication channels between audio processors and their editors, which may run on different machines, and so are unable to access the corresponding object directly via pointers in memory.

I’m certain that there are parties who have strong interests to add AAX DSP and WPAPI to JUCE, but unfortunately they have no clear path to do it now because JUCE doesn’t have the relevant APIs for the required communications. If JUCE would add the necessary channels, AAX DSP and WPAPI support could be added to JUCE and it will ultimately be a big win for the live audio crowd which will get a better selection of available plugins.

---

<div class="post-metadata">

**Author:** ![adamwilson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/adamwilson/32/1387_2.png) [@adamwilson](https://forum.juce.com/u/adamwilson)\
**Post date:** [February 26, 2019, 10:40am UTC](https://forum.juce.com/t/communication-channels-between-audio-processor-and-its-editor-instead-of-directly-accessing-objects/31984/2 "2019-02-26T10:40:24Z")

</div>

This would also promote cleaner separation of GUI code from the audio processing/logic/data layers.

---

<div class="post-metadata">

**Author:** ![lob](https://avatars.discourse-cdn.com/v4/letter/l/ecae2f/32.png) [@lob](https://forum.juce.com/u/lob)\
**Post date:** [March 13, 2019, 2:45am UTC](https://forum.juce.com/t/communication-channels-between-audio-processor-and-its-editor-instead-of-directly-accessing-objects/31984/3 "2019-03-13T02:45:33Z")

</div>

I am not an experienced programmer. I am setting up synchronized ValueTrees. Will this be legit for most purposes?

---

<div class="post-metadata">

**Author:** ![jrlanglois](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/jrlanglois/32/21372_2.png) [@jrlanglois](https://forum.juce.com/u/jrlanglois)\
**Post date:** [August 24, 2020, 1:39pm UTC](https://forum.juce.com/t/communication-channels-between-audio-processor-and-its-editor-instead-of-directly-accessing-objects/31984/4 "2020-08-24T13:39:20Z")

</div>

This thread reminds me of Vinnie Falco’s VFLib, specifically the concurrency module: [https://github.com/vinniefalco/VFLib/tree/master/modules/vf\_concurrent/threads](https://github.com/vinniefalco/VFLib/tree/master/modules/vf_concurrent/threads) .

With this system, in the most simplest terms, you would have a `CallQueue` and set values into it from your main thread (eg: UI thread), and read them out in your audio callback (eg: `processBlock`). There’s a lot of scaffolding but I’m sure you can figure it out if you’re curious.