atom feed21 messages in at.iem.pd-listRe: [PD] tabwriteat~ object
FromSent OnAttachments
Frank BarknechtAug 3, 2009 5:50 am.tgz
Miller PucketteAug 3, 2009 12:30 pm 
Jonathan WilkesAug 3, 2009 1:46 pm 
ypatiosAug 3, 2009 2:13 pm 
Frank BarknechtAug 3, 2009 2:36 pm 
Frank BarknechtAug 3, 2009 2:44 pm 
ypatiosAug 3, 2009 3:43 pm 
Jaime OliverAug 3, 2009 3:51 pm 
Matt BarberAug 3, 2009 4:44 pm 
Chris McCormickAug 3, 2009 5:00 pm 
Charles HenryAug 4, 2009 6:00 am 
Frank BarknechtAug 4, 2009 6:21 am 
Miller PucketteAug 4, 2009 8:01 am 
hard offAug 6, 2009 3:16 am 
Miller PucketteAug 6, 2009 9:41 am 
Frank BarknechtAug 6, 2009 10:06 am 
Charles HenryAug 6, 2009 10:31 am 
Mike Moser-BoothAug 6, 2009 11:03 am 
Frank BarknechtAug 6, 2009 12:01 pm 
Matt BarberAug 7, 2009 6:42 am 
Derek HolzerAug 7, 2009 7:23 am 
Subject:Re: [PD] tabwriteat~ object
From:Frank Barknecht (fb@footils.org)
Date:Aug 4, 2009 6:21:32 am
List:at.iem.pd-list

Hallo, Charles Henry hat gesagt: // Charles Henry wrote:

Doesn't tabwrite~ have a second inlet to set the name of the array (It's been awhile)? If so, then what harm could there be in re-writing the object with 3 inlets? Would it break something?

It just has one inlet, you change the table to set with "set NAME" messages into the first inlet.

So, yes, adding a second inlet should not change anything there. But it gets a bit tricky later on: How should you deal with a [bang( message that goes into the first inlet when there's something connected to the new audio-index inlet? There is a conflict of interest, which IMO is better solved with a new object.

Actually I like the name [tabfeed~], as it somehow describes, that with audio index inlets you kind of constantly feed data into the table.

Ciao

-- Frank

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