@henrique99sl I don't understand, why would it be bad if someone else in your class saw your patch?

@ingox said:

@oid No question. I just wanted to show this way of implementing recursion in Pd. Isn't that a technical issue?

Oh yes it is, and a really badass one too. Thanks for letting me know that there are different kinds of recursive functions. I'm looking forward to learning your patch when my current show closes.

@KMETE You could also make a 10 track wav file and play that back.

Hi, I just wanted to report a related discovery. When REAPER loads a Camomile VST3 on an M2 Mac, it runs it via an x86 bridge process because they are compiled for Intel processors (so says the internet). With my plugins, this bridge process almost doubles their CPU overhead and causes REAPER to load quite slowly. Rewriting my plugins for PlugData addressed both issues--PlugData is apparently ARM processor-compatible.

edit: that said, I've seen REAPER crash twice now as I've edited patches in PlugData when it's hosted as a VST3. So be careful.

@FFW BWAH HA HA HA HA HA ... I just tested this insane version with Qlab and it worked:

Note to self: must get a life

Edit: a more modern version:

@FFW He he he....or since the backslash is always at a fixed position in the complete OSC control message, take the output of [oscformat] and just remove the byte at that position Oh wait, no, I think I'd have to also add some padding to the end to meet some message length requirement.

@whale-av said:

@jameslo There can be spaces in the address.... the [oscformat] help is full of them between symbols.

Between symbols is different from what I'm asking--I'm asking about within a symbol (i.e. "Container"). [oscformat patch 1] outputs "/patch/1" but what the Qlab OSC dictionary seems to imply it wants is ".../patch 1/...". From their documentation:
and the default name for the one uneditable audio patch you are allowed in the free version is "patch 1". (Did that sound like a complaint? In no way am I looking a gift horse in the mouth! Technically you have to buy a license to be able to adjust that level in the GUI, but for some reason it's adjustable via OSC and it works. I guess their license fee is a tax on non-hackers )

I'm trying to write an OSC control message for Qlab and one of the nodes in the path is supposed to be "patch 1". Yes, that's a space between the 'h' and the '1'. Is that legal OSC, and if so, how do you coax [oscformat] to emit it?

edit: Oh duh, I can just change the name of the patch to not have spaces. I'd still like to know if spaces are legal and possible with [oscformat] though.

@AndreasA I've never used Pduino or firmata, I've always just coded the Arduino-Pd interface using [comport] or TCP/IP. Here's my comport method: https://forum.pdpatchrepo.info/topic/13086/arduino-to-pd-vanilla/8

@AndreasA I'm assuming that the numbers you are seeing in the Arduino IDE are timings you captured on the Arduino, not using [realtime], is that correct? If so I think @alexandros is suggesting that you send those timings to Pd, instead of trying to measure the times between Arduino messages on the Pd side.

I'm guessing what you are measuring with [realtime] is when the OS schedules the Pd process to handle the next Arduino message, not when the message actually arrived at your computer, so that could explain the apparent rounding to the nearest 10 mS. I first saw this kind of rounding while investigating this problem: https://forum.pdpatchrepo.info/topic/13489/realtime-detecting-lack-of-correct-delay-in-the-delay-object

@fishcrystals said:

I'm curious tho - pretty sure opening the pd doc for the camomile VST3 with plugdata would fix the midi problem....

YESSSS! PlugData solved the issue. Thanks for bubbling that option to the top of my list.

@whale-av But I used PlugData as a VST3 in REAPER, so VST3 doesn't support MIDI except when it does?

ARRGH! Using a round-trip latency test I wrote, I just measured 39mS with the M2+01V96i!

So help me understand:

• I finally get shamed into buying a new MacBook after several theater techs comment on it.
• Plus my hand is forced by Qlab 5, which needs a more recent OS than my old MacBook can support, and I only needed Qlab 5 to support a show I was unhappy working on.
• So I upgrade and get better performance in some areas but get almost 4X worse performance in others
• Plus I lose the ability to script little problem solving MIDI widgets

Does that about summarize things, and is this the new normal?

Unable to let it go

This Camomile+Pd VST3 also works on Windows but not on my Mac M2 (it outputs nothing as far as I can tell) so it's not just CC messages that are messed up.

Next up (but the order will probably be mood-dependent):

• Dig old 2012 Mac out of closet and test on it
• Try Camomile 1.0.8 beta
• Try PlugData

@whale-av said:

.... so maybe the question is why does it work for you on windows?

Dang yo, I think you might be right. No doubt Pierre Guillot is clever. Googling "vst3 midi cc" turns up lots of platform-agnostic brow-furrowing and teeth-gnashing. I just now remembered that REAPER includes the ReaControlMIDI plug-in that generates ad-hoc MIDI messages, but that's a VST, not a VST3! So I went back to see if Camomile included a plain VST component, but it didn't

I'm honestly happy to have been forced to learn a little about Mac, but it's only been Qlab and its omnipresence in the performance world that's been doing the forcing.

One of the search results (that I didn't read) seemed to be about handling this limitation in JUCE, so maybe @timothyschoen is exploiting something like that? I'd love to hear from PlugData users if they've been successfully sending CC messages from their patches running as plug-ins on an M2 Mac.

@whale-av I'm using the default MIDI control mapping documented in the 01V96i reference manual and decided to continue using it but to send each channel's CC message directly from Qlab instead of trying to have Camomile/Pd map OSC messages to groups of CC messages. But what I was wondering, probably unclearly, is why I've appeared to lose the ability to output CC from a Camomile/Pd VST3 plug-in on my new Mac, something I did routinely on my old Mac, the last time in 2020. Is it a VST3 issue? an M2 issue? A Camomile 1.0.7 + Pd 0.54.0 issue (1.0.7 looks to be 3 years old)? REAPER running under MacOS? You get the idea.

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.

@kleko Here's an excerpt of something I wrote to read the 14 bit CC messages generated by each fader of my mixer. I'm not sure if this is always the case, but my mixer always sends the most significant 7 bits first, so that's why I can be casual about the fan-out from that first route.

@Nobody Oh, you're right, rpole~ uses the previous input, but you wanted the previous output. My bad. Maybe you could prototype with [fexpr~] and then search for something more efficient (if it matters) once you know it's working?

Edit: crap, just saw @seb-harmonik.ar's post, my bad again. rpole~ doesn't use the previous input, it uses the previous output.

@Nobody Take a look at the help patch for [rpole~]

@lacuna Oh I see, my bad! I hear the smearing now. I wonder if increasing the overlap would help? I wonder if that would require a different shaped window? I would think it would also affect the normalization constant.

Edit: Hmm, maybe not. I increased the overlap to 32 and the normalization const to 12N but kept the Hann window and it still smears. I03.resynthesis 4096.pd But this is just me taking a random shot in the dark.