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