I've written a VST3 plug-in using Camomile+Pd to output groups of control change messages in response to OSC commands. The CC messages are used to turn channels of a Yamaha 01V96i mixer on and off.

On Windows, everything works fine, but on my M2 Mac I'm having strange issues. The plugin receives OSC fine but the MIDI CC it generates is zeroed-out, e.g. when I ask it to send B0 48 7F, the mixer receives B0 00 00. I can run the Pd patch standalone on the Mac and it works fine.

The AU version of my plugin doesn't output MIDI at all and I get an OSC error message in the Camomile console. I tested a different CC generating Pd/Camomile/VST3 plugin on my Mac and its CC messages are also being zeroed out. In contrast, I've written two other plugins that work fine on the Mac: one is a side-chained envelope follower with adjustable release time and the other generates 5 channels of audio in response to OSC messages.

I saw a somewhat old discussion on the Camomile Github site referring to some issues with MIDI CC under VST3 (https://github.com/pierreguillot/Camomile/discussions/260), but I don't recall having issues like this on my old Mac with my CC-generating plugins hosted in REAPER circa late 2020, and I don't see any similar complaints in discussions about PlugData, which I believe uses Camomile under the hood. In case the issue was REAPER, I tried to load the plug-in to Audacity, but Audacity complains that the plugin is incompatible.

I think there's probably a better way to achieve my end goal but wanted to check in with Pd brain trust because I'm sad to think that I've lost this capability. What would you try next?

I'm using REAPER 6.81 as the VST host, Camomile 1.0.7, Pd 0.54.0, and MacOS 12.6.7 on last year's M2 MacBook Pro.

Not sure....
https://github.com/cuinjune/Ofelia/issues/60

You might try with the ofelia test version based on OF 0.11.2 that cuinjune compiled here?

https://github.com/cuinjune/Ofelia/issues/79#issuecomment-1399175597

@alexandros thanks for replying! I am using [table], not [array]. I've experimented with hiding the tables in subpatches to get around the drawing CPU issue, but still had pops when the tables were hidden. This is an interesting question, though, because my CPU usage never really spiked any further than around 10% when playing with this-- are the issues with tables being redrawn a CPU draw issue or is it that the table's data set actually changes more slowly when they are graphically redrawn?

Unfortunately, I have edited the patch fairly intensely to implement my workaround- and the patch was complicated to look at to begin with. I did some testing in a more simple environment, but was still getting this issue. I'll throw together something soon to demonstrate what I'm talking about because I'd really like to understand what's going on.

@Riccardo-V Yes.... your patch is not causing the problem.
There are issues with coreaudio in Ventura 13.0....... https://community.roonlabs.com/t/strange-audio-issues-w-ventura-roon-investigating-known-apple-issues-w-ventura-system-audio/222113/24 .... see posts from Dec 1 onwards.
Try the latest Ventura 13.1 update.
Then reset coreaudio if necessary (probably not).
Or downgrade OSX.... I think you need all data backed up to do that successfully.

Ignore the following if the OSX upgrade/downgrade solves the problem.
I suggest building the Pd app for your OS and system from the source code.... here...... https://puredata.info/downloads/pure-data/releases/0.53-0
I don't use OSX much (still Snow Leopard when needed) but I believe it is a simple procedure.
As far as I know.... unzip the tar.gz file.
Navigate to the folder in a terminal window.
Type "make" and press enter,
It only builds a Pd app tailored to your system..... it doesn't change any other files.
If it doesn't work then at least you will get messages to the terminal telling you why...... something missing or incompatible.
David.

simple_looper1.2.pd

Hi,

I am trying to construct a looper. My goals seem simple but I am having some issues.

I want to record an initial loop into an array, and once that's recorded I don't want the array size to change.
I want to be able to playback my loop at different speeds, plus backwards.

I think all this is working fine in what I have, which I uploaded with this post. I record audio input, and the array is resized to reflect the length of my loop.

When I try and overdub additional audio I am running into issues where the original loop seems to skip around in time. I can't figure this out.

Ultimately I want to be able to playback the loop at various speeds and overdub onto that as well, which is giving my issues too, but I think if I resolve the first issue noted above it might help me resolve this goal as well.

If anyone can take a look at this patch and offer suggestions I would appreciate it.

Thank you.
Nick

@cfry the quality mainly refers to how steep they are. The basic filters are just 1-zero 1-pole, simple recursive digital filters.
these do introduce phase differences in the frequencies but that usually isn't too audible. Other than that they are linear (meaning that the gain and phase difference at a specific frequency doesn't depend on input volume or phase) and time-invariant. so they won't have any other artifacts, unless you get roundoff error issues or something which also aren't audible usually. (however in very edge cases numerical issues can have an effect on the sound)
there was a case of this recently on the mailing lists but I can't find the full achive for some reason. here's part of the thread:
https://www.mail-archive.com/pd-list@lists.iem.at/msg23581.html
here is a description of the issue:

The test-patch is a 0.1 Hz oscillator sourcing a highpass filter
3.order with butterworth characteristic at 20 Hz.

