@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

@porres said:

to never miss a period, but I also think this is a job for a C code.

To atone for my earlier SC jibe, here's a delay-based approach. (Also, indeed you're right -- I hadn't read the thread carefully enough. Dust / Dust2 don't implement exactly "one pulse per regular time interval, randomly placed within each interval.")

velvet-noise-2.pd

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.

It looks to me in the graphs like there is exactly one nonzero sample per phasor~ cycle.

hjh

PS FWIW -- one nice convenience in SC is that non-interpolating DelayN doesn't require the delay time to be rounded

(
a = { |density = 2500|
    // var pulse = Impulse.ar(density);
    // for similarity to Pd graphs, I'll phasor it
    // but the Impulse is sufficient for the subsequent logic
    var phasor = LFSaw.ar(density);
    var pulse = HPZ1.ar(phasor) < 0;
    var delayTime = TRand.ar(0, density.reciprocal - SampleDur.ir, pulse);
    var rand = TRand.ar(-1, 1, pulse).sign;
    [DelayN.ar(rand * pulse, 0.2, delayTime), phasor]
}.plot;
)