I’ve made a quick emulation of the Remco Sound FX Machine as an audio unit and standalone application for Macintosh. The original was quite an interesting toy based on a Texas Instruments noise chip used in Space Invaders. I’ve never owned this toy or seen this chip, so the emulation is really just guesswork based on reading the datasheet. The UI was designed by the estimable ghostfacter (ghostfactor?) Eric, and the icon for the .app was drawn by Kate Lindsay. All artwork is public domain, and the source code is open (new code is under a permissive license, JUCE is GPL, pdlib is BSD).
Here’s a video demo:
Here’s the compiled, ready-to-use standalone and audio unit
And, all the source code is on GitHub:
Recently, I’ve been looking a for quick ways to make audio effects and add them to my workflow. I’m a big fan of puredata for prototyping and quick editing, but it’s not too easy to use if you want to process audio coming from an AU or a track on an audio workstation. What I usually do is start up JACK, attach PD’s ins and outs to that, and then run the JACK AU in my sequencer. While this is okay, the problem is you have to perform the somewhat complicated set-up procedure each time you want to start working. It’s also very hard to run multiple pd-based effect or synths at once, as each needs its own output routing.
The answer to all these problems seems to be to try to fit PD more naturally into the audio workstation, probably in the form of a plug-in. There’s been some work on this, namely pd-vst, but that doesn’t seem to be maintained very well these days. A much more active project is Peter Brinkmann’s pdlib. Pdlib allows embedding pd into your own app, and seems to be focused on smartphone platforms like Android and iOS. However, its smart, fast and minimal API seems pretty useful for regular old PC, Mac, and Linux apps, too.
So, recently I’ve been using a combination of JUCE and pdlib as a quick development platform for plug-ins. If you have a puredata patch that you want to make into a plug-in, it should be pretty simple to edit the source code (all you should have to change is PD_characteristics.h, in addition to using the jucer UI editor to edit PluginEditor.h/cpp – no knowledge of c++ required). Right now I don’t support any MIDI, but it should be fine for midi-less effects and synths – I plan to get midi working in the future (if you want to try your hand, the source code is right there!)
The one problem with this system is that puredata uses a lot of global state, so you can’t have more than one copy of puredata in any process. While this is fine for standalone apps, it means that if you directly use pdlib in plug-ins, you can only have one instance loaded at any one time. This kinda sucks, as that was the main problem with my JACK-based set-up. So, I’ve made the plug-in launch a UI-less process to run PD in. There are problems with this approach, too – right now I’m using JUCE’s interprocess communication layer, which doesn’t really seem to be fast enough for this. Things like switching programs and expose will sometimes block execution and cause audio drop-outs. If anyone wants to help out by speeding up the interprocess communication stuff, that would be really cool! The relevant code is in PluginProcessor.cpp and PDSubprocess.cpp . Also, I’ve heard mutterings that there is some plan to remove the global state from PD – if anyone has any info on this, drop me a line!
The only reason the system is mac-only right now is because I don’t have regular access to any sort of linux or windows-based system. It should be as simple as building a project and hitting the compile button! If anyone has some time and a windows or linux machine please e-mail me and we can try to get a version working for your platform.
If you want to avoid global state, use $0 in your message names. E.g. for send and receive blocks: [s $0-freq], [r $0-freq].
The $0 is translated to a new number for every new instance of the patch.
hope that helps.
Hey! Thanks! Yes, it would be better practice to use $0 for all the message names in case you want multiple copies of the patch in the same instance of PD, which is something I always forget about and run into trouble with.
However, the “global state” I was talking about it is a different issue – PD itself has global state. This means that you can’t run multiple copies of PD from within the same process. In most “sane” cases you’d never want to do this, but when you are instantiating PD from a plug-in, it would be useful, because then the separate plug-ins don’t have to somehow coordinate in sharing one copy of PD.
A different – and more polished – approach (which I found out about after writing this article), is called Pandemonium. It’s available under a permissive license (woo!) at http://www.mazbox.com/pandemonium/. This is a “plug-in generator”, which takes a pd patch and creates an audio unit. Instead of having each audio unit have a separate copy of PD, they all share one and they interact with certain rules. There are unfortunately somewhat serious problems with this method – for one, any “plug-in generator” doesn’t allow rich custom plug-in UIs. But worse is the fact that PD doesn’t really have a clean way of running multiple patches independently, so the developer had to resort to some hacks. These hacks, while extremely clever, unfortunately don’t work with any non-dsp object that deals with time – i.e., metro, line, etc, if more than one patch is running as a plug-in at once.
The main problem (which is pretty severe) with the sub-process approach I introduced in this post is speed: currently it’s not really fast enough to pass audio across the process boundary in time. It’s using JUCE’s default interprocess communication layer, so maybe if someone switched it to use something more efficient it would be fast enough.
Hope this clarifies some of my concerns!
-Russell
I just found this machine in a box that said “Free” and I love it. Cool software!!! I’m
using the Remco in a Pop Art project….Cheers!
http://www.youtube.com/watch?v=A7SR3JOszV0
You wouldn’t happen to have the schematic for this toy, would you?
No, sorry! Most of the features all come from one chip, the TI sn76477. Pretty much every knob is probably just a pot with one end connected to ground, one to power, and the wiper to a pin on the chip. That’s an exaggeration of course, but the knobs correspond pretty closely to the pins as described in the datasheet: http://amigan.yatho.com/sn76477d.pdf
Where did you get the PDF file shown in the demo video? I’d like to get a copy that I can use alongside the program, as shown in the video.
Thanks.
I actually couldn’t find a pdf of it either! I was working from a flickr set here:
http://www.flickr.com/photos/siempre_la_luna/sets/72157622335732590/with/3909196776/
It’s of course copyrighted – my guess is my use of it in the video was fair use (educational!) :-).
Were you able to download the files at some point before they became restricted? If so, is there any way you can send them to me? Maybe as a zipped file?