@Blaine24 Look into @alexandros's library for Arduino-Pd com examples (which I think is https://github.com/alexdrymonitis/Arduino_Pd but I'm hoping @alexandros will correct me if I'm wrong), or you could try my way https://forum.pdpatchrepo.info/topic/13086/arduino-to-pd-vanilla/8. In that example I send "list <float> <float>;" but in your case you want to send "list PAD# <float>;" Observe the space separators--they're significant!

That first select is looking for the end-of-line (EOL) character (the thing appended by Serial.println()), otherwise it's queueing up the characters in the order that the Arduino sends them. When EOL is seen, it parses the list of characters into a Pd list, e.g. "PAD4 42", which you can then route as you did in your example code, although I don't understand what you're doing with the output of [route]. In my way, each of the [route] outputs (except the last one) should just pass the value for each pad.

Edit: I ran a test and it looks like you don't need the list prefix.

@oid said:

Calculating the value of the resistor is simple

Yes, but you neglected to give the OP the formula, which is a little harder to figure out . It's approx 0.13 of the value of the potentiometer. So for a 10k audio taper pot you want a 1.3k resistor. And for the record, it increases the load that the pot presents to the power rails by a factor of 10 when it's fully counter-clockwise.

To me, both solutions are just linear-ish, You can find a discussion of it here: https://www.modwiggler.com/forum/viewtopic.php?t=56318. You can see that they discuss 0.12 so 0.13 is not exact, even more so since the audio taper pot isn't exactly log. I'm not claiming that linear pots are perfect, but if it were me I'd just go buy the right pots and chalk up the extra expense as tuition. Unless there was a show breathing down my neck.

@callummalcolm In my experience, "audio taper" pots and faders aren't mathematically logarithmic like Pd's are, which is why you can't make Pd's log sliders go to 0 without extra effort. So here's a solution that works in Pd, but what I'm saying is that it probably won't linearize a physical audio taper pot well. I made a table-driven transfer function to linearize the CC messages coming from the faders on my Yamaha 01V96i and the line is somewhat arbitrary, especially at the bottom of the travel. Let me know if you want to try that route and I'll tell you more. Capturing the physical curve is kinda messy.
log2lin.pd

@kyro I don't understand your previous comment, so consider this an alternative answer to your original post

If you can tolerate the latency, I wonder if an FFT filter would work for you? You can test with audiolab's pp.fft-split~. Set the frequency to 20 and take the middle output.

Oh wait! I think I just understood your previous post! So this probably won't work for you because I think you're objecting to the latency.

@bklindgren Maybe "expected I/O latency" or "realtime processing budget"? I say that because if the actual latency is greater, you'll hear clicks as blocks are dropped or corrupted. But the expected latency can be set much greater than the actual latency without problems. Look at the following test:

REAPER sends the test tone on track 1 out its audio loopback driver to Pd, and Pd returns it on the next 2 channels in the loopback driver. I recorded the return signal on tracks 2 through 5 using Pd delay settings of 50, 20, 10, and 100 ms, respectively. The delays on the return tracks are 52, 21, 11, and 101 ms respectively.

@bklindgren From the manual:
The "delay" is the nominal amount of time, in milliseconds, that a sound coming into the audio input will be delayed if it is copied through Pd straight to the output.
I've always assumed this includes the time it takes for the audio interface to fill Pd's input buffer, the time it takes for Pd to process a straight-through connection, the time it takes for Pd to fill the output buffer, and any OS-specific/driver-specific/audio-framework-specific overhead. I suspect that some of these categories overlap. So I wouldn't say "it's the buffer" exclusively, but in as much as a larger buffer takes a longer time to process, then yes, buffer size is probably a factor. For example, with a 64 sample buffer, I'm able to set delay much lower if I select an ASIO driver than if I select one of the Windows built-in drivers.

@ddw_music said:

Gotos have been discouraged for a long time because they're messy.

Hmm, that's interesting, have you considered Java's use of gotos? They're structured, provide a convenient way for exiting deeply nested loops, and feel similar to Java's exception framework.

Never mind, I just couldn't resist. Carry on.

FWIW, I interpreted "spray everywhere" to mean that Pd "functions" spray their return values to every place that could potentially need it, depending on the control flow. That's a common way of dealing with Pd's lack of intrisic "return to caller" when there are just a few callers.

@ddw_music said:

(and is basically identical to the approach in my example patch above).

Oh sorry, I missed that. TBH I've been barely hanging on I'll go back and read why you were hesitant about endorsing this approach. But don't you think that in the end, all languages have things that are convenient and things that are inconvenient, and so....so what? Before I retired I was studying functional programming languages like Haskell, and I didn't get far enough along to understand how the hell you could program without state! I understood that it was great for multiprocessing, but wow.

@ddw_music Does this behave like a shared stateful function that returns to the caller? returnToCaller.pd

@whale-av said:

Maybe that could be described as a bug, as I cannot see that anyone would ever have used it for any purpose

I'd bet that the following theorem is true:

All Turing-complete languages contain useless statements

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?