<div dir="ltr">Well, just to clarify, it's clear now that Pd-l2ork doesn't do anything wrong in this specific example, in fact it let me *discover* this bug (never would have noticed in vanilla, since all xlets look the same there). And it's surely a bug in *my* code (must have goofed somewhere in pd-pure's inlet configuration code).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 21, 2017 at 6:04 PM, Ivica Bukvic <span dir="ltr"><<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Based on this discussion, I think it may be also worth entertaining the idea that we would want to set up a more strict set of checks and balances by which we would prevent objects connecting to specifically inlets and outlets within abstractions depending on the kinds of objects they're connected to below them. I understand this could introduce major compatibility breakages, so it may be something we would have to encapsulate inside the Legacy flag. Personally, I feel this would be a step in the right direction that would further help newcomers better understand the interaction between the two different kinds of nlets. This may require a separate kind of an object that provides at ability to distinguish between the two kinds of data. <br><br><div data-smartmail="gmail_signature">-- <br>Ivica Ico Bukvic, D.M.A.<br>Associate Professor<br>Computer Music<br>ICAT Senior Fellow<br>Director -- DISIS, L2Ork<br>Virginia Tech<br>School of Performing Arts – 0141<br>Blacksburg, VA 24061<br>(540) 231-6139<br><a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a><br><a href="http://www.performingarts.vt.edu" target="_blank">www.performingarts.vt.edu</a><br><a href="http://disis.icat.vt.edu" target="_blank">disis.icat.vt.edu</a><br><a href="http://l2ork.icat.vt.edu" target="_blank">l2ork.icat.vt.edu</a><br><a href="http://ico.bukvic.net" target="_blank">ico.bukvic.net</a></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Feb 21, 2017 11:51, "Albert Graef" <<a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 21, 2017 at 3:16 PM, Alexandre Torres Porres <span dir="ltr"><<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">i'd like to challenge the notion of "all signal objects", see cyclone's [click~] for instance.</blockquote></div><br></div><div class="gmail_extra">Interesting. However, while googling this issue I've read on the Pd mailing lists that cyclone does its own magic for setting up the inlets (sic_setup, sic_inlet). At least that's what I deduce from this thread here: <a href="https://www.mail-archive.com/pd-list@lists.iem.at/msg07016.html" target="_blank">https://www.mail-archive.com/p<wbr>d-list@lists.iem.at/msg07016.h<wbr>tml</a><br><br>So quite obviously it's not a display issue then, must be an issue with my faust~ external after all. But it does work all right, i.e., the leftmost inlet certainly processes control messages as it's supposed to. Strangely enough, that inlet in fact does accept signal connections, too, even though I've set it up to do control processing and nothing else. So that might be one of those "conveniences" that Pd sets up by default, but I haven't been able to figure out how to disable it yet. Maybe I should have a look at those cyclone routines to see whether there's some incantation that I'm missing in my code.<br><br></div><div class="gmail_extra">Anyway, thanks for pointing me to that example, I think I know where to dig next now. :)<br><br></div><div class="gmail_extra">Best,<br></div><div class="gmail_extra">Albert<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="m_-6189651343500630072m_9086622868057777118gmail_signature"><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a><br>WWW: <a href="https://plus.google.com/+AlbertGraef" target="_blank">https://plus.google.com/+Albe<wbr>rtGraef</a></div></div>
</div></div>
<br></div></div><span class="">______________________________<wbr>_________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="http://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">http://disis.music.vt.edu/list<wbr>info/l2ork-dev</a><br></span></blockquote></div></div>
<br>______________________________<wbr>_________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="http://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">http://disis.music.vt.edu/<wbr>listinfo/l2ork-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a><br>WWW: <a href="https://plus.google.com/+AlbertGraef" target="_blank">https://plus.google.com/+AlbertGraef</a></div></div>
</div>