Pure data on Teensy 3.6

Status
Not open for further replies.
F

frank_channel

Member
I just received my Teensy 3.6 and am excited to get started with it. The first project I would like to work on is getting Pure data running on my Teensy using libpd: https://github.com/libpd/libpd.

I know there is already an Audio library for the Teensy, however, I am still interested in this project for a number of reasons: i) I have experience using pure data, and I have already a repertoire of audio "patches" developed in the language; ii) I like that I can test and develop patches on the desktop; iii) Pure data patches can be loaded and changed at runtime.

My main question is as follows. When loading a pure data patch (which describes the audio processing graph) libpd makes calls to fopen and lseek. These are platform dependent system calls, which are implemented in "newlib" as stubs that return an error code (I think). I am guessing the first thing I will need to do is overwrite these stubs with implementations specific to the Teensy 3.6 hardware (e.g., loading a file from the SD card, reading blocks, etc)? However, I'm not 100% sure how all this works (and it is a little opaque to me when using the teensyduino). For example, do I need to rebuild libc?

I am looking for any help in the form of examples, advice, etc... For example, has anyone done any "retargeting" with a Teensy? If so, what is the work-flow, and are there any pedagogical examples?

All the best,
Corey
 
Last edited:
Hello,

Amazing! I just wondering exactly the same thing!

My primary goal is to build an analog inspired modulation delay from objects I build in Pure Data. I tried to rebuild it with the prjc vanilla audio library tool with no success, and time changing delay sound really bad.
Ideally, I could be amazing to "compile" PD patches directly to the teensy, like the OWL does... I admit it's "in my dreams" for the moment.
I've read lots of forums around the web and I never seen concrete example of this. But technically it's absolutely possible with ARM processor, like the way you try using libPd as a library in the C code (Arduino work this way too). The real problem here is the lack of information about the process to achieve this.:confused:
So, if people have made some experiments around this specific trick, please share your experience.:eek:

regards
Q
 
Yes, I've seen that. But you have to use their compiler to produce code from a given patch. I would like to have several patches stored on a SD-card and be able to choose which one to use at run-time (e.g., using an encoder and LCD screen to select the patch, etc). It shouldn't be too hard to get libpd working... the first thing to do is re-target the low-level functions in newlib to the teensy (e.g., open, lseek, etc). Then a wrapper would be need to be written that fills a buffer and uses the DMA peripheral to write samples to the DAC (or I2S or whatever output)... I haven't had much time to work on this yet, though.

I was hoping someone else here had already done some "re-targetting" on the teensy for some other project. That would help a great deal in understanding the workflow (e.g., how to set up the toolchain so as to override newlib's stubs, and compile projects with the modified libc). It's a bit harder to figure out using teensyduino (might be just easier using a makefile and teensy loader?)
 
I don't understand how a makefile will make this easier, but you can find one in hardware/teensy/avr/cores/teensy3.

My gut feeling says this will take more than a minimal posix emulation layer. You'll probably need to dig into that code. It probably contains several assumptions about conventional PC operating systems that aren't easily solved by a wrapper layer.
 
hi, discussing with a friend on facebook
he told me that run PD on teensy don't make sense because is a simply microcontroller not crafted for audio processing...
what do you think about?

This are the spec of the OWL project
8kHz to 96kHz sampling rate
More than 3000 instructions per sample @ 48kHz
Powerful microcontroller:
168MHz 32bit ARM Cortex M4
192KB RAM, 1MB Flash memory
Integrated DSP, FPU, DMA
1MB external SRAM
16/24 bit codec
Stereo in/out
USB MIDI
Click to expand...

And this the spec of the new teensy 3.6
180 MHz ARM Cortex-M4 with Floating Point Unit
1M Flash, 256K RAM, 4K EEPROM
Microcontroller Chip MK66FX1M0VMD18 (PDF link)
USB High Speed (480 Mbit/sec) Port
2 CAN Bus Ports
32 General Purpose DMA Channels
22 PWM Outputs
4 I2C Ports
11 Touch Sensing Inputs
Click to expand...

can you tell me what the differences are so teensy could not turn on PD with similar owl's performance?
Thankyou
 
urbanspaceman said:
teensy don't make sense because is a simply microcontroller not crafted for audio processing...
Click to expand...

Well, that is simply not true. Audio processing on the teensy has already been demonstrated (see the Audio library).

That said, the current UGENs in libpd may not be particularly well optimized to run on the teensy, but that is another story (and something that could be worked on)...
 
I hope that someone work on this part, it will be a great step up for teensy to run Pdlib or Faust or other audio oriented frameworks.
 
Perhaps you are right (although according to the authors of libpd it was designed to be embedded). I'll post back here after I have time to investigate more. My real first question, however, was really: are there any good examples of "re-targeting" on the teensy for other projects? There are all sorts of details that a simple example might clarify (e.g., does newlib need to be recompiled without syscalls, where should the initialization code be called, etc, etc)...
 
Faust should be a lot easier, actually, since it can generate a self-contained C++ function that contains the audio processing (which could just be cut and paste into a wrapper that loads samples from the ADC and outputs samples to the DAC)
 
Status
Not open for further replies.
Back
Top