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 
<brbrof...@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.re...@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...@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


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

Reply via email to