@jameslo said:

But what prevents Pd from displaying the inexact result, e.g. in the number box above [expr]? If the goal of patching is to make things more friendly for non-programmers, how is it helpful to hide it?

In fact, when a user types in 0.1 and it displays 0.100001 (I forget how many zeros for single-precision), this is more disturbing to non-programmers.

... because that's exactly what you get when you don't round off the last bit or two for string conversion: a whole lot of 0.n000001 or 0.n999999. SC tried this for awhile, but had to revert to a slightly lower precision for float-to-string because users really hated the more accurate display.

Python can demonstrate with double precision floats -- https://en.wikipedia.org/wiki/Double-precision_floating-point_format says "The 53-bit significand precision gives from 15 to 17 significant decimal digits precision (2−53 ≈ 1.11 × 10−16)" so let's try both:

$ python3
>>> for x in range(1, 10): x = x * 0.1; print(f"{x:.15f}")
... 
0.100000000000000
0.200000000000000
0.300000000000000
0.400000000000000
0.500000000000000
0.600000000000000
0.700000000000000
0.800000000000000
0.900000000000000

>>> for x in range(1, 10): x = x * 0.1; print(f"{x:.17f}")
... 
0.10000000000000001
0.20000000000000001
0.30000000000000004
0.40000000000000002
0.50000000000000000
0.60000000000000009
0.70000000000000007
0.80000000000000004
0.90000000000000002

Increasing the string representation to include more digits makes it necessary to render into the UI the noise inherent in the least significant bit(s). This isn't appealing to everyone.

Since Pd uses single precision, 6 digits is the low end (and exactly the precision Pd displays). If Pd expanded these strings to 8 digits, you would see trailing digits for fractions that seem like they should be simple.

I think it's pretty common practice with floats to calculate with more precision than you're going to display, and round off for UI strings.

hjh

When performing division of rational numbers, the result will be exact if the denominator factors out such that all factors are a power of a factor of the numeric base. We're used to decimal, so those factors are 2 and 5. 20 = 2•2•5 so it's ok; 27 = 3•3•3 so we know this will be a repeating fraction (since 3 is not a factor of 10).

Floating point numbers in computers are base 2, so, for non-repeating division, the denominator must be a power of 2.

First you have [/ 1] -- 1 = 2^0 so, ok.

Then you have [/ 64] -- 64 = 2^6 so, ok.

When you introduce division by 44.1, then the denominator includes two 3s and two 7s (plus 2^-1 and 5^-1). These aren't powers of 2, so the fraction will be infinite, and rounding it off to the available precision is an approximation. Multiplying again doesn't restore the precision.

Like, 2/3 = 0.66666...7. Let's pick an arbitrary precision, say, 4 digits. 2/3 = 0.6667 (or, the floating point way, 6.667•10^(-1)). Now you multiply this back by 3 and you get 2.0001 -- there's your "higher than." This must also get rounded off, but at least it shows that inaccuracy when scaled up can eventually become visible.

The assumption that floating point math is exact is basically a good way to set yourself up for confusion or disappointment. (That is, this isn't Pd's fault -- it's IEEE 754.)

hjh

@willblackhurst said:

in my one I just install pd vanilla and then do sudo apt install gem. and then I dont have to do anything else.

It's true that in most cases this is sufficient. Anybody finding this thread in the future should try installing from packages first.

I found in my case that, inevitably at some point, I will have to install some other media plugins and enable them in Gem. If I don't, certain image or video files will not be accessible in Gem. That's why for the last two or three OS update cycles, I have built from source instead of installing from packages, and I expect to continue doing so.

hjh

OK, I found the problem.

For Gem, it's mandatory to sudo make install. In Ubuntu, by default, this goes into /usr/local/lib/pd/extra. Then the problem is that this location is not added by default into the PD path, so [declare -lib Gem] doesn't know to look there.

I had tried to work around that problem by symlinking the gem repository into my user-level externals directory, but that didn't work because the repository's folder structure doesn't match what is needed to use the external.

So the solution was sudo make install, then add /usr/local/lib/pd/extra to the path.

hjh

After 4 days of software reinstallation, I built Gem from sources, then this:

Also doesn't work with -lib Gem -path Gem either.

I'm... just done troubleshooting.

Help.

hjh

@jameslo said:

But wait! I just checked the harmonics of a full wave rectified {cos~] and all the even FFT terms have positive magnitude, so this post appears to be correct. And now I just reran my first test and set my "top only" slider to exactly 2 and am getting the fundamental + all even harmonics. Why am I getting so tripped up by this?!!!

Hm, yes, the argument about double frequency does make sense. I guess neither of us considered the possibility that the initial test may have been flawed.

What actually were your settings for the two sliders in the first screenshot? I'm curious to try to reproduce it but I can't see what the numbers are.

hjh

@TheBarker

If it's tabwrite~ then you'd have to bang it precisely when it should loop back around to the beginning of the array. That might be doable at 48 kHz because 48000 is divisible by 64. 44.1 kHz is likely to be trickier.

For this usage, I'm a fan of count~ and poke~ in the cyclone library.

hjh

@jameslo said:

I think it's things like this that misled me in the first place

YouTube channel House of El-AI calculates, based on Google's number of daily queries scaled down to an hour and multiplied by a ~9% hallucination rate, that Google's AI overview serves up 57 million wrong answers every hour.

hjh

As you noted, [poly] works in the direction of note number --> channel: you give it a note number; it gives you a voice number, or channel; and then when you tell [poly] that you want to release that note number, it will retrieve the channel number.

The catch for your case seems to be "when a new note comes in to a particular channel" -- which sounds like the voice/channel assignment is happening independently of anything [poly] might do.

Does this accurately describe the messaging?

1. Note on, say, f# above middle C = channel 2, note 66, velocity > 0.
2. New chord overwrites all the strings, including, say g above middle C.
   • g is on the high E string, so f# needs a note off: channel 2, note 66, vel = 0.
   • Then note 67 gets a note-on.

Is that right?

In that case, could you not simply use an array, indexed by channel number? You have a sequential index that's coming in from outside. Arrays operate based on sequential indices. That sounds simpler to me than using a bag.

midi-guitar-string-tracker.pd

If I run the message boxes left to right, it prints:

// for 66 64 2:
0 0 2 (note-off: redundant but not harmful)
66 64 2 (ok)

// for 67 64 2:
66 0 2 (note off for preceding pitch on this string, ok)
67 64 2 (ok)

// for 67 0 2:
67 0 2 (ok)
67 0 2 (redundant but not harmful)

hjh

@xaverius said:

@ddw_music Thank you for your post, but I'm looking for a solution that does not influence the zoom level of other applications.

In Ubuntu, for Qt apps (which is most of them), the way to set zoom per app is to hack the desktop file:

1. App menu.
2. Right-click > Edit app.
3. In "Command," add env QT_SCALE_FACTOR=2 before the command. (Or =1.5, or whatever.)

The problem for your case is that I don't know which graphics toolkit Purr Data is using. If it's Qt, then QT_SCALE_FACTOR in a .desktop file should work. If that doesn't work, then you'd have to find out what is Purr Data's GUI toolkit and find out how to affect application zoom in that framework.

QT_SCALE_FACTOR worked for pretty much every application I use, except Pd vanilla (Tcl/Tk), Audacity 3 (never figured out how to fix that, though Audacity 4 alpha builds are Qt-based and respond to QT_SCALE_FACTOR), and Wine (winecfg exposes a different zoom setting).

hjh