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

Thanks, I'll give it a try.

Hi there,

thank you @EEight for you work! I'm a compulsive reader, and missing posts makes me (relatively) sick.

Each time I'm away from keyboard for a week or two I experience the same behaviour : instead of the tens of unread posts I'd hope to find in my "unread" section, only the more recent of them are to be found. I couldn't find any option in my profile settings to be tweaked. Is there something I can do, outside of using the "recent" section and go down the timeline?

Thank you!

Nau

Thank you @Jona,

I started to discover ofelia and openFrameworks and it's very promising, even though it seems difficult to understand if OF will be "better" than QT or WxWidgets in my personal context. Of course ofelia brings it directly (but partially if I understood well) into pd, and that's really impressive.

I'll dive into documentation tonight!

Nau

Hi there,

I like the simple yet useful array object, but I'd like to be able to zoom in and out, and to edit data with a higher precision. I've been playing for some time with [hrslider.mmb] and [vrslider.mmb] objects within pd-extended in order to achieve this with mixed results. In addition I'd like to implement other features so naturally came the idea to create such an editor, outside of pd, and make the two of them communicate using a simple '.txt' file.

I recently started to learn C++ and would like to ask for some advice in order to follow my thread smoothly. The starting specifications would be

• fixed number of points
• homogeneous horizontal discretization
• "control-oriented" editor rather than "waveform-oriented"
• drawable graph such as in pd, directly with the mouse
• zoom in, out and by region selection, obviously keeping the precision of coordinates
• possibly : axis graduations following the zooming operations.

So there probably exist open source applications that are already doing all this, and I'd be glad if someone could point out some of them. I'm looking for a starting point, something that would serve as a basis, having C++ programming in mind. My C++ and OOP skills are quite fresh, although I've been coding as a hobby for years, and I'd be glad to dissect and study some well-formed piece of code to go deeper into my learning process. This way I hope to be able to implement other features that I will spare you. My "paradigm" is somewhat similar to a midi control change editor, and I think this could be a lead.

I'm a linux user, but I'd like to use multi-platform libraries, and I'm considering learning to use QT or WxWidgets. But at the moment I couldn't find a way to break the tie. Probably because the articles and comments I read so far weren't dealing with my precise context, but maybe will there be someone here that could give me some advice?

Thank you very much!

Nau

Hang in there!

Hi,

I couldn't find any description nor video nor screenshot presenting the idea behind Spaghettis. Is there any way of getting information other than a "compile and test by your own" scheme?
thanx,

Nau

Maybe could you compare it with I03.resynthesis.pd that you will find in the help files, in the directory pure data/3.audio.examples ?

Or [<~], [==~] and [>~] maybe? Just thinking out loud.

When doing such things, filtering out the resulting continuous component is a good idea.
[hip~ 5] or some higher order highpass filter would do the job.

Waves observed in liquid, in a string, in a drum head etc (material waves) are functions of time and space while audio are only time-dependant. As a result you can derive audio signals from a material wave for by fixing a position and observing a property of the material wave at this dertermined position over time. For example, let's imagine a little fishing float maintained that would "freely" slide on a vertical rod maintained in a fixed position in water (in order to get rid of the space variables). The float would go up and down over time as the waves come and go, and the vertical position signal obtained would be a an audio signal (provided it's mean over time is zero), also all the derivatives of this signal accompanied by frequency multiplication and amplitude modifications, but also pressure or desity measurements or whatever you want. This is a way of thinking the link between material waves (the ones you draw, with the horizontal axis representing space, with a freezed time) and strictly time-dependent signals (very near to audio signal, just a matter of being "centered" on the x axis).
This proximity allows for "sonification" of intrinsically non-audio phenomena, like "hearing a black hole squeaking" etc.

Sorry, now that I'm reading back what I've written I feel like all this is probably obvious to you, or simply useless.

Nau