[L2Ork-dev] Non-signal *left* inlet visualization of a dsp object

Albert Graef aggraef at gmail.com
Tue Feb 21 17:48:52 UTC 2017


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).

On Tue, Feb 21, 2017 at 6:04 PM, Ivica Bukvic <ico at vt.edu> wrote:

> 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.
>
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> ico at vt.edu
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
>
> On Feb 21, 2017 11:51, "Albert Graef" <aggraef at gmail.com> wrote:
>
>> On Tue, Feb 21, 2017 at 3:16 PM, Alexandre Torres Porres <
>> porres at gmail.com> wrote:
>>
>>> i'd like to challenge the notion of "all signal objects", see cyclone's
>>> [click~] for instance.
>>
>>
>> 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: https://www.mail-archive.com/pd-list@lists.iem.at/msg07016.html
>>
>> 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.
>>
>> Anyway, thanks for pointing me to that example, I think I know where to
>> dig next now. :)
>>
>> Best,
>> Albert
>>
>> --
>> Dr. Albert Gr"af
>> Computer Music Research Group, JGU Mainz, Germany
>> Email:  aggraef at gmail.com
>> WWW:    https://plus.google.com/+AlbertGraef
>>
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> http://disis.music.vt.edu/listinfo/l2ork-dev
>>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> http://disis.music.vt.edu/listinfo/l2ork-dev
>



-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email:  aggraef at gmail.com
WWW:    https://plus.google.com/+AlbertGraef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20170221/2e9edccc/attachment.html>


More information about the L2Ork-dev mailing list