An implementation of FFmpeg for audio playback of almost any media format

When building, the FFmpeg libraries are dynamically linked by default, which means that you'll need a local installation of these libraries in order for the external to work.

Includes the following features:

• play/pause and seek functionality.

• changing the speed of playback.

• reading and iterating through m3u playlists.

  • It reads pseudo m3u playlists. Each line in the m3u should be just the file name, preceded by a path relative to the location of the m3u if they don't reside in the same folder.

  • The m3u reader can also read nested m3u's. For example, an m3u could consist of the following three lines:

  disc1.m3u
  disc2.m3u
  disc3.m3u
  

• opening files from http urls.

• retrieving metadata.

Creation args

1. numeric list

   • The channel layout. Defaults to stereo if no args given.

   • Numbers specified represent the bits of an audio channel bit-mask. A full list of available channels can be found here: https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/channel_layout.h

Inlets

1. bang - Play/pause the currently loaded track.

   • Sends a 1 or 0 through the last outlet to indicate whether it's playing or paused.

   float - (Re)start playback of a given track number

   • Zero will stop playback.

   anything - Look for matching metadata

   • If metadata is found, it will be sent through the right-most outlet.

• A file must be successfully opened for any of the above to work

2. signal - Change the playback speed.

   • speed can be a factor between 16 and 1/16th.

   • speed can also be altered by sending the message [ speed $1 ( to the 1st inlet.

Outlets

1. signal - Left channel

2. signal - Right channel

   • The number of signal outlets there are depends on the number of creation args given, with the default being 2 signals for stereo.

3. list - Outputs various messages including information regarding whether a file was successfully opened, whether a track is currently playing, track metadata, etc.

Messages

• [ print $.. ( or [ info $.. ( - Prints metadata info.

  • If no args given, it will print general info. Otherwise, it will print custom info.

  • metadata needs to be surrounded with percent signs.

    • Example [ print %artist% - %title% (

• [ send $.. ( - Sends metadata info through the
  last outlet.

• [ open $1 ( - Attempts to open a file.

  • Sends a 1 or 0 through the last outlet to indicate success or failure.

• [ seek $1 ( - Seek to a track position.

• [ speed $1 ( - Set the playback speed.

• [ play $1 ( - Set playback state to either playing or paused.

  • Acts as a toggle when no args are given.
  • When an arg is given, state is forced to playing(1) or paused(0).

• [ interp $1 ( - Change the interpolation algorithm.

  • Options include:
    • Sinc (good | medium | fast)
    • Zero-order hold
    • Linear (the default)

• [ stop ( - An alias for [ 0 (.

• [ pos ( - Returns the track position.

• Any unrecognized message is assumed to be a metadata term. If there is a match, the metadata will be sent through the last outlet.

Update - March 16 2022:

ffplay~ now uses Secret Rabbit Code for resampling, which makes playback speed transitions much smoother. Playback speed can also be manipulated with signals via the 2nd inlet.

ffplay~ is now available through deken. It is part of a larger library called quilt. Searching either "quilt" or "ffplay~" should give a result.

The FFmpeg libraries are still separate, but can be either easily downloaded or easily installed via a package manager.

For Windows users, the FFmpeg libraries can be downloaded here: https://github.com/myQwil/pd-quilt/releases/download/v0.7.7/ffmpeg.v4.4.1.Windows-amd64-32.zip.

For Linux and macOS users, A README file is included, which lists the dependencies for those platforms.

ffplay~.zip

Hi zigmhount!

This is a copy paste of a message I (hopefully) sent via chat as well:

I figured I’d tell you a bit more about my patch so we can see if there’s overlap. Switch is definitely an overlap. I’m not using a metronome at all on mine. The inspiration was two loopers I love: the line 6 DL4 and the EHX 45000. It’s going to be 4 foot switches. Record, play, previous and next. Record and play function the way they do in the DL4. Record to start a new loop, record again to set length and start overdubbing or play to simply set length and start looping. From there record works like overdub on/ off toggle and play stop or restarts the loop. Previous and next are where it gets interesting.

There’s a 7 segment display (meaning a 1 digit number read out) that tells you what loop you’re “focused” on. It starts on 0. You can’t change focus until you have a loop going. Once you do, prev or next change focus. If you change focus while recording, it closes the loop you’re on and starts playing it, then immediately starts recording the next loop. The next loop though can be as long as you want. However, silence gets added to the end of the loop when you are done so that it matches up with a multiple of “loop 0”

In other words, loop 0, acts as a measure length and all other loops are set to a multiple of that measure length.

But...they can start anywhere you want. To the person playing the looper, it will feel like individual loops are all overdubs of the first loop, just at any length you want. I don’t know if I’m explaining this so well, but the point is, you don’t have to worry about timing or a metronome with this. You don’t have to wait for the beginning of measures to start or end loops. Once you have the timing of the first loop down there’s no waiting... you start recording and playing whenever you want as long as you want t and if it’s in time when you play it it will be i the recording.

So far I have recording and overdubbing down on loop 0 WITHOUT CLICKS. this took a lot of work and messing. Sounds like you are struggling with that now. Hardware is important yes.

I’m running it on a rasberry pi 4b 4 gig memory but with a pi sound audio interface. It’s more expensive than the pi but the latency and sound quality are GREAT. I also wanted to make the hardware all independent eventually and have the whole thing fit i it’s own box. The foot pedals run on an arduino that talks through comport to the pi and pure data.

In pure data I’m timing the loops and recording them via tabwrite. I’m then playing them with tabplay with a 0 $1 message box where 0 is start and $1 is the length, rounded to block size, of the recording. I record and play the same arrays for each loop at the same time while overdubbing, but delay the recording so it’s a few blocks back from the tabplay. The delay on the recording seemed to help elimate clocks as well. So did using tabplay instead of tabread 4. I think the phasor is CPU expensive or something. I don’t know. When I start / stop recording I use a line ramp on the volume going into the recording of 5 msecs. This is also necessary to eliminate clicks. Also, I had to stop resizing or clearing arrays as both cause clicks. Now I just overwrite what I need and don’t read from what I didn’t overwrite (If that makes sense).

If you are getting clicking I would try upping block size, buffer size and just delaying the actual recording (delay the audio in the same amount) giving the computer time to think avoids drop outs. Also you don’t want monitoring if you can avoid it. I don’t know if you are using a mic or what.

Hopefully some of this made sense.

A degenerate case that has probably no utility but that i post for fun.

The [block~ 32 2] (reblocked down overlapped twice)???

block.32.2.pd

Notice that here the letters represents 16 samples (64/4). And since it is always complete at each tick just one of them is required. The result is strange. Each DSP vector is sliced in four pieces, and combined. Is it normal. I don't know? But it can be awesome! For what?

TBH I did that kind of thing only to be sure that i didn't make an error while refactoring Pure Data.

[a b c d]  !  [A B - -]
              [- C D -]
              [- - A B]
              [D - - C]

-->       [A+D B+C A+D B+C]

// [block~ 32 2]

BLOCK FREQUENCY+4
BLOCK PERIOD+1
INLET SIZE+64
INLET WRITE+64
INLET HOP+64
OUTLET SIZE+64
OUTLET HOP+16

#+0#

P+0/+64

R+0/+32
W+0/+32
R+32/+32
W+16/+32
R+0/+32
W+32/+32
R+32/+32
W+48/+32

E+0/+64

#+1#

...

Basic upsampling and downsampling is obvious also. The up/down sampling is done before/after (the prologue/epilogue) in anothers buffers. The DSP computation is performed in one shot with the required block size.

// [block~ 32 1 0.5]

BLOCK FREQUENCY+1
BLOCK PERIOD+1
INLET SIZE+32       // Downsampling is done before.
INLET WRITE+32
INLET HOP+32
OUTLET SIZE+32      // Upsampling is done after.
OUTLET HOP+32

#+0#

P+0/+32             // Read 32 samples already downsampled from 64.

R+0/+32
W+0/+32

E+0/+32             // Write 32 samples that will be upsampled to 64.

#+1#

P+0/+32

R+0/+32
W+0/+32

E+0/+32

// [block~ 128 1 2]

BLOCK FREQUENCY+1
BLOCK PERIOD+1
INLET SIZE+128      // Upsampling is done before.
INLET WRITE+128
INLET HOP+128
OUTLET SIZE+128     // Downsampling is done after.
OUTLET HOP+128

#+0#

P+0/+128

R+0/+128
W+0/+128

E+0/+128

#+1#

P+0/+128        // Read 128 samples already upsampled from 64.

R+0/+128
W+0/+128

E+0/+128        // Write 128 samples that will be downsampled to 64.

For reblocked down (e.g. [block~32]) it is rather easy.

At each DSP tick the parent's vector (64 samples) is simply processed right away piece by piece.

// [block~ 32]

BLOCK FREQUENCY+2
BLOCK PERIOD+1
INLET SIZE+64
INLET WRITE+64
INLETHOP+64
OUTLET SIZE+64
OUTLET HOP+32

#+0#

P+0/+64     // Prologue: write 64 samples in the buffer in.

R+0/+32     // Proceed first half part (32 samples).
W+0/+32
R+32/+32    // Proceed secondth half part (32 samples).
W+32/+32

E+0/+64     // Epilogue: read 64 samples from the buffer out.

#+1#

P+0/+64

R+0/+32
W+0/+32
R+32/+32
W+32/+32

E+0/+64

@jameslo yes, @ddw_music was correct. It's a combination of double and single precision (and I edited my last comment, this prediction is consistent w/ the 1st patch at least). The value "conv" in the source code is stored in a t_float, which is generally a 32-bit float these days (though maybe that will change soon..). This is set to 1/samplerate. every sample conv is multiplied by the input frequency (which is also a 32-bit float) and then added as a double to the current phase, which is a double with value 1572864 + actual phase, (1572864 is 3^19, a float value that makes bit 32 of the entire 64-bit double value the 1s place, leaving the remaining 32 bits as the fractional part). Every sample the top 32 bits of the phase are set to the top 32 bits of 1572864, and when the phase is output, 1572864 is subtracted from it.

tldr: the phase accumulator is basically 32-bit fixed-point

@liamorourke Yes, probably best to start simple.
Here is an example using "graph on parent"...... GOP.
cart.pd

The patch itself will only work in extended. Many objects will be missing.... but that is not important.
Right click the window with the controls and click open and you will see what is inside.
The window is actually a sub-patch called [pd guts]

Once it is open you can right click anywhere on its background and a properties window can be opened.
The properties control the GOP..... whether its name is shown........ whether the GOP is active...... the size and the position of the GOP window in the sub-patch (the red box).
The size is reflected in the mother patch [cart] but the position is the position of the window through which you are looking into [pd guts]
"size" is obvious. "margin" sets the position of the box relative to the top left of the window.
Nothing outside that window is shown through the GOP, and no connections are shown even within the window.
David.

@cfry Those sorts of sounds can be gotten as well and a more sensitive mic will pick them up. The problem you are having is the mic is just getting noise, everything of the same volume, so nothing distinct for [sigmund~] to pick out, remember all those discrete sources add together. By wind noise I meant the sound of wind hitting a microphone directly, this creates a constant sound which will over power all those other sounds, not the sound of wind rustling the leaves in a tree. A good wind screen will be very helpful for you here, but you need to remember, a windscreen does reduce mic sensitivity, so there is a trade off, increase mic sensitivity and the more wind noise it picks up, put on a denser wind screen and you loose some of that sensitivity. A pop screen could work better since it can be placed between the wind and the mic, the other sides of the mic are left open, but if the wind shifts you could end up with wind noise overpowering everything and have to reposition the screen. If you limit yourself to days with nothing more than light winds, you should be able to get by with just a light windscreen and not suffer much loss in sensitivity.

My knowledge of windscreens and pop screens and the like is fairly limited and largely theoretical, I have little hands on use of these things as I mostly record in more controlled environments or in situations where I have more leeway than your needs allow. Seeking out people or sites dedicated to making field recordings would likely be your best path on finding a good mic/pre setup for your needs.

@whale-av, here is a log running pd with -lib Gem -verbose.
tried both 32bit and 64bit pd 0.48-1...

tried ./Gem.m_i386 and failed
tried ./Gem.dll and failed
tried ./Gem/Gem.m_i386 and failed
tried ./Gem/Gem.dll and failed
tried ./Gem.pd and failed
tried ./Gem.pat and failed
tried ./Gem/Gem.pd and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.dll and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.dll and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.pd and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.pat and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.pd and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.dll and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.dll and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.pd and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.pat and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.pd and failed
tried C:/Program Files/Common Files/Pd/Gem.m_i386 and failed
tried C:/Program Files/Common Files/Pd/Gem.dll and failed
tried C:/Program Files/Common Files/Pd/Gem/Gem.m_i386 and failed
tried C:/Program Files/Common Files/Pd/Gem/Gem.dll and failed
tried C:/Program Files/Common Files/Pd/Gem.pd and failed
tried C:/Program Files/Common Files/Pd/Gem.pat and failed
tried C:/Program Files/Common Files/Pd/Gem/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem.dll and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.dll and succeeded
D:\\pd-0.48-1.windows.64bit\\extra\\Gem\\Gem.dll: couldn't load
tried D:/pd-0.48-1.windows.64bit/extra/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem.pat and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.dll and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.dll and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.pat and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.pd and failed
Gem: can't load library```

i am not sure if it is the best solution, but it works now (with setFromPixels) it is a variable framebuffer and the example buffers the last 300 frames from a video.

frameTable300.pd

;
if type(window) ~= "userdata" then;
window = ofWindow();
end;
;
local canvas = pdCanvas(this);
local clock = pdClock(this, "setup");
local videoPlayer = ofVideoPlayer();
local outputList = {};
local frames = {};
local images = {};
local N = 300;
for i = 1, N do;
images[i] = ofImage();
end;
;
function ofelia.new();
ofWindow.addListener("setup", this);
ofWindow.addListener("update", this);
ofWindow.addListener("draw", this);
ofWindow.addListener("exit", this);
window:setPosition(50, 100);
window:setSize(800 + 40, 600 + 40);
if type(window) ~= "userdata" then;
window = ofWindow();
end;
;
window:create();
if ofWindow.exists then;
clock:delay(0);
end;
end;
;
function ofelia.free();
window:destroy();
ofWindow.removeListener("setup", this);
ofWindow.removeListener("update", this);
ofWindow.removeListener("draw", this);
ofWindow.removeListener("exit", this);
end;
;
function ofelia.setup();
ofSetWindowTitle("Video Player");
ofBackground(0, 0, 0, 255);
end;
;
function ofelia.moviefile(path);
videoPlayer:load(path);
videoPlayer:setLoopState(OF_LOOP_NORMAL);
videoPlayer:setPaused(true);
end;
;
function ofelia.setSpeed(f);
videoPlayer:setSpeed(f / 100);
end;
;
function ofelia.play();
videoPlayer:play();
end;
;
function ofelia.stop();
videoPlayer:setFrame(0);
videoPlayer:setPaused(true);
end;
;
function ofelia.setPaused(f);
if f == 1 then pause = true;
else pause = false;
end;
videoPlayer:setPaused(pause);
end;
;
function ofelia.setFrame(f);
videoPlayer:setFrame(f);
end;
;
function ofelia.setPosition(f);
videoPlayer:setPosition(f);
end;
;
function ofelia.setVolume(f);
videoPlayer:setVolume(f / 100);
end;
;
local number = 0;
function ofelia.update();
videoPlayer:update();
if videoPlayer:isFrameNew() then;
number = (number + 1) % N;
print(number + 1);
images[number + 1]:setFromPixels(videoPlayer:getPixels());
table.insert(frames, 1, images[number + 1]);
if #frames > N then;
table.remove(frames);
end;
end;
outputList[1] = videoPlayer:getPosition();
outputList[2] = videoPlayer:getCurrentFrame();
outputList[3] = videoPlayer:getTotalNumFrames();
return outputList;
end;
;
function ofelia.draw();
videoPlayer:draw(420, 20, 400, 600);
if #frames == N then;
frames[ofelia.frame]:draw(20, 20, 400, 600);
end;
end;
;
function ofelia.exit();
videoPlayer:close();
for i = 1, N do;
images[i]:clear();
end;
end;
;