FWIW, a few days ago I was showing [vstplugin~] in a class, and it hung, and I could get control back only by rebooting. This was on Mac. Cmd-Q didn't do anything, and right-clicking on the Pd icon in the dock did not reveal a force-quit option. I haven't typically had that problem in Linux.

It doesn't normally happen for me in Mac, so my observation is maybe not the same as in the original post.

Come to think of it -- @ultraman, are there any particular objects that provoke this kind of hang? In my case it was very clearly an errant instance of a complex external (and an external which invokes third-party executables), but I've never seen this with plain vanilla objects.

hjh

There is actually a difference between SC's 'degree' and mscale.

[mscale] is more like an analog modular quantizer -- put in chromatic data, and it gets rounded off to the scale.

What I was looking for is a diatonic data representation: scale degrees 0 1 2 3 4 5 6 7 map onto major scale chromatic semitones 0 2 4 5 7 9 11 12. That way, a root position triad is always note, note+2, note+4 and this becomes major, minor or diminished at the time of mapping.

Diatonic transposition is really hard when the data are chromatic. It's really easy when the data are diatonic.

degreeToKey was as easy as I expected. keyToDegree isn't critical for me at the moment, so I'll deal with that later.

hjh

degree2key.pd

@seb-harmonik.ar

To me it makes sense that windows has appreciably different standard paths than linux.

Sure. And I can see the logic of installing executables into locations that are ordinarily hidden -- but, I'm guessing that the reason why the default external install directory is in Documents for Mac and Windows is that the user may need to manipulate the contents of this location, and that gets harder when the OS's file browser goes out of its way to make it hard to find them. In Mac (I think), Library used to be visible, but then Apple decided there was more money to be made by marketing lifestyle devices to ordinary consumers rather than supporting media professionals, so... hide it. In Windows, AppData is likewise hidden.

I assume you can navigate to the externals directory in the help browser in windows and Gem and Zexy show up there though..

Ah, OK, I overlooked that -- in hindsight, I probably shouldn't have overlooked it, but... anyway, yes, I checked the Windows machine too, and there is an "externals/" entry and all the good stuff is under there.

So that is... actually the solution!

Thread resolved. Thanks!

hjh

As a further test -- I hacked ./tcl/helpbrowser.tcl to print to stdout some progress messages while building the help browser directory list. (Doing this in Linux -- I haven't set up the Windows machine to build Pd from source.)

To my surprise, I found that the Externals Install Directory is part of $::sys_staticpath (in Linux).

Each entry in $::sys_staticpath is globbed for any subdirectories -- so this is how it's finding Gem, cyclone, zexy etc.

staticpath add search /home/dlm/pd-externals/Gem
staticpath add search /home/dlm/pd-externals/freeverb~
staticpath add search /home/dlm/pd-externals/zexy
... etc.

A little bit later, it checks $::sys_searchpath -- this comes from preferences. These entries are not globbed for subdirectories.

searchpath add search /home/dlm/pd-externals

(Above is the only entry coming from Preferences > Path.)

So one possible difference is that the "static path" includes my external location in Linux (that isn't speculation -- the stdout listing proves it), while it probably doesn't in Windows.

OK, then, let's grep staticpath... this leads to s_path.c, which says (in an ifdef for Linux):

sys_expandpath("~/pd-externals", pathbuf, MAXPDSTRING);
STUFF->st_staticpath = namelist_append(STUFF->st_staticpath, pathbuf, 0);

So user-home/pd-externals is a special, hardcoded location for Linux, which I happen to be using for my externals.

Looking a bit further down, hardcoded locations in Windows are AppData/Pd and something about common-program-files/Pd -- but the Pd GUI recommends Documents/Pd/externals as the installation directory. (And Mac will have a similar problem, because the hardcoded locations include ~/Library/Pd but again not Documents/Pd/externals.)

I'm satisfied that this explains the difference in behavior between the two environments. But it leaves a bit of an impression that this hasn't been completely thought through. If there are magic locations for help browser search, ideally this would be coordinated with recommended installation directories, but they aren't.

hjh

@whale-av

Are you looking at the same directory?

Do you mean the Linux machine or the Windows machine?

If the Linux machine -- I'm aware of the ~/.pdsettings file -- its contents match the display (nloadlib = 0 meaning no startup libs, npath = 1 and only a path1). There is no registry in Linux, so that comment isn't relevant to the Linux machine.

On the Windows machine, there isn't any other Pd library folder, and I keep only one version of Pd. But I don't think this question quite makes sense -- if there are multiple versions of Pd sharing the same settings, how would the two versions behave differently? Wouldn't I see the same behavior in multiple versions?

FWIW, I checked the registry and, just like the Linux machine, nloadlib is 0 and npath is 1. So Pd on the Windows machine should not be loading any startup libraries (and indeed, I don't see any output from Gem or zexy), and there should be only one search path (which I can confirm by creating an object in a subfolder, and it isn't found).

"This Pc" is pretty clearly just a display convention in the Windows Explorer, and has nothing to do with the actual file system structure.

hjh

OK, thanks.

hjh

It takes 10 minutes to boot that machine, but OK, here are the screenshots.

On my Linux machine, I have this. (Startup preferences are empty.) E.g. Gem is not listed under either "path" or "startup," but it does appear in the help browser.

On my Windows machine -- observe -- "Externals Install Directory" is the same as the single search path (specific path is not the same as in Linux, but the configurations are functionally identical), and at right, you can see that under Documents/Pd/externals, Gem and a couple of others live here.

But the help browser omits Gem and zexy.

Because from your description it seems most likely that it was added to the paths on Linux but not Windows.

No, that isn't it. Functionally equivalent configurations, different behavior = platform-specific bug (IMO).

hjh

Before I roll up my sleeves and build something that might already exist --

Is there already an abstraction somewhere for diatonic scale degree mapping? cf. http://doc.sccode.org/Classes/SimpleNumber.html#-degreeToKey

degreeToKey is relatively easy (basically wrapped indexing into an array, with octave displacement).

The inverse operation keyToDegree is a little trickier -- if somebody has already done it, I would rather not reinvent the wheel.

Thanks,
hjh

@ingox "Yes, this is a major downside of the declare method. Help files will only show up with the old path method"

Or maybe just log a bug report, then.

Curiously, though, in Linux it does show help files in subfolders. So I suspect that maybe the subfolder search is being done incorrectly in Windows (which would make sense, since Windows decided back in the day to be contrary and use \ as the path separator, creating headaches for decades thereafter -- if Pd is searching for help files on the assumption that / separates folder names in paths, that would explain what I'm seeing).

hjh

@beep.beep "I had the same problem years ago when I added an older version of freeverb to my patch, namely that this denormals bug would cause the CPU to grow out of control if the input to [freeverb~] fell silent. The readme in my current version says 'Recent changes (1.2.2): fixed the NaN/denormal check'"...

That's exactly what I suspected, and tested this morning, but I couldn't reproduce denormal performance problems. So I think it's really fixed.

Definitely worth updating, then. If the older version is not flushing denormal floats to zero, that would entirely account for out-of-control CPU usage.

hjh