I've been doing a bunch of experiments with PD on a Raspberry Pi, with custom-built MIDI control via a Teensy microcontroller. I've been using Raspbian lite with no GUI. This was working really well until recently.

For various reasons I updated my Raspberry Pi to the latest Raspbian (Stretch) which also allowed me to get a slightly more decent build of PD, 0.47.1.

Since doing that I can't seem to get any MIDI input in PD, no matter what startup flags I use. Most tellingly, if I run pd -nogui -listdev I get the following list:
audio input devices:

1. bcm2835 ALSA (hardware)
2. bcm2835 ALSA (plug-in)
3. Teensy MIDI (hardware)
4. Teensy MIDI (plug-in)
   audio output devices:
5. bcm2835 ALSA (hardware)
6. bcm2835 ALSA (plug-in)
7. Teensy MIDI (hardware)
8. Teensy MIDI (plug-in)
   API number 1

no midi input devices found
no midi output devices found

--
I find it very odd that it lists my Teensy MIDI device as an audio input and output, and also says that no midi input or output devices have been found. It is somewhat understandable that my patches will not therefore recognise any midi activity, but I don't understand why PD isn't seeing the MIDI devices.

If I run aconnect -o I can see that the Raspberry Pi recognises the device:
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
client 20: 'Teensy MIDI' [type=kernel,card=1]
0 'Teensy MIDI MIDI 1'

and if I run aseqdump -p 20 the MIDI data comes streaming through normally. I'm interpreting this to mean that the MIDI device is working, and the alsamidi system is working on the rPi. My only explanation is that something has changed in PD 0.47.1 to create this bug?

I am thinking about starting from scratch and installing Raspbian Jessie instead to test and see if this works, but I'd like to avoid that if possible! Any ideas?

@ingox I think all operating systems collect keystrokes, mouse movements, kernel activity etc. for encryption purposes.
But access will be different for each one probably.
This gets kernel load in a browser in JavaScript....... https://github.com/keybase/more-entropy
Maybe start it, open a socket, send to patch....... (always "maybe"..... )
David.

Okay ;that's what I suspected you were doing. It is possible to use the MTP serial directly with linux and the mtpav driver, though this requires a machine with true hardware parallel port access (USB adapters won't cut it) and is limited to MIDI output only as the driver is a hack that was never finished. I used to run mine that way with a second USB MIDI interface connected to one or more of the MTP's unused routed MIDI outputs (there is, BTW still no way to connect the MTP USB version directly to a Linux system as it doesn't use a standard USB MIDI driver)

As far as the kernel is concerned, I've only ever used lowlatency or RT kernels for MIDI stuff. I don't know how a generic kernel would affect this problem but it's probably best avoided as they are not specifically built for multimedia.

Now read closely as this is where it becomes stupidly complicated.

