well, by using [array set] it gives you the "warning: *arrayname*: multiply defined", so there you go... I say this is not "value" behaviour, as you still only have one defined array to access
2018-05-07 15:11 GMT-03:00 Alexandre Torres Porres <por...@gmail.com>: > I didnt know you could have two [array define] with the same name without > printing "warning: *arrayname*: multiply defined", and this feels like a > bug to me, because what's the use case here? I treid using [array set] and > it only did set one of the arrays... (the first one) > > 2018-05-07 13:41 GMT-03:00 Liam Goodacre <liamg...@hotmail.com>: > >> Seems like the "value behaviour" is something that could be implemented >> in [array define] with a new flag, right? >> >> >> Correct me if I'm wrong, but the [array] objects already have [value] >> like behavior, in that you can have multiple objects referencing the same >> array. The difference is that with [value], the reference is implicit while >> with [array] it is explicit (ie. [array define]). >> >> The only thing a flag could do would be to tell [array define] to accept >> the first instance of a particular argument and reject the rest. But this >> would lead to a lot of confusion since you could have lots of empty [array >> define]'s scattered around the place. >> >> The best solution is surely to put the array in a parent patch of the >> abstraction. If you don't mind putting it there yourself, you can do as >> Ingo suggested. If you want it to happen automatically, then there are neat >> dynamic patching solutions available. >> >> ------------------------------ >> *From:* Pd-list <pd-list-boun...@lists.iem.at> on behalf of Alexandre >> Torres Porres <por...@gmail.com> >> *Sent:* 07 May 2018 15:46 >> *To:* Pd-list >> *Subject:* Re: [PD] static array/text >> >> Seems like the "value behaviour" is something that could be implemented >> in [array define] with a new flag, right? >> >> 2018-05-07 10:19 GMT-03:00 Antoine Rousseau <anto...@metalu.net>: >> >> In moonlib you can find [sarray] and [slist], which implement the [value] >> behaviour (i.e multiple declarations of a shared data) for array and list >> of symbols. >> They are also dynamically re-assignable. >> >> >> Antoine Rousseau >> http://www.metalu.net <http://metalu.net> __ htt >> p://www.metaluachahuter.com/ >> <http://www.metaluachahuter.com/compagnies/al1-ant1/> >> >> >> 2018-05-07 13:47 GMT+02:00 Ingo Stock <m...@ingostock.de>: >> >> Maybe you can just put the text/array object into the main file, like in >> the attached demo? >> >> best, ingo >> >> >> On 05/07/2018 12:02 AM, Dan Wilcox wrote: >> > Is there one way to define a "static" table or text data that can be >> > shared among abstractions? I have a few abstractions which use lookup >> > tables and I realize now that they are basically creating a copy with >> > each instance when they could really share the same data directly. I >> > suppose this would be somewhat related to [value]. >> > >> > -------- >> > Dan Wilcox >> > @danomatika <http://twitter.com/danomatika> >> > danomatika.com <http://danomatika.com> >> > robotcowboy.com <http://robotcowboy.com> >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Pd-list@lists.iem.at mailing list >> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/li >> stinfo/pd-list >> > >> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li >> stinfo/pd-list >> >> >> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li >> stinfo/pd-list >> >> >> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li >> stinfo/pd-list >> >> >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list