@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

I've long since lost the reference, but I learned a neat trick from a video once: if you need a circular buffer for a grain delay, use delwrite~ and delread4~.

You can't get a smooth circular buffer by banging control messages into a line -- well, maybe you could, but it would be delicate. You might see other tutorials that suggest running a phasor~ at samplerate / arraysize Hz and multiplying the phasor by the array size, but floating point rounding error means you have no guarantee of touching every sample (and you still need a poke~ external that way, IIRC).

But a delay line gives you the circular buffer for free. It isn't the first thing you'd think of but it is so much easier.

Pitch shifting can be done by modulating the delay time. If you're playing a 100 ms grain, run a line~ with "100, 0 100" as the delread4~ delay time and you'll get 2x speed, 2x frequencies.

hjh

@xaverius said:

Is there a possibility to set a default zoom level for all windows that are opened? There is nothing in the preferences, but maybe a kind of config file entry?

I've just been round the bend with app zoom levels (xubuntu with Ubuntu Studio packages). XFCE does have a global zoom setting but most apps ignore it so I had to set environment variables. One was QT_SCALE_FACTOR; this worked for most of them. A bit of a saga, but worth it.

I don't know which graphics toolkit Purr Data uses, so a Qt variable might not make a difference.

At least my experience might comfort you that you haven't missed something obvious; it's rather that HiDPI support in Linux is not quite ripe yet.

hjh