First, make sure that the problem is internal to Pd. Your interfaces are probably not the issue (since Pd is only seeing the UM-1 driver I don't think the MTP even figures in here). However, the chosen MIDI API can get in the way, specifically in the case of the unfinished JACK MIDI. JACK MIDI presently can only pass SYSEX as short realtime messages. SYSEX data dumps will disappear if sent into the current JACK MIDI system. ALSA works OK. OSS probably too, but I have not tried it.

If that stuff is ruled out and you are still getting problems, it probably has to do with a set of longstanding bugs/oversights in the Pd MIDI stack that can affect the input, output, or both.

On the output side there is a sysex transmission bug which affects all versions of Pd Vanilla before 0.48. The patch that fixed Vanilla had already been applied to L20rk/PurrData for some time (years, I think). The output bug did not completely disable SYSEX output. What it did was to miss-format SYSEX in a way that can't be understood by most modern midi applications, including the standard USB MIDI driver software (SYSEX output from Pd is ignored and the driver/interface will not transmit anything). You would not notice this bug with a computer connected directly to an MTP because the MAC and Linux MTP drivers are programmed to pass raw unformatted MIDI.

If this is the problem and you have to use a pre-0.48 version of Vanilla it can be patched. See:

https://sourceforge.net/p/pure-data/bugs/1272/

On the MIDI input side of Pd we have 2 common problems. One is the (annoyingly unfinished but nevertheless implemented) input to output timestamping buffer that's supposed to provide sample-accurate MIDI at the output (if it was finished). This can be minimized with the proper startup flags (for a MIDI-only instance of Pd, -rt -noaudio -audiobuf 1 -sleepgrain 0.5 works for me) or completely defeated with a source code tweak to the s_midi.c file. This may not be the source of your particular problem as it usually only affects the time it takes to pass messages from input to output, but is worth mentioning as it can be very annoying regardless.

With SYSEX dumps it is more likely that the problem lies with the MIDI queue size. This is very common and I experienced it myself when trying to dump memory from a Korg Electribe Ea-1.. The current version of Pd limits the queue to a size of 512 (even worse it used to be 20) and any input larger than that will get truncated w/no error warning. There is not yet any way to change this with startup flags or user settings. This can only be "fixed" by a different tweak to s_midi.c and recompiling the app.

The attached text files are derived from the Pd-list and will show the specific mods that need to be made to s_midi.c.

pd_midi_io_timing_buffer_mod

pd_midi_input_quere_mod

I'm not sure what kind of sound you are going for exactly, but if you plan to oscillate only one cycle of the waveform, you can expect it to come out sounding like an old buffered op-amp synth from the 80's. A cool sound, yes, but not entirely 'organic. use a larger portion or 'granule' if you will, to get it more natural sounding. Experiment with crossfading and looping the granule forwards and backwards in an alternating loop... sometimes that can help compensate for volume dips in elongating percussive instruments like a piano. Hope that helps

here is a nice collection of game of life objects, perhaps the 3d objects are useful for mapping several sounds or other parameters: https://commons.wikimedia.org/wiki/Game_of_Life?uselang=de and here are some examples of existing musical implementations:
http://people.ece.cornell.edu/land/courses/ece5760/FinalProjects/f2011/lba36_wl336/lba36_wl336/index.html
http://tones.wolfram.com/generate/GLVpE3LbDUTbzs1eNYPVjqdtPYK299o6uu1CFDvWhhGSQ7VAfC
http://grantmuller.com/projects/game-of-life/

If planet ccrma has a real-time kernel, then go for that. I can confirm that editing the limits.conf file won't harm your system. Only, when you run Pd (and Jack if you run it with it), your computer won't be able to do some things like play a Youtube video, for example.
But you'll need these permission (and to add yourself to the audio group) in order to get real-time. You'll definitely need a real-time kernel as well to run on real real-time.

I was wondering if someone could give a little overview on the current (end 2016) situation on installing and running PD, l2-ork or purr-data on recent ARM boards, for somebody just getting into embedded systems (read: somebody terminal-literate, but not savvy enough to compile kernels).

The project is building a display-free modular sampler instrument, so GPIO, USB MIDI and USB audio I/O are paramount. Everything else (WIFI, BT, GPU etc) is secondary.

More specifically:

• Are more recent boards like Pine A64, Odroid C2, Chip (PRO?) or BBB worth considering?
• If so, what's the story on DSP performance/latency and RT kernel tweaks etc, compared to Pi3?

Much obliged,
S

That looks so damn good!

I threw together an Orange Pi One in a 1590BB enclosure a few months ago, and this post kind of inspired me to do so. I used an arduino nano for the I\O, a 2 dollar CM108 usb codec, and a 4 character LED display I had to write a driver for. With x-forwarding set up, I can just plug an ethernet cable in for full control.

I'm using armbian, and so far the audio works. Did you have to compile a RT kernel yourself? Thats the trick I'm currently stuck on. I can compile it but it wont boot.

It is also not nearly as pretty and well done as yours.

If you're curious, my github has the rough draft of it. An install script to compile from source and drag pd-extended's externals into the right place, set up audio permissions and x-forwarding, With a vanilla kernel (no preempt) it works well without dropouts. The next step is to design a PCM2906 soundcard with 2 in and 2 out audio and correct buffering.

Where did you get that enclosure? It looks like it has tons of room for expansion!

Well first, to be clear, the part inside the square brackets is just the Blackmann window. The fraction to the left (without K) is the sinc function.

Secondly, for sin(x), x itself is not a frequency and therefore should not go in the frequency inlet of [osc~]. It's more like a phase input, if you were treating sin() as an oscillator (which it isn't in this case). If you wanted to use dsp object to make this, you'd be better suited using [expr~ sin($v1)]. You could also use [cos~] but it expects a normalized phase, not radians, and needs a phase offset to make it act like sin().

Since FIR filters like these use convolution and tend to have long kernels, implementing it with vanilla objects can be a nightmare. You could probably use the FFT objects to do it, but since the overlap is based on the kernel size you might be restricted on what sizes you can use (I'm not entirely sure about that, though, never tried it).

I used to use [iemlib/FIR~] for it, but it doesn't seem to be working on 64-bit systems. You can use [bsaylor/partconv~], though. It does partitioned convolution and is meant for long IRs, but it works just fine for FIR filters as well. The annoying thing is that whenever you update the kernel you have to resend it to [partconv~] and you get some clicks and messages in the console when you do that.

Attached is an implementation. M is variable, between 3 and 255. As you can see, M doesn't actually need to be even. Odd values for M just place a zero at the Nyquist frequency, so the roll-off at high frequencies is different for even and odd values. I just used [until] to generate the kernel, so no dsp objects needed.

FIR_example.zip

Hey,

I'm trying to create my own low-pass filter in Pd. So I would like to ask if you guys knew how to implement a the following fllter kernel into puredata.

I already have created the Blackman windowed sinc. Which is the last part of the function inside the square brackets. For the missing part: .

I have created the following.

I'm note sure what I'm doing wrong. Only that I think there is something completely wrong with the code circled in red. Hope you guys can see my mistake(s). Also I have to remark that my window size is 65.

Regards,
Slashpwn