still considering my options when it comes to how to send MIDI to this Blackfin DSP board i received from a visiting friend today. Analog Devices offers a USB stack, but it doesn't implement the MIDI device class. it's somewhat more tempting to use the MIDI ports on my Focusrite interface, because it's much easier to get basic serial communication working.

Follow

@lore Depending on the model, it should support Ethernet which can be used for MIDI. It should allow for newer features with that communication speed. Good old UART should be acceptable. An Arduino UNO can handle MIDI to USB.

It might be a good idea to use a Microcontroller board or SBC to interface with the DSP. This would allow for the DSP to be free for DSP functionally. It could also allow a little more control over the DSP without having to get more than a laptop and a cable. A Raspberry Pi could have GCC ready to compile and upload new code. A few scripts could make it reconfigurable with a button press.

Offloading MIDI and other things to an SBC would allow for easier programming and some really cool features while the DSP pipelines are free for pure synthesis. If I recall correctly it is SIMD so keeping only the needed instructions would allow for a respectable level of performance. Digital Signals in, Blending and Digital Signals out to the SBC or MCU to be converted.

@AmpBenzScientist well, something has to tell the DSP what to synthesise. that's why i cut it down to just accepting control messages (MIDI) and synthesising things. another chip will be the application controller. if you cut it down to just virtual control voltage type signals and found a way of placing those in the DSPs memory then i suppose the MIDI could be dropped.

@AmpBenzScientist i probably should've prefaced that statement with: "we're already doing that, but" and "for the moment, i haven't got this thing interfaced that way but still need a way of testing and controlling it" - we're not co-located so we sort of have to do these things semi-remotely, since we don't meet every day

@AmpBenzScientist i haven't examined exactly what this chip supports in terms of transferring data that isn't audio to or from the codec, which happens via DMA. the experience of programming this thing feels more like a uC with DSP features than programming a pure DSP that can only do stuff like MAC and pseudo-branch instructions.

@lore Newer DSPs get very weird very quickly.

Texas Instruments has some interesting DSPs and then there's Qualcomm.

en.wikipedia.org/wiki/Qualcomm
Yes it uses RISC instructions along with VLIW instructions with 4 way multi threading. It's not AMD's GPU TeraScale 3 VLIW4 but it kinda looks like it.

Direct from the Wiki entry above.

"{ R17:16 = MEMD(R0++M1)
MEMD(R6++M1) = R25:24
R20 = CMPY(R20, R8):<<1:rnd:sat
R11:10 = VADDH(R11:10, R13:12)
}:endloop0

This packet is claimed by Qualcomm to be equal to 29 classic RISC operations; it includes vector add (4x 16-bit), complex multiply operation and hardware loop support. All instructions of the packet are done in the same cycle."

It's from a FFT.
Doesn't it look superior to 29 instructions? What you get Engineers to write after a compiler can't get it right.

@lore Ah yes, development stages. Nice drawing of the final design and a desk full of parts wired together. Why does that sound so familiar? Oh I forgot the all the datasheets.

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.