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?
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@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@hotmail.com *An:* "pd-list@lists.iem.at" pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 anobject in Pd-l2ork called [draw group], which is essentially just a subpatchwith an inlet-- to set graphical attributes-- and an outlet-- to receive eventnotifications. Thing is, my extra outlet will appear as the leftmost outlet when Iload the patch, while my extra inlet will always be the furthest to the right (likewith the pointer inlet in [append].) Looking at the reordering code for inlets vs. outlets, I can't see any obviousdifferences. -Jonathan
On Saturday, September 19, 2015 10:50 PM, Matt Barber <brbrofsvl@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@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%C2%A0@IOhan...: 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@hotmail.com An: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: [PD] getting [inlet~] to accept dataMany 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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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,
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@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@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@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@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@hotmail.com *An:* "pd-list@lists.iem.at" pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
Ivica Bukvic -
Jonathan Wilkes -
Liam Goodacre -
Matt Barber -
Miller Puckette