Try this patch with pd-0.52-1-msw-i386 and amd64 aka 32-bit and 64-bit
and older pd versions.
The 32 bit version has 20 dB less noise than the 64 bit version (and
no oscillations).

Double precision filters of iemlib ("hp3_butt_dp~.pd") have less noise
than single precision filters.

IOhannes z. and Chrostof R. figured out, it depends on compiler
options -ffast-math and / or -fassociative-math.

but like I said it's unlikely that's an issue here..

Hey,

I've been struggling with puredata on a raspberry Pi4 all day. After finally managing to install comport, I'm running into an issue outputting to my arduino.
I'm trying to send a 6 figure string to the comport (opened on port 1, serial rate 9600), but I'm getting the error:
"Write failed for 0 bytes, error is 2"
I'm not really sure why this is happening - I ran an identical patch in Max that worked without issue but this doesn't seem to work. I'm assuming that there is an issue with the way the data is formatted but I don't exactly know what the issue is.

Thanks!

@porres said in Contribute to better Pd Documentation:

On the other hand. If you want a new tutorial like the FLOSS one for 'vanilla' as part of its official documentation, then we need to work on it from scratch, and there'll be no need for a FLOSS version that lives in flossmanuals.net! And I think that can easily be included as part of the Pd Vanilla distribution and its online documentation.

So, went to have a look as to what would it take to make the FLOSS tutorials ported to vanilla... and... well, it seems that despite using Extended, some of the examples are pretty much 'vanilla friendly' (no externals). These can be easily ported then...

But where are the authors these days? I know Derek Holzer is one, but he was just recently sayin on the facebook group that the FLOSS manuals is old should be forgotten himself... If we were to update it in the web, who would do it? And could we revise it and change it and take or put stuff?

Well, I'm thinking about copying the basic tutorials here into a new one, fully vanilla, to be downloadable via deken. But... I guess it'll be kinda "based on this", because I have a few issues with some of the things we have here.

For instance, [phasor~] is described as an osccllator, and it is not one in the sense you can plug it in and listen to it as it has a DC Offset. I will suggest that we even change the description in the help object from 'sawtooth' generator to 'phase ramp' generator. Oscillators need to go from -1 to 1. The square oscillator there is also a pulse train instead. And these are not band limited oscillators (so pretty bad and aliased ones) and we should say that...

Also, in ampplitude modulation, I don;t think it's a good classical example to modulate it to a phasor~ signal, an [osc~] should be much better. And the 'tremolo' effect should also have a 'depth' parameter so it can be called an actual tremolo. A tremolo is not just amplitude modulation with a low frequency.

So if I were to design a new and quick, simple, new tutorial for newcomers, I know I'd change a lot of things... so the problem I have with it is not that it's just old and outdated, but also with the content, which I think can be greatly improved.

I created a new issue on github https://github.com/pure-data/pure-data/issues/1331#issuecomment-850893517

@whale-av Aha, thanks! I think I'm moving forward a bit here! But also a bit backwards.

So, I got out of the "last pitch" issue, that's great. Here is what I achieved so far: granular_20.zip. I'm throwing in one of the samples I'm using to demonstrate why I'm going backwards.

First, though, I get clicking between notes when the [legato-mrn] patch does its job (it's more noticeable with quieter samples and I'm sure it also happens with staccato notes but I haven't been able to hear it. Anyway, I figured I'd put another [vline~] right after the grainSpeed bit but I'm getting some horrible zipping noise (which I suspect is just a slower version of the clicks).

Second issue, higher notes start later in the sample, so basically the higher you go, the closer to the end of the sample you start playing from. I think this is related to the way I'm modifying the output of the grainData [vline~]. I'll play around with it a bit more but if anyone can spot an obvious solution, I'll be forever grateful at this point

(no pressure, but I'm hoping to use this one in a video that should be out in about 48 hours, so… and I'll also try to make this polyphonic, by cloning the granular patch, let's hope I don't kill my PD!)

EDIT: Ok, scratch the second issue, I had a day-long brain freeze that thawed only now. The first issue persists but now that I have it running polyphonically it's not even that bad.

I'm working on a building a parametric EQ in Pd, and was following the model in this post, which at first appears to work really well using para_bp2~ from iemlib.

However, what I've noticed is that whenever the center frequency of a filter is set relatively low and the q approaches an octave bandwidth or so, I'm getting a lot of extraneous high frequency noise even with a gain of 0 whenever a low frequency tone is sent in to the filter. So, everything sounds well until you send a sine sweep through it and you'll notice a lot of noise when the tone is below 40 Hz or so, but again only when the center frequency of the filter is set relatively low as well.

Here is an example with very common values found on the bottom filter of a 10-band graphic EQ (31Hz, Q of 1.41), and you can hear the issue. This same issue seems to persist when using coefficients for biquad~ as well although I haven't tried that exensively.

para_bp2~issue.pd

I thought it might be aliasing caused by some ultrasonics the filter is producing for some reason, but oversampling and filtering doesn't seem to change matters much.

Anyone have any thoughts on this? Thanks for your help!