[loadbang] sending two bangs
I have a student patch with a subpatch inside. The subpatch contains
[loadbang] --> "read" --> [buffer~ src] right inlet --> [info~ src]
... and the file duration outlet is going to the subpatch outlet, and from there, the outlet goes to two other places in the patch window.
The loadbang fires once, and after selecting the file, it... fires again. Every time.
But only for this patch. I have tried to reproduce it in a brand-new patch, and nothing bad happens.
The upshot is that one or the other file-reads ends up with only one channel, even though the file is stereo. So the subsequent stereo [groove~] plays only the left channel.
I just spent quite some time trying to figure this out, so that I could explain to the student how to fix it, but I have found no solution other than to rebuild the patch completely from scratch.
Has anyone else seen this? How is it possible for [loadbang] to be hyperactive?
(For more amusement, "paste from clipboard" ends up firing the [loadbang] three times!)
hjh
"I have tried to reproduce it in a brand-new patch, and nothing bad happens."
Ah... Turns out this is incorrect. If I replicate the same structure, with loadbang in a subpatch triggering a file-read dialog, then it does happen twice.
So here is a minimal reproducer.
I suppose the workaround would be to tell my students to never, ever put [loadbang] in a subpatch -- probably the safest practice would be one [loadbang] only per patch, and [send] where you need it. This may not be possible for abstractions, though, and shouldn't be necessary at all.
hjh
This is most certainly a bug related to the fact that the loadbang triggers a dialog window to select a folder/file.
I does the same with just a [loadbang] --> [opendialog] in a subpatcher.
Instead of "never use loadbangs in subpatchers" (which has never been a timing issue for me), the workaround would rather be: "never connect a loadbang to something that opens a dialog in a subpatcher".
Another workaround is to delay the loadbang:
EDIT:
Tried on Windows 10, Max 8.5.6, with any combination of DSP and overdrive on/off.
cannot reproduce it.
the minimal patch from post 2 does what it should: it loads an audio file once and prints once to the console.
loadbang perfectly works in subpatches, bpacthers, poly or pfft. you only have to be aware that loading a file from disk can break order. but this is not the case here.
it could be the case in such situations:
it currently works for me even like that, but i would not do that in a bigger project with hundred loadbangs or multiple files involved.
OK, so we got two votes for "see the problem" and one vote for "don't see it."
"never connect a loadbang to something that opens a dialog in a subpatcher" -- this advice, I'll pass along to the students, along with the [delay] suggestion. (But I still wonder why this is even a thing...? Pd [loadbang] doesn't have this problem.)
"loadbang perfectly works in subpatches, bpacthers, poly or pfft" -- sure, when not directly triggering user interaction.
I'm a bit puzzled by an inconsistency. In some of the affected student patches, the repeated file-load caused the buffer~ to get stuck at one channel, even though the file is stereo. But my test patch could never reproduce that behavior -- I did see the double dialog, but it always loaded stereo. These kinds of things... I find it difficult to let them go. I should let it go, because I have other work to do, but... "read" --> buffer~ when selecting/reselecting the same file should be deterministic, but it wasn't deterministic last night when I was grading homework. Non-determinacy in deterministic operations drives me batty.
hjh
note that overdrive on/off, DSP on/off, operating system and max version all could be factors which influence the behaviour.
the "solution" is to use a better alternative: [buffer~ filename] and [sfinfo~ filename]. inner to outer, left to right, threadsafe, no dependencies between the parts.
but such an alternative "working solution" does not include any advice one could give to the students nor does it explain what you see.
Thanks Roman. I edited my previous post to provide more info about the context.
> the "solution" is to use a better alternative: [buffer~ filename] and [sfinfo~ filename]
OK, fair 'nuff, will advise them this (or even give them an abstraction... it's approaching a certain threshold of fiddliness).
I was influenced here by Pd, where [soundfiler] reports file stats after load, and SuperCollider, where file stats are available in the Buffer object in the 'action' callback which fires after load. Different software, different methodology, OK, though here's a case of multiple approaches but only one is reliable (also a problem in some areas of SC, fwiw).
hjh