FYI, BH
- *"pd -help" produces no output, version 0.51-4 / Win7 #1280*
https://github.com/pure-data/pure-data/issues/1280
- *tabwrite should act sensibly upon out of bound address #1281*
https://github.com/pure-data/pure-data/issues/1281
- *Feature Request: allow a [clone] instance to know the total number of
instances #1279* https://github.com/pure-data/pure-data/issues/1279
-- William Huston: WilliamAHuston@gmail.com Binghamton NY
*Public Service Mapping / Videography / Research / Education / Safety Advocacy* Blog http://WilliamAHuston.blogspot.com -- Facebook http://facebook.com/billhuston -- Twitter http://twitter.com/WilliamAHuston-- Youtube https://www.youtube.com/channel/UCGijK1amWOLglT3YeTyEBNQ?sub_congfirmation=1
- -- Podcast Blog https://billhustonpodcast.blogspot.com/*
*Document collections*: VirtualPipelines http://TinyURL.com/VirtualPipelines -- BHDCSDimockArchive http://bit.ly/BHDCSDimockArchive *Please support my work! -- *TinyURL.com/DonateToBillHuston
On 3/5/21 6:29 AM, William Huston wrote:
FYI, BH
- *"pd -help" produces no output, version 0.51-4 / Win7 #1280* https://github.com/pure-data/pure-data/issues/1280
this issue has been resolved and closed.
it's a limitation of Windows' cmd.exe .
if you want to change it, i suggest filing a feature-request/bug-report with microsoft :-)
- *tabwrite should act sensibly upon out of bound address #1281* https://github.com/pure-data/pure-data/issues/1281
as explained in the issue, this is by design. if you hate it, just use [moses] to filter out the out-of-bound indices.
- *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.
[clone -n foo 20] takes the same number of chars as [clone foo 20 20] and needs more brain power to parse ("what was that '-n' flag for again?"). the other solutions require much extra work both for the implementation of the feature and for using it, making it more likely to introduce bugs.
so i don't see a point.
gfdr,mas IOhannes
On Fri, Mar 5, 2021 at 10:06 AM IOhannes m zmoelnig zmoelnig@iem.at wrote:
- *tabwrite should act sensibly upon out of bound address #1281* https://github.com/pure-data/pure-data/issues/1281as explained in the issue, this is by design. if you hate it, just use [moses] to filter out the out-of-bound indices.
It seems quite unexpected behavior, but yes I can do range checking. And agree w/Alex this behavior should be documented.
- *Feature Request: allow a [clone] instance to know the totalnumber of
instances #1279* https://github.com/pure-data/pure-data/issues/1279i 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.
[clone -n foo 20] takes the same number of chars as [clone foo 20 20] and needs more brain power to parse ("what was that '-n' flag for again?"). the other solutions require much extra work both for the implementation of the feature and for using it, making it more likely to introduce bugs.
Well, I understand. But maybe there is a simple solution no one has dreamed up. I'd prefer to leave this one open, but the wrapper solution proposed by (??) seems like that may work for my purposes.
BH
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@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 totalnumber of
instances #1279* https://github.com/pure-data/pure-data/issues/1279i 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
On Fri, 2021-03-05 at 21:42 +0100, IOhannes m zmölnig wrote:
Am 5. März 2021 20:35:50 MEZ schrieb William Huston < williamahuston@gmail.com>:
https://github.com/pure-data/pure-data/issues/1279Well, 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)
Just for the sake of having more opinions, I chime in here. I tend to oppose feature additions that cover some (to me at least) obscure/very specific use case, especially if they bring nothing to the table that couldn't be covered by obvious means. I don't see why the number of total clones should be treated differently than any other argument that someone might come up with.
Roman
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Roman Haefeli -
William Huston