<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Am 20.12.20 um 11:49 schrieb Sven
      Jaehnichen:<br>
    </div>
    <blockquote type="cite"
      cite="mid:01e334e7-c7df-fada-a932-0cb9c1ff0b50@jahnichen.de">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <p>Hi,</p>
      <p>the old problem: control ports are READ_ONLY in LV2. Me and
        other plugin programmers struggle about it. I know it has been
        discussed here before and I know the workarounds (like
        parameters) and their limitations.</p>
      <p>Actually I read in unfa's software chat that the Surge
        programmers team are struggling about this problem too:<br>
      </p>
      <p> </p>
      <blockquote type="cite"><span><code class="code-colors inline">We
            made this choice because parts of the current LV2 spec and
            Surge are incompatible in a couple of ways, most importantly
            in the LV2 assumption that plugins never modify their
            control input port. Actions like ‘changing parameter types
            when an effect changes’ or ‘patch changes’ are not
            compatible with this design constraint. As a result, the LV2
            - especially in Ardour - unreliably saves and restores
            state. The solution - which we are working on - is to use
            new LV2 APIs that allow current Surge behavior (and match
            what other plugin specs like AU and VST do).</code></span><code></code><br>
      </blockquote>
      <p><br>
      </p>
      <p>My request: LV2 UI can call the host to change control port via
        the write_function(). I don't see such an option for the DSP
        instance. Why? It would be nice to have it. Or are there
        restrictions why it's impossible or problematic to implement?</p>
      <p>Best wishes<br>
        Sven<br>
      </p>
    </blockquote>
    <p><br>
    </p>
    <p>Yes, that would be nice.</p>
    <p>In the past I've worked around that by adding a output-port with
      NotOnGui and send a message from the plugin to the UI force the UI
      to send a value change for a input port. Drawback is, beside that
      it needs some care to avoid loopbacks, that this only work with
      the plugin GUI, not with the host provided UI.</p>
    <p>Using atom ports could be a solver, just, unfortunately the only
      host I found which fully support the patch:Set patch:Get extension
      is Qtractor. All other hosts I tried didn't handle those messages
      in the one or the other way, so that sync between host and plugin
      provided GUI didn't work. </p>
    <p><br>
    </p>
  </body>
</html>