whie haveing all the inlets be outlets on the sub patches [inlet] object continues the same visual metaphore nicely, i think i'd prefer it to have 1 object per inlet, so if i have 4 inlets i have the objects :
[inlet 1] [inlet 2] [inlet 3] [inlet 4]
this would save a little bit of speghetti chord clutter for me :)
-josh
Mathieu Bouchard wrote:
On 6 May 2003, jfm3 wrote:
I agree. I think the inlet object should take several symbolic arguments. Your abstraction should then get that many inlets, and the little inlet object box should take on that many outlets. Data sent to the first inlet will both come out of the first outlet of the inlet object box, and be sent to the first name after "inlet", etc.. This would be much more orthogonal to the way the ui elements work. The position of an object should bear as little semantic load as possible. Of course, inlet objects with *no* arguments should continue to work as they do now. Otherwise pretty much every patch in existence would break.
This is an interesting alternative to the (jMax-style) way that I proposed. Maybe I should have proposed the same thing as well, but I sticked to the non-broken solution that is closest to the PD-style. However your method sounds familiar because I am already using it in a dataflow system of my own, where object #-1 is the "flip side" of the patcher (its inlets are the patcher's outlets, and its outlets are the patcher's inlets). Naturally, for a visual system, it may be better to make that two separate objects like you propose.
(I'm still wondering which solution, the numbered [inlet]'s, or the single [inlet] with multiple outlets, is better.)
Mathieu Bouchard http://artengine.ca/matju
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list