come to think of it: why do we have an issue (or three) open, if we keep 
repeating the arguments here?
Am 5. März 2021 20:35:50 MEZ schrieb William Huston <williamahus...@gmail.com>:
> 
> It seems quite unexpected behavior, but yes I can do range checking.

i dont know.
its been there for 20+ years and I cannot remember many complaints.

but: 

> And agree w/Alex this behavior should be documented.


yes totally. I think everybody agrees here.

> > >     - *Feature Request: allow a [clone] instance to know the total
> > number of
> > >     instances #1279*
> > >     https://github.com/pure-data/pure-data/issues/1279
> >
> > i was under the impression, that in the end everybody agreed that
> this
> > feature doesn't buy us anything.
> >
> 
> Well, I don't think everyone did agree.

sure, at least one disagrees.
but there weren't that many voices in the discussion (I take that as a lack of 
interest)

> 
> Well, I understand. But maybe there is a simple solution no one has
> dreamed
> up.


maybe.
but there are only so many ways you can pass information from one side to the 
other:
- have the owner of the information actively promote it to the clients
- add some possibility to the client to query the info

the latter lacks the possibility to re-use the info as arguments for child 
objects, which I think makes it practically useless.

the former does not, but we already have that. just think of it as a variably 
named flag whose name happens to match the number of clones :-P

more seriously:
imagine a patch that consists of multiple parallel [clone] objects that 
together form N "voices", even though there are multiple (sub)classes of these 
voices (eg an ambisonics bus, where group voices by order).
propagating the voice-id along with the total number of voices is *currently* 
quite straightforward and consistent (using the `-s` flag, iirc).
any of the solutions  proposed so far do not add any value for that. 


> I'd prefer to leave this one open

but why?

I think the issue itself is niche enough, that nobody would actually spend 
brainpower on it, just because they see that there's an open ticket.

otoh closing it, does not keep anyone interested in dreaming up a simple and 
elegant solution and create a new feature request.

(I'm only saying this because I'm one of the people that are looking quite 
often on the issue tracker, and keeping such "wontfix" issues open just for the 
sake of it, is burning brainpower)

>, but the wrapper solution proposed
> by (??)

hmm. let me check.

mfg.hft.fsl
IOhannes


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

Reply via email to