@yannseznec said:

I have also been having some issues with stable Serial connection, and after some digging I learned that the Pi has a default Serial baud rate of 115200. That is likely faster than I need, but I couldn't figure out how to change this on the Pi (all the advice online seems to be for earlier OS versions...). So I instead changed the baud rate on the [comport] object to 115200 and it seems to work much better so far.
@yannseznec

thank you for the heads up, never spotted this technical detail, good to know.

Nau

@yannseznec

yet another trick that comes handy: in order to avoid the need of another physical display to work with your RPi you could install NoMachine (or any similar software) on the latter and on your (lap or desk)top and work on your Pd patch in a window on your (lap or desk)top in parallel with Arduino IDE or whatever editor you use.

Nau

@yannseznec

another useful point to know about is the size of the UART buffer, which is set to 64 bytes. When a code is buggy it can easily overflow and block further operation of the Teensy. You could call serial1.available() in order to get the number of bytes that are present in the buffer and monitor it in the serial console, and even set a conditional stop of the UART communication with Serial1.end before it overflows.

Nau

Hi,

this is possible, I've been fiddling around with code and patch in this direction for some weeks now, starting with a Teensy LC and heavily leaning on excellent @alexandros Drymonitis tutorial "Arduino for Pd'ers". Sadly I damaged the Teensy (floating power supply wires - stupid me), and had to keep going using an Arduino Micro as a mere substitute (and a 5V-3V3 converter in between them), but I do remember that it was already working with the Teensy, sending values sampled from a potentiometer tied to A0 pin to a pd patch running on the Rpi.

As of now I am able to transmit in both directions, with various packet lengths depending of the type of data and as many "fluxes" as needed. My code and patch is by no means clean nor properly commented and I plan to share it in the future through GitHub. I could share this in a private way anyway, I just need a free evening to gather the bits and write some explanation lines.

In the meanwhile here are some tech points that come to my mind: (sorry this is rather "trivial", but in my experience such "trivial" topics can be time-consuming, sometimes)

• connect Rx from one board to Tx of the other and GND together

• use Serial1 (or higher indexes) for UART communication, Serial for common console debugging, as advised by the manufacturer PJRC

• on linux I usually execute the command sudo systemctl stop ModemManager in a terminal first thing, if I remember well I had to find this workaround because the card couldn't be detected in Arduino IDE. (more of an Arduino Micro specific issue I guess but who knows...)

• sending data from the Teensy to the Rpi is easier (codewise) because you only have to create "packets" (i.e.: use start and end marker bytes to "frame" the relevant data) and send all at once. In the other way round (RPi->Teensy) you have to poll incoming data using a code structure that takes into account the fact that even with a high UART bitrate the Teensy will loop a great number of times, doing nothing, between incoming bytes because of its much higher clock frequency. See serial input basics - updated on arduino forums for more on that

Hope this will be useful, I'll try to pack up a decent recent version of my code and patch in order to share it soon.

Nau

Hi,

maybe could you have a look at waveform and hrslider abstractions from Maelstorm's GitHub.

Edit: sorry I don't have the time to test it now, maybe isn't lighter than classical technique but still neat abstractions, as is the whole "library" by the way

Nau

My two cents... Katja Vetter's expochirp

You could use [poly 1 1] for common mono voice stealing (automatic note offs), and go on with the envelope threshold.
Sorry I can't be more specific, it's difficult to put my hands on an example patch right now.

One option would be to use en Teensy : it has a micro usb port that can be used as usbmidi and of course lots of gpio pins. It looks a bit like an arduino micro but gives more for less money and can be programmed with the same tools (arduino IDE for instance). The teensy LC ("low cost") is already far better than an arduino micro for instance.

I think you could easily manage a monophonic voice triggering using a [poly 1 1] object.