Ive heard of people loading they're own dsp code onto Analog Devices chips,kind of like a homemade non-patchable nord micromod kind of thing. but I thought it would be amazing be able to run a realtime puredata or max type environment from hardware dsp chips. with just a few chips, if it could be realtime and computer interfaced, it would be insanely powerful compared to a nord modular.

PDa; http://gige.xdv.org/pda/.

This is a version of PD that can be used on any Linux Embedded ARM processor. Seems to be the best option right now.

The gluiph was DSP-based and ran Pd:

http://citeseer.ist.psu.edu/579012.html

http://www.glui.de/old/prod/gluiph/gluiphSensors.html

hmm, so did that require you to rewrite objects to run from the dsps?

My distant idea, is to figure out how to write an external pd library that would run off an adi dsp card, sort of a uad1 for pd. (lots of acronyms, I know)

@randal said:

hmm, so did that require you to rewrite objects to run from the dsps?

My distant idea, is to figure out how to write an external pd library that would run off an adi dsp card, sort of a uad1 for pd. (lots of acronyms, I know)

So the SHARC would be doing the DSP on the system, great idea. SHARC is it's own architecture, has it's own development environment (C++ based?), and compiler. It seems like a tough job. Blackfin, however, seem to be able to run linux... making things a little easier.

I don't really know much about processor architecture, but it seems there are some premade PCI (daughter cards?) options available. With the proper driver/module, couldn't one just offload a portion of the PD's Processes to the sharc?

The option which I think I could easily handle is: An embedded soc (or even better, ITX) with adat/spidf optical i/o runs a gui-less version of PD (jack-rack, whatever). Patches are managed with ssh or x-forwarding from a client "remote control" (iPhone, shitty laptop, whatever) which is also a remote for a video machine. Patches are controlled via OSC, with interesting HIDs. For live stuff, you could get an onyx or similar board with A/D and go nuts.

heavy stuff!

according to my dad, who knows a bit about some of this, a dsp card could be used as a coprocessor without altering pd itself as long as pd used a library of externals for whatever needs processing (like fft or whatever) where the objects are basically just directing work to new code written for the chip, so it would require a class of objects that are essentially wrappers for whatever code the chip requires. seems feasable...

Good topic.

Just as an anecdote, I have had a Creamware Pulsar (with 4 x SHARC DSP) in my junk box for years. I got it as a primary studio sound card about 10 years ago while using Windows. Then they didn't bring out any XP drivers for it that worked, and after that I switched to Linux so it became so much expensive junk. Creamwares support has certainly been wanting, like so many proprietry h/w manufacturers, which is a shame because it was an awesome system.

I recently checked it out again to see if they had managed to write a Linux driver in 10 years. I found several rumours of one on old mailing list messages but nothing actually useful. Then someone told me there was a SDK, but it cost thousand$, so I kinda gave up on dedicated DSP boards after that.