I'm currently not in any condition to reply coherently, but my thought was that either you assume that a non-numeric leading atom is a selector or a symbol. Max (taking the OP's word for it because I'm Max-ignorant) assumes it's a symbol, and Pd assumes it's a selector. So it's just a choice that inconveniences those who think it should've been the other way. Please let me know how I'm wrong!

Edit: for instance (feeling irrationally emboldened by this example I just thought of), think about the set message for symbol boxes. If the leading "set" was interpreted as a symbol, then you'd lose the the "set" capability unless you added a new (potentially inconsistent) language construct.

PLEEEZE, I'm not arguing that Pd is consistent, I'm just sayin' that there are hard choices to make in language design.

@nicnut I agree with @alexandros that 200 ms is too long and think you could even try something shorter than 20 ms.

Here's another strategy: make 2 voices that accept play/stop commands and then toggle between them, e.g.
This sends the stop command to one voice and the play command to the other, so that the voices effectively crossfade. The voices should fade up on start and fade out on stop, and if a stopped voice receives a stop command, it should keep quiet. This scheme will still pop if you bang twice within the crossfade period, but you could prevent that using a lock-out timer.

@jamcultur I think it's just a display option. If you want to interpolate between your 7 points, you either have to roll your own (e.g. linear interpolation), or use tabread4 (which requires you to pad your 7 points at the beginning and end). Tabread4 has some strange inflection points though that might not be what you want. Maybe someone knows of an external you could use?

@Ice-Ice yeah, I'm afraid I'm getting the same results as you are (Win10). Even the help patch gives the same results.

Hmm, I see the dll is from 2018. I wonder what Pd version the author was running?

@Ice-Ice Try adding [declare -lib csound6~]

@didipiman said:

So I guess my question, rather than trying to revive that old patch, would be: is there any documentation on how to send data to Enttec DMX USB Pro from Pd?

Not sure if this is what you're looking for, but I designed a show a while back that used Pd as a serial-to-OSC bridge between an Arduino and QLC+. QLC+ is open-source lighting software that understands OSC and MIDI and which happily drove the cheapest Entec DMX dongle I could find. I scripted most of the DMX stuff in QLC+ and then just triggered the scripts from Pd via OSC. That part was surprisingly reliable.

Adding on to what @alexandros wrote, you could also try [vcf~] which is a vanilla object. It has both bandpass and lowpass outputs, and you can vary q. I've chained 3 in series for a stronger effect.

Also, I recommend taking things one step at a time and verifying you got things right before continuing to the next step. It could be;

• Verify that you are getting MIDI input into Pd and that you understand the data coming in.
• Check that you can convert MIDI pitch to frequency, which is what the filters will need
• Maybe start with a mono patch with just one filter
• Then tackle stereo and/or polyphony

@porres Dude, I saw the smiley face, but I do want to say that I've seen a marked improvement in the help files and documentation over the decade I've been fiddling with Pd, so your efforts haven't gone unnoticed.

@chvolow24 As far as I understand from help, [netsend] doesn't support what you're expecting. I wonder if there's a way (outside of Pd) to forward your return packets to a different port?

@chvolow24 On the client-side [netsend -u], are you connecting to both the send port and receive port?