Right -- the OP actually mentions both types of blurring: blurring the contents of each frame individually (feathering edges), or blurring from one frame to the next (trails).

[pix_blur] does motion blurring but AFAICS it does not do image blurring.

[pix_convolve] does image blurring, but it's probably slow for the large kernels that would be required for extreme blurring effects.

I needed an extreme image blur (soft-edge alpha masking) so I looked to see if frei0r had an appropriate plugin, and it did

AFAICS Gem does not have a built-in IIR image blur object.

hjh

Pushing the boundaries of necrobumping a thread (19 years!)...

I just needed a more extreme blur than pix_convolve can do.

For future readers: pix_frei0r with the stock IIRblur plugin worked great, a trouble-free drop-in.

hjh

@FFW said:

For fun this is the cross product

Huh -- the visual is actually kinda comprehensible

Eventually I realized that my specific case can be done more easily with Cartesian coordinates, so I'm just keeping them in that space. This cross product is good for future reference

hjh

@willblackhurst said:

its always half at first. its for mesuring distance from the middle. like a radius.

Thanks -- I still don't get it. Maybe I'll have to file a bug report and ask the devs.

I also find that as I increase the grid resolution, the drawn shape grows -- a 5x5 grid with points at -3, -1.5, 0, 1.5, 3 draws half size, but a 6x6 grid draws slightly larger.

That's weird.

hjh

@jameslo said:

@ddw_music Is this what you're looking for?

Indeed -- thanks. Wouldn't have chanced across that.

Though, in (3.0 / 250), Pd didn't truncate the 3.0 either.

Thanks --
hjh

I'm stumped. I'm generating control points between -3 and +3 (z = 0), and it's drawing -1.5 to +1.5. The white square is -3 to +3. The green circles show where -1.5 and +1.5 are.

Anyone know why?

why-is-it-half-size.pd

(I will be distorting the grid later, so the loop-generation of a control point grid is necessary.)

hjh

Is this documented? Surprised me rather a lot.

"You've got... integer division" is a bit too much like Max for my taste...

hjh

Pondering a thingy that would depend on adding/multiplying vectors (as in an angle and magnitude) -- perturbing points in a grid. Has anyone already built abstractions for the basic ops? Would save me some time.

EDIT: Turns out what I'm doing isn't so complicated, so, a library is not really necessary.

hjh

Is there any way, in Gem, to draw arbitrary curves ([curve3d], [surface3d]) with color gradients?

I guess, worst-case bad workaround would be to algorithmically generate a pix_texture (but Gem's support for this isn't marvelous either).

Or write a shader (yikes, that's gonna eat up hours that I don't have).

Would be nice if you could write per-control-point colors into the curve.

hjh

@dlask IMO:

Normalize your knob range to be 0-1 (or -1 to 1).

Then you can express any range you want, in terms of a range and an offset: value = range * knob + offset.

The radio button would change the range and offset.

"Sample and hold," I'm not sure now exactly what behavior you want. An easy behavior would be: use the radio button to change only the cold inlets of the * and + operators. Then, changing the radio button would not update the output value. The knob would be connected to the * operator's hot inlet, so that touching the knob would produce output.

hjh

@Luizagimenez said:

I have a work assigned to translate some Graphs from UV lightning on molecules to an array in Pure Data. Im trying to find a way to get the Quadratic Equations that have complex numbers to show on a somewhat precise array or graph, so i can use these numbers for frequencies, to create a movable bar to select a pixel of the graphic.

Pd can express any math formula, but it's more cumbersome for complicated math expressions than a text-based language. [expr] helps somewhat, though. A real-number (no complex) quadratic would look like this:

If a quadratic is ax2 + bx + c, and you need complex numbers, is it that a, b and c can be complex, or only x? Your graph suggests a real-number domain, in which case complex a, b, c would be the sum of 2 quadratics, one multiplied by i. So, the above patch, but duplicated, to give you a real and an imaginary result.

If x can be complex too, then it's more involved than that.

hjh

@ChicoVaca Yes -- whale-av is right about the problem. It's possible to collect, but the only way to know that the chord is over is to wait a short time.

