[PD] getting [inlet~] to accept data

[Miller Puckette]

It's a bug that conrol values aren't promoted to signals when appropriate
by inlet~ objects - I tried to figure out how to fix this a couple of years
ago but couldn't immediately figure it out...

cheers
Miller

On Sat, Sep 19, 2015 at 11:20:47PM -0400, Ivica Bukvic wrote:
> While I don't know much about the draw group yet, it is conceivably
> possible the order by which inlets are created and depending on what kind
> they are could have something to do with it.
> 
> Best,
> 
> -- 
> 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
> On Sep 19, 2015 11:11 PM, "Jonathan Wilkes via Pd-list" <
> pd-list at lists.iem.at> wrote:
> 
> > It doesn't look to be much different atm.
> >
> > In fact, I can't even figure out how subpatches actually reorder their
> > inlets and outlets when you add new [inlet] and [outlet] objects inside
> > them.  I have an
> > object in Pd-l2ork called [draw group], which is essentially just a
> > subpatch
> > with an inlet-- to set graphical attributes-- and an outlet-- to receive
> > event
> > notifications.  Thing is, my extra outlet will appear as the leftmost
> > outlet when I
> > load the patch, while my extra inlet will always be the furthest to the
> > right (like
> > with the pointer inlet in [append].)
> >
> > Looking at the reordering code for inlets vs. outlets, I can't see any
> > obvious
> > differences.
> >
> > -Jonathan
> >
> >
> >
> > On Saturday, September 19, 2015 10:50 PM, Matt Barber <brbrofsvl at gmail.com>
> > wrote:
> >
> >
> > I worked on this for a while in 2008. A big part of the problem is that
> > the architecture for first/main inlets is quite different from generic
> > inlets, which do not respond to both signals and messages. [inlet~] does
> > (or at least is supposed to) promote floats to signals, but it won't pass
> > other kinds of messages; and it seemed like too deep a problem to be solved
> > without a pretty serious overhaul. This was a number of years ago and
> > things may have changed since then, but I don't think so (though I'd be
> > glad to be wrong).
> >
> > Matt
> >
> > On Fri, Sep 18, 2015 at 11:04 AM, Christof Ressi <christof.ressi at gmx.at>
> > wrote:
> >
> > I was wondering about that too! After a quick search in the mailarchives
> > I've found this discussion from 2008:
> > http://lists.puredata.info/pipermail/pd-list/2008-06/062895.html
> >
> > @IOhannes: What's the state now? How difficult would it be to make an
> > [inlet~] external which, for example, passes signals to a left outlet and
> > all messages (also floats!) to a right outlet. Or which passes everything
> > it receives and then you could use [route~] from zexy to separate signals
> > from messages?
> >
> >
> >
> > *Gesendet:* Freitag, 18. September 2015 um 12:49 Uhr
> > *Von:* "Liam Goodacre" <liamg_uw at hotmail.com>
> > *An:* "pd-list at lists.iem.at" <pd-list at lists.iem.at>
> > *Betreff:* [PD] getting [inlet~] to accept data
> > Many objects (ie. [osc~]) have a sort of a hybrid inlet which accepts both
> > signal and data input. However, the [inlet~] object seems to reject data.
> > If I wanted to build an abstraction with an [inlet~] that accepts both
> > signal and data, is there any other way?
> > _______________________________________________ Pd-list at lists.iem.at
> > mailing list UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
> >

> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list