@gentleclockdivider Ceammc is vanilla..... with some add-ons that seem not to load (according to your console).
Your Ceammc distribution must be based on a version of Pd prior to 0.53.
Prior to that version you had to define the length of the list to get..... so... [get $1 1( ... instead of... [get $1( ..... will work.

Please carefully check the help file for objects before posting technical issues.
You should find that they are different in your 2 screenshots.
If, and only if you are running the latest version of Ceammc, then you can report the issue here...... https://github.com/uliss/pd-ceammc/issues
David.

@4poksy A standard sequencer is probably a few dozen instructions to the cpu and even the early rpi can do ~2000 MFLOPS, pd can get a great deal done between audio blocks despite its single thread nature. Has your experience demonstrated that you even need to worry about this? Even my 230k patch which is an entire programming language can accomplish a great deal between audio blocks and it can control all of the parameters for a good number of analog style subtractive voices in real time without issue. Sure my computer is a considerably more performant than a pi but still, it is getting a hell of a lot done between audio blocks.

An arduino will probably not help anything unless you have a good amount of interface stuff and/or are using one of the old single core pis, with a multicore pi you can just do the UI stuff external of pd and let the kernel deal with scheduling everything, it will almost certainly do a better job than a mortal unless your programming skills are getting up around kernel dev level. Even on a single core pi it may not be an issue. If it is a multicore pi than one of the things you can do is isolate a cpu core with the isolcpus kernel parameter, play with IRQ affinity and start pd on that isolated core with taskset or cpuset, this will make sure that the kernel does not stick some other process on the core with pd during a time when pd has an easy load which can cause dropouts when that load suddenly jumps. You can also structure your patches so all UI is separate from DSP which will allow you to isolate a second core and run UI on one, DSP on another and communicate between them with [netsend]/[netreceive].

But none of that may even be a problem, are you having issues with dropouts or are you attempting to preempt such issues? For the former knowing your exact issues would help a great deal in assisting you, for the latter learning more about how pd works and the system on which it will be run will guide you in what preemptive measures you actually need to take.

The stuff above regarding arduino and pi should be taken with a grain of salt, I have no direct experience with either and am basing that off of my electronics/pd/linux knowledge, but someone (hopefully) will come along to correct me in short order if my assumptions are faulty.

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.

@esaruoho [command] and [ggee/shell] allow you to execute shell commands and scripts, both are in dekken, no idea if they work on OSX but I expect they would. I also do not know what shell they run, might be limited to plain old sh for scripts but I believe I have used bashisms with both, would be surprised if I havn't so they may just load the users default shell.

@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!