Re: Bad visual feedback for KORG nanoKONTROL 2

--===============6084327412738693455==
Content-Type: multipart/alternative; boundary="94eb2c115a5e25a3610557bf54a9"

--94eb2c115a5e25a3610557bf54a9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 27, 2017 at 12:58 PM, David Kastrup <[email protected]> wrote:

> =E2=80=8B
>
> There will be ever new control devices in years to come.  Having to
> recompile for every single one of them is not a desirable feature, so
> the question is what the best way to change that would be.
>

=E2=80=8BI don't see things this way, sorry. I have no interest or desire t=
o make
it possible for people to write control surface support in a non-compiled
lanuage, although that is already possible theoretically using lua.

If you look at Reaper and Bitwig, they have control surface support
implemented in various non-compiled languages (Javascript for Bitwig), and
I don't think it really has a dramatic impact on their control surface
support. To the extent that it does, it also creates a divide between
developers willing and able to work on the compiled aspects of surface
support and the scripted parts, which has its own set of downsides.=E2=80=
=8B

If someone really believes that they can refactor the existing control
surface support, integrate it with a scripted/non-compiled language, and
then implement new surface support with the result: prove me wrong. Untiil
then, it just isn't a high priority item to bridge the gap between "i'm
willing to write software as long as i don't have to compile" and "i'm
willing to compile ardour".
=E2=80=8B

--94eb2c115a5e25a3610557bf54a9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif"><br></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On Sun, Aug 27, 2017 at 12:58 PM, David Kastrup <span dir=3D"l=
tr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><div sty=
le=3D"font-family:arial,helvetica,sans-serif;display:inline" class=3D"gmail=
_default">=E2=80=8B<br></div></span>
<br>
There will be ever new control devices in years to come.=C2=A0 Having to<br=
>
recompile for every single one of them is not a desirable feature, so<br>
the question is what the best way to change that would be.<br></blockquote>=
<div><br><div style=3D"font-family:arial,helvetica,sans-serif" class=3D"gma=
il_default">=E2=80=8BI don&#39;t see things this way, sorry. I have no inte=
rest or desire to make it possible for people to write control surface supp=
ort in a non-compiled lanuage, although that is already possible theoretica=
lly using lua.<br><br></div><div style=3D"font-family:arial,helvetica,sans-=
serif" class=3D"gmail_default">If you look at Reaper and Bitwig, they have =
control surface support implemented in various non-compiled languages (Java=
script for Bitwig), and I don&#39;t think it really has a dramatic impact o=
n their control surface support. To the extent that it does, it also create=
s a divide between developers willing and able to work on the compiled aspe=
cts of surface support and the scripted parts, which has its own set of dow=
nsides.=E2=80=8B<br><br></div><div style=3D"font-family:arial,helvetica,san=
s-serif" class=3D"gmail_default">If someone really believes that they can r=
efactor the existing control surface support, integrate it with a scripted/=
non-compiled language, and then implement new surface support with the resu=
lt: prove me wrong. Untiil then, it just isn&#39;t a high priority item to =
bridge the gap between &quot;i&#39;m willing to write software as long as i=
 don&#39;t have to compile&quot; and &quot;i&#39;m willing to compile ardou=
r&quot;. <br></div><div style=3D"font-family:arial,helvetica,sans-serif" cl=
ass=3D"gmail_default">=E2=80=8B<br></div></div></div></div></div>

--94eb2c115a5e25a3610557bf54a9--

--===============6084327412738693455==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ardour-dev mailing list
[email protected]
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

--===============6084327412738693455==--