<div dir="ltr"><div>JACK already supports MIDI data. Presumably if you are using notes, you would use that.<br><br></div>But again, I wasn't proposing "one jack client per effect" ... I was proposing only a single JACK client per application, and NOT using JACK's audio graph capabilities within your application: you would need to compute execution order yourself or use a nice library for this (not that there necessarily are any nice libraries).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 11, 2015 at 6:26 AM, Johannes Lorenz <span dir="ltr"><<a href="mailto:johannes89@mailueberfall.de" target="_blank">johannes89@mailueberfall.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am Donnerstag, 9. April 2015, 09:00:38 schrieben Sie:<br>
<span class="">> Speaking entirely personally, I think this design is just plain nuts. I<br>
> know there are some JACK-ecosystem developers who disagree with me, but I<br>
> think that using JACK clients for this purpose is just wrong and is pushing<br>
> the design scope for JACK.<br>
<br>
</span>Ok, let's say I'll do what multiple people proposed here: one jack client per effect + only data exchange between effects via jack ports.<br>
<br>
Then see this example:<br>
<br>
    piano roll   ----- (notes) -----> synthesizer<br>
<br>
How should one transfer notes using a jack buffer? Of course, one could make a structure to transfer notes, cast this structure to const char*, and *hope* it fits into the port buffer. Is there any better way? Maybe a "custom port type"?<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Jack-Devel mailing list<br>
<a href="mailto:Jack-Devel@lists.jackaudio.org">Jack-Devel@lists.jackaudio.org</a><br>
<a href="http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org" target="_blank">http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org</a><br>
</div></div></blockquote></div><br></div>