[PD] 2 bugs and a feature request, FYI

IOhannes m zmölnig zmoelnig at iem.at
Fri Mar 5 21:42:26 CET 2021



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 <williamahuston at 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




More information about the Pd-list mailing list