This handles note-on. It will not remove notes from the chord upon note-off (which is easy in a programming language but rather laborious in patching -- not impossible, just cumbersome, and I'm short on time).

Every time a note is appended to the list, it also triggers a 50 ms delay. [delay] only fires the last one -- so if you play C 60 and E 64 quickly, the [delay] will fire only 50 ms after the second note, causing the list to be output.

hjh

@vk092 said:

@dreamer Information regrading how they are used in Pd is what I am concentrating on currently , but still it covers a lot of thing . I'd appreciate any suggestions on what specific aspects I should include in the PR for the community.

I guess, if anything, I'd suggest to keep it minimal. The main things users will care about are:

• How to choose a specific audio device
• How to set sample rate, bit depth etc.

Detailed ALSA configuration instructions... I wouldn't see much benefit in duplicating existing online materials.

Also... Pipewire is coming fast (Ubuntu Studio 24.04 ships with pipewire as the default audio system, no longer JACK). So, if you're going to write up something about audio frameworks, it would be great to handle this in advance. My understanding is that it's supposed to be as simple as doing pw-jack pd-gui instead of just pd-gui but when is it ever that simple...? (Haven't tried pipewire myself yet, maybe it is that simple.)

hjh

@hmp Should "text tolist 1" be an object box? Currently it's a message box, so it isn't doing any actual operation.

hjh

@Dizzy-Dizzy said:

To verify that I have the latest I used the "sudo apt-get upgrade puredata" command in the terminal and got the message "puredata is already the newest version (0.51.4-1)"

That's referring to the latest version in your Linux distro's package manager. Package managers aren't guaranteed to have the latest versions of everything. So there does exist Pd 0.55, but the package manager doesn't have it.

Agreed that Pd is one of the easiest packages to build. Readme instructions are straightforward.

hjh

@JOHN_SIX said:

Does Ableton Link provide the sync of the song position?

No. Ableton documentation explains it better than I could.

https://ableton.github.io/link/

Link Concepts
Link is different from other approaches to synchronizing electronic instruments that you may be familiar with. It is not designed to orchestrate multiple instruments so that they play together in lock-step along a shared timeline. In fact, Link-enabled apps each have their own independent timelines. The Link library maintains a temporal relationship between these independent timelines that provides the experience of playing in time without the timelines being identical.
Playing “in time” is an intentionally vague term that might have different meanings for different musical contexts and different applications. As a developer, you must decide the most natural way to map your application’s musical concepts onto Link’s synchronization model. For this reason, it’s important to gain an intuitive understanding of how Link synchronizes tempo, beat, and phase. Version 3 of Link makes it possible to share start and stop commands.

Your other question:

Hopefully, what is the proper way to let pd and logic know the same song position?

Perhaps use plugdata as a VST in Logic, to send OSC messages containing song position to your standalone Pd.

hjh

@jameslo said:

Hmm, but hold on a second. @ddw_music - if I somehow managed to save once in QLab (see the first paragraph of my original post), then doesn't that mean the huge plug-in state size hypothesis can't be true?

Ah, I hadn't spotted that. Indeed, if it can work under some unknown circumstances, then that would rule out my guess.

FWIW I can't get Audacity to use plugdata-fx -- I've enabled it in the plug-in manager, but it still doesn't show up in real-time effects for a track.

hjh

@dreamer said:

Cardinal's AU implementation is completely independent of plugdata. Of course testing any other AU is useful to test, but ideally the same plugin framework is used to pinpoint where the issue is (with the framework or with the plugin).

I was suggesting to test whether the host would fail or succeed with a different plugin that is also likely to generate very large blobs. That's not a useless thing to test. You're correct that a result of "Cardinal OK, plugdata not OK" wouldn't be conclusive -- but if they both fail, it would point to the host.

hjh

@jameslo said:

For instance, I just learned that the Mac version of REAPER runs AUs, so I tested in REAPER and there were no issues. So to me it's a tossup whether I should report it to the QLab group or the plugdata issue list.

Reaper gives some insight, because its file format is text.

I created a Reaper project with a single track, and two effects: plugdata and ReaEQ. I saved two versions of this product, with slightly different plugdata patch contents. Then I opened both files in Emacs and did ediff-buffers on them.

The main difference is that a whole long string of binary-encoded stuff (not human readable) changed... plugdata appears as:

      <VST "VST3i: plugdata (plugdata) (32ch)" plugdata.vst3 0 "" 1821045374{ABCDEF019182FAEB506C44745064496E} ""

... a ton of encoded stuff... like 560 lines of it...

>

Since the encoded stuff changed, it means that plugdata renders the patch into the VST preset data. (Good point about this is that a DAW project using plugdata doesn't have to ship with a pd patch file.)

I guess then, for whatever reason, QLab and Audacity are not handling this, while Reaper does. One plausible guess might be that QLab and Audacity have a limit on the size of a plug-in's settings. Plugdata really spits out a lot. The ReaEQ settings are fully represented in 7-8 lines; plugdata, for a minimally simple adc~ --> dac~ patch, needs over 550. It wouldn't surprise me if some audio software assumed "nobody's going to make a plug-in that big."

Hm, here's a thought -- Cardinal synth (VCV Rack fork) should also save patches into plug-in settings, which could get arbitrarily large. Maybe try that in QLab, for differential testing. If they both fail, you would have more ammunition to go back to QLab. If QLab handles a large Cardinal patch but fails on plugdata, that seems more like a plugdata bug.

Audacity is open-source, so it may be possible to find a limit in the code.

Could be something else too (maybe plugdata's settings use some data types that certain software isn't prepared for). Or it could be too many parameters. Plugdata publishes 512 free parameters, plus 128*16 MIDI CCs, plus a few other odds and ends. Pretty sure even Vital isn't that big.

(I'm also certain that someone on the QLab group is going to respond "plugWHAT?!!!" )

Yeah, tech support finger-pointing. When I worked in tech support, I saw that a lot of questions that really should have gone to partner companies ended up coming to us, because we were the smaller kid on the playground.

hjh

@ddw_music said:

Uses else's del~ because delread~ requires a message-based delay time, which can't update fast enough, and delread4~ interpolates, which smears the impulses. With del~, I could at least round the delay time to an integer number of samples, and AFAICS it then doesn't interpolate.

Actually delread4~ doesn't smear if the delay is always an integer number of samples (which makes sense from the cubic interpolation formula -- if the fractional part of the index is 0, then you just get the sample value at the integer index).

It's easier to ensure an integer-sample delay time using else/del~'s -samps flag

I've definitely not dug deeply enough into ELSE -- so many things that are a PITA in vanilla become straightforward. (I'd have complained a lot less four-five years ago if I had known about this library from the beginning!)

hjh