So I was going to replace type punning flush-to-zero in bsaylor/svf~ with something else, but first wanted to check how it behaves in Pd-E 0.42 and in latest 0.43 autobuild. As it happens, it gives no output sound at all in latest autobuild. It's compiled with fno-strict-aliasing. By coincidence it occurred to me to check cyclone /svf~. No sound either! In dutch we say 'alsof de duvel ermee speelt'. The issues may be unrelated. cyclone/svf~ has four inlets and one outlet now, while it used to have three inlets and four outlets.
This is with Pd-0.43.4-extended-20121221.app for OSX 10.5 i386 (but very unlikely that cyclone/svf~ has different number of outlets on other platforms). Weather forecasts are unfavorable for this weekend and I may spend some time on these issues.
Katja
Have to eat my words. Nothing wrong with cyclone/svf~, it's just that Pd-E would erroneously load the help patch of bsaylor/svf~ after a click on cyclone/svf~ in the help browser (after bsaylor/svf~ was loaded once).
So the problem is with bsaylor/svf~, that's probably an easy fix. What about the help browser? It loads the wrong help patch because of a namespace clash. Will Pd never reload an external with same symbol but different path?
Katja
On Fri, Dec 21, 2012 at 10:30 PM, katja katjavetter@gmail.com wrote:
So I was going to replace type punning flush-to-zero in bsaylor/svf~ with something else, but first wanted to check how it behaves in Pd-E 0.42 and in latest 0.43 autobuild. As it happens, it gives no output sound at all in latest autobuild. It's compiled with fno-strict-aliasing. By coincidence it occurred to me to check cyclone /svf~. No sound either! In dutch we say 'alsof de duvel ermee speelt'. The issues may be unrelated. cyclone/svf~ has four inlets and one outlet now, while it used to have three inlets and four outlets.
This is with Pd-0.43.4-extended-20121221.app for OSX 10.5 i386 (but very unlikely that cyclone/svf~ has different number of outlets on other platforms). Weather forecasts are unfavorable for this weekend and I may spend some time on these issues.
Katja
Turns out adding -fno-strict-aliasing after -ftree-vectorize does nothing, so the no sound part is indeed caused by bsaylor/svf~ being compiled with -fstrict-aliasing.
I get the right help patch in all cases I could think of using Pd-extended 0.43.4 2012-12-19, see attached:
.hc
On Dec 21, 2012, at 4:53 PM, katja wrote:
Have to eat my words. Nothing wrong with cyclone/svf~, it's just that Pd-E would erroneously load the help patch of bsaylor/svf~ after a click on cyclone/svf~ in the help browser (after bsaylor/svf~ was loaded once).
So the problem is with bsaylor/svf~, that's probably an easy fix. What about the help browser? It loads the wrong help patch because of a namespace clash. Will Pd never reload an external with same symbol but different path?
Katja
On Fri, Dec 21, 2012 at 10:30 PM, katja katjavetter@gmail.com wrote:
So I was going to replace type punning flush-to-zero in bsaylor/svf~ with something else, but first wanted to check how it behaves in Pd-E 0.42 and in latest 0.43 autobuild. As it happens, it gives no output sound at all in latest autobuild. It's compiled with fno-strict-aliasing. By coincidence it occurred to me to check cyclone /svf~. No sound either! In dutch we say 'alsof de duvel ermee speelt'. The issues may be unrelated. cyclone/svf~ has four inlets and one outlet now, while it used to have three inlets and four outlets.
This is with Pd-0.43.4-extended-20121221.app for OSX 10.5 i386 (but very unlikely that cyclone/svf~ has different number of outlets on other platforms). Weather forecasts are unfavorable for this weekend and I may spend some time on these issues.
Katja
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Fri, Dec 21, 2012 at 11:07 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I get the right help patch in all cases I could think of using Pd-extended 0.43.4 2012-12-19, see attached:
Ah I see. I also get the right help patch but with the wrong svf~! Try this: start Pd, first load bsaylor/svf~, then the help patch from cyclone/svf~. You get cyclone's patch but with bsaylors' svf~ (with four inlets and one outlet), no? And the other way round is also true. This is what confused me. But probably this makes sense (though it is not the desired behaviour in all cases): once a symbol is loaded, Pd will not reload it. Pd does not remember the path where a symbol was loaded from, or does it?
Katja
On Dec 21, 2012, at 6:09 PM, katja wrote:
On Fri, Dec 21, 2012 at 11:07 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I get the right help patch in all cases I could think of using Pd-extended 0.43.4 2012-12-19, see attached:
Ah I see. I also get the right help patch but with the wrong svf~! Try this: start Pd, first load bsaylor/svf~, then the help patch from cyclone/svf~. You get cyclone's patch but with bsaylors' svf~ (with four inlets and one outlet), no? And the other way round is also true. This is what confused me. But probably this makes sense (though it is not the desired behaviour in all cases): once a symbol is loaded, Pd will not reload it. Pd does not remember the path where a symbol was loaded from, or does it?
Yeah, this is a bummer. This the big problem with the namespaces as they are now. If a binary object is loaded like [bsaylor/svf~], still claims the [svf~] name. So in this case, [cyclone/svf~] comes first in the search path, so its normally [svf~]. But if [svf~] or [cyclone/svf~] has never been loaded, then the 'svf~' name is unclaimed. Then when [bsaylor/svf~] is loaded, it claims [svf~]. Sad but true.
So the help patch you get is a good clue to which one actually claimed [svf~].
.hc
On Fri, Dec 21, 2012 at 11:07 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Turns out adding -fno-strict-aliasing after -ftree-vectorize does nothing, so the no sound part is indeed caused by bsaylor/svf~ being compiled with -fstrict-aliasing.
Indeed bsaylor/svf~ works again when type punning is removed (used PD_BIGORSMALL instead to avoid subnormals). Patch file submitted to patch tracker. Who is maintaining Ben Saylor's stuff by the way? His name is on this maintainer's list:
http://puredata.info/dev/roles
but the list is very much outdated. There is even the name of someone who isn't alive anymore. I'm sure I've seen another maintainer's list somewhere, but can't find it now.
Katja
On Dec 22, 2012, at 9:17 AM, katja wrote:
On Fri, Dec 21, 2012 at 11:07 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Turns out adding -fno-strict-aliasing after -ftree-vectorize does nothing, so the no sound part is indeed caused by bsaylor/svf~ being compiled with -fstrict-aliasing.
Indeed bsaylor/svf~ works again when type punning is removed (used PD_BIGORSMALL instead to avoid subnormals). Patch file submitted to patch tracker. Who is maintaining Ben Saylor's stuff by the way? His name is on this maintainer's list:
http://puredata.info/dev/roles
but the list is very much outdated. There is even the name of someone who isn't alive anymore. I'm sure I've seen another maintainer's list somewhere, but can't find it now.
Excellent, that's the last one! I committed a fix for iem_spec2/spec_sqrt~ to the pd-extended branch. I recently found out that there are two levels of that "type punning" warning: 1) this will definitely cause problems, and 2) this might cause problems. Unfortunately, they are both the same warning message. But currently, the level 2 warnings are only turned on for the Mac OS X builds, so that's the difference why there are more warnings on the Mac builds than the rest.
I usually look at 'svn log' to see who has been committing recently. I don't think Ben Saylor's touched that in a good long time, but its been maintained by various people, including me. You should just commit directly.
.hc
-
Hans-Christoph Steiner -
katja