I received my Organelle M yesterday and already I’m back to being a computer developer rather than a musician… oh well.
So here’s my conundrum. One of my favorite materials to work with are live internet radio streams. I’m trying to use [mp3amp~] from the pd-extended/unauthorized external. However, it crashes as soon as DSP is flipped on.
So I went to try to recompile it from scratch. But then discovered that the Organelle does not have a package manager installed, so getting lmp3lame-dev installed required me to compile THAT from scratch. Which was actually painless.
But now I’m faced with trying to get mp3amp~ itself compiled, and I’m running into issues. And I don’t even know if it’s going to work. There are complexities in the Makefile that don’t really let me compile just the one external successfully; and to compile the entire thing requires that I have the speex lib available, which was a dependency nightmare (to compile that from scratch require Meson and Ninja).
Any advice or help would be greatly appreciated, I think that this external would be of general interest to many Organellistes. I was never very good at compiling things, as I never studied C and am from a generation spoilt by package managers.
I think I actually ran into this issue years ago when I first started working with the internet streams, and compromised by cobbling together a handful of OGG streams and using pdogg/oggamp~ instead.
Indeed, as consolation for today’s failures, ONE of the OGG streams I used in my original project still works (http://stream.xaok.org:8000/frs.ogg)
There’s a broader discussion to be had about why (the patented) mp3 stream has won out over open-source ogg; why radio stations are pulling their OGG streams (WFMU, for example); and why so many are moving to Mixcloud instead (which basically breaks a lot of what makes radio/internet radio so much fun).
I tried looking for the mp3cast~ external and had no luck tracking it down. I couldn’t find the source or anything either but I don’t know how much help I could be either since I have limited C skills too. If you could post some of your work, I’ll see if I can bang my head against the keyboard enough to be helpful tho. If you are thinking of going the oggamp route, C&G has compiled an external for the Organelle.
I am in fact already successfully using the pdogg/oggamp~ external as compiled by C&G, so no real issues there (except that it is fussy about disconnecting and reconnecting).
The mp3cast~ external is under the pd-extended/unauthorized directory of the same pd-extended collection. [as I note in another post I actually care about mp3AMP~, but I keep accidentally typing “mp3CAST~” and I’m trying to edit my posts… sorry!]
I assume this would be child’s play for anybody with any gcc/make skills whatsoever. Given the limitations of the stock Organelle w/r/t a package manager especially, cross-compiling on a different machine is probably indicated.
Oh! Also, be aware that I edited my posts because I keep mixing up mp3cast~ and mp3amp~: the one I care about is “amp”, the one that is a client for playing back mp3 streams . I don’t know if mp3cast~ (for publishing mp3 streams) works well or not, but it would of course be useful to know if it does.
I’m working on it! It’s pretty straightforward to use oggamp~ in itself, so I’m essentially just trying to figure out a good interface for it.
I’m thinking that one would just provide a simple text file with a list of ogg stream urls that would be shared across all slotted instances of the module. Each module could “tune” to one of these urls at a time.
The only thing that is posing a challenge, or is an open question at this time, is how to override what orac shows on the display, since there is no “string” or “symbol” data type (that I’m aware of) in orac’s configuration setup. I’ll do some experimenting, as I’m just becoming familiar with both orac and organelle’s API.
Ideally, I’d like to have some way to have a unique configuration of urls for each module instance, but that’s not really the focus of orac. It would be akin to shared sample kits, but for text files.
There is no data/string type that is readily available. If you check out a lot of the recent modules I have put out (OracLoops, Loopy, Samplekids, and Converb) they all pull a file path using an abstraction called soundshare.
You could probably have a random number generator choose to pull a random one into a textfile object and then tune it with a float object with a 0 to 1 boundary
Currently I’m using an “int” type and splitting out a text file that way. The display shows “Station 0” (for example), which also requires hard-coding a range that at least encompasses the number of url entries in the text file.
Using a float and some rounding, I could make it a bit more flexible. But if you’re already providing a hard-coded list of urls anyway, it doesn’t really make too much sense to fuss.
Ideally, I’d love to see a “symbol” or even “list” type for the orac module configuration.
In my PD ignorance the first thing I’d try in this case would be to put mp3amp~ in its own pd~ subprocess and try to run the instance with some flags especially the “compatibility” flag, but I’d also experiment with audio buffer etc…
The only way I’ve been able to stream mp3 into Pd is by using mplayer to open the stream and then connecting the output to Pd input using jack (audio server for connecting different audio apps). So the process is a little different from a default Organelle Pd patch, which doesn’t use jack (Pd is just connected right to the audio hardware).
You can override the default behavior by including a run.sh file in your patch folder, instead of a main.pd. When you start the patch from the Organelle, it will execute run.sh instead of starting Pd. Then in run.sh you can run the commands to open mplayer, start Pd and connect things up. Here is an example of run.sh that seemed to work:
In the patch radio.pd (also in the patch folder) you can do whatever with the stream using [r~ inL] and [r~ inR]. It was pretty fun proof of concept, but would be great to get it working in a more general sense, like globally selecting streaming audio as the audio input.
I did some debugging and it seems (for me) that mp3amp~ is crashing with a Segmentation Fault when it calls the external decode_header() function, which appears to be part of mpg123 (inside libmp3lame?).
My best guess (after looking at the current mpg123 source code) is that the struct used in that call is defined in mp3amp~ against an older version of mpg123, so decode_header is trying to write to invalid memory locations.
Next thing I would try would be to see if it is possible to install an older build of libmp3lame on the Organelle, or re-implement decode_header.
But of course there could be further problems down the line. This is all probably a dead end. But just wanted to share this here in case some brave person is looking for info in the future.
Further into the thread, somebody posts a version they compiled for a Pi 3. I tried it and it doesn’t work out of the box: a bunch of .so files are off by like, one number. I don’t understand much about .so files and linking, etc, but I tried and failed to compile it directly on the Organelle.
I’m a bit short on time at the moment, but next time I get a chance to try, I’ll update this thread. Perhaps somebody else will beat me to it and get it compiled for the Organelle??
It looks like the [ffplay~] was failing to compile because the version of ffmpeg in the Organelle M’s repo is quite old. I’m compiling the latest version to see if it goes… could be going for a while though, lol.
Keep your fingers crossed. Looks like a really powerful, long-term solution to many format playback tasks in Pd
