Line6 Tonecore DSP

[wuschel]

DSP has a lot of specialized instructions that make it run audio DSP operations faster for a given clock:

- Branchless conditionals. Instead of needing a branching if() statement, you can use conditional moves, which take a single cycle. Used for level detection in compressors and the like, makes things way easier.
- Built in clipping operations, or saturating math. No if() needed for clamping things to desired bounds. Useful for cheaper polynomial waveshaping, where you need to clip within bounds.

Conditional moves and saturation are part of x86 for more than a decade now, BTW.

Carry on...

[quikquak]

Line6 have revealed some more details about the tonecore programmable pedals:
http://line6.com/tcddk/

The linked video on that page states it's a 100mips 24bit device, but I can't find any other details about the real speed or memory of it, or even the sample-rate. The guys says it can do a few seconds of delay, but then quickly moved on to show how great it is that a little shoe appears on the dev kit screen when you press the pedal!
Video from link:
http://www.sonicstate.com/news/shownews.cfm?newsid=6291

The big question for me is can it handle convolution?

The multi-coloured programmable LED is a nice touch though.

Dave H

[valhallasound]

Conditional moves and saturation are part of x86 for more than a decade now, BTW.

Really? Which instructions? I have to admit I haven't gone as far into x86 as I would like - been stuck in the embedded world. Are they part of the main x86 instruction set, or SSE?

The paradox is that, when I program for PC/Mac, I tend to avoid using ANY assembly language. The reason? I would hope that, someday, the source code would be portable to another platform by someone else.

Assembly on an embedded device, and generic C code on a PC/Mac, both stem from the same source for me: THE FEAR OF DEATH.

The embedded device will survive, so the source code does not need to be public. And it wouldn't make much sense, anyway, as the chips will probably be gone. The PC/Mac platform will not survive, at least in its present form - it will evolve. So, generic source code is the best solution for long-term survival.

Probably the best compromise would be to get the code working as optimally as possible with generic code, then optimize with assembly, and keeping the original optimized C code in there via #ifdef and the like.

Sean Costello

[valhallasound]

The linked video on that page states it's a 100mips 24bit device, but I can't find any other details about the real speed or memory of it, or even the sample-rate.

The DSP is the DSP56364, with some other Freescale uController handling the user interface. 100 MHz, 1.5K x 24 bit Y-data RAM, 1K x 24 bit X-data RAM, 0.75K program RAM. You can switch around the RAM distribution a little bit, but that isn't much RAM at all, and my guess is that the on-DSP RAM is going to be the big bottleneck for development on this DSP.

http://www.freescale.com/webapp/sps/sit ... 0127958596

The Tonecore platform also has a 4Mbit RAM chip - I don't remember if it is SRAM or DRAM. The Echo Park pedal has 2.5 seconds of delay time, so I would guess that this is pretty typical for applications. This is plenty for FDN and allpass loop reverbs, but not enough for good audio looping.

Sample rate is in the 44.1 kHz region, although it might be above or below that. Remember that guitars don't generate a lot of high frequency harmonics, and the typical guitar speaker is a big woofer, so there is no need to have a super high sampling rate.

The big question for me is can it handle convolution?

Short FIR convolution? No problem. Ovelap-and-add frequency domain convolution for reverbs? I would highly doubt it. There just isn't enough memory on board. I am unsure if the part can handle larger FFTs, although the Electro-Harmonix HOG and POG series use this DSP, and they sure sound like frequency domain pitch shifting.

The biggest limitation, for me, won't be on the algorithm side, but rather the interface side. Only 6 knobs, and 2 little switches. I consider this a cool challenge, but it will probably be really frustrating as well. I have worked with the Spin Semi FV-1 before, which only has 3 knob inputs, but that part is limited in CPU power as well, so developing for the FV-1 is an exercise in how creative you can get within the limitations. The Tonecore platform should be far more open ended, so the limitations will take more time to run into, and probably be harder to work around.

Sean Costello

[quikquak]

Thanks for hunting down the info Sean.
If Echo Park has 2.5s delay time, and advertises as a stereo effect, then there must me a fair amount of RAM in there?
Hopefully there will be different types of module configurations, so effects can be made to look less generic, but it's always going to be a simple array of controls.

Dave

[wuschel]

Conditional moves and saturation are part of x86 for more than a decade now, BTW.

Really? Which instructions? I have to admit I haven't gone as far into x86 as I would like - been stuck in the embedded world. Are they part of the main x86 instruction set, or SSE?

The conditional move instruction is conveniently named "CMOV", first introduced with the P6 back in 1996, if memory serves. (if one does not count CMPXCHG, which was first implemented on the 486...)

Saturation has been with us since the advent of MMX:

PADDSB, PADDSW, PADDUSB, PADDUSW, PSUBSB, PSUBSW, PSUBUSB, PSUBUSW, PACKUSWB, PACKSSWB, PACKSSDW

Even more with SSE2.

[Malcolm G]

This greatly appeals to the geek in me, so no doubt I'll end up with one at some stage.

re: all this talk about it being a toy, what's wrong with toys? I like toys, especially ones that have an SDK

[hibrasil]

Does anyone have one yet? I'm interested in getting one but i'd like to get an idea of how hard they are to program first. It would be useful if someone could post the example code when it is available.

oli

[quikquak]

The modules seem to have a few reliability problems:

http://reviews.harmony-central.com/revi ... +Park/10/1

I'm wondering if the little black plastic 'modules' can cope.
It's OK at home, but on a gig, they'll be slung in a box, thrown in a van, then chucked at the floor. The pedal itself is sturdy enough though, so yeah, if anybody has one then please let us know what you think of them.

[Edward_AudioDSP]

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.

They seem to be shipping now...
You can also download the software from the line 6 website (including sample code): Download link (http://line6.com/software/index.html?set_form=&submit_form=set&submit_query.x=28&submit_query.y=16&submit_query=submit&hardware=ToneCore+DSP+Tools&name=All&os=All)

[valhallasound]

For some perverse reason, I was reading my oldest posts at KVR, and this thread came up.

Does anyone know if the Line 6 Tonecore is still a viable platform for 3rd party DSP developers? I haven't paid much attention to it for the last 4 years. I ended up deciding that VSTs and AUs weren't such a bad idea after all.

Sean Costello

[Stupid American Pig]

Its scary how quickly 4 years can pass. I remember wondering about these myself 4 years ago.

[Crandles]

I had an idea for a pitch shifting effect using the pedal but I'm not sure if it has the resources or not to be able to do it fully. The core of the effect would be done with the PSOLA using YIN for tracking the fundamental frequency. After looking through the paper on YIN it seems like it might be computationally expensive from all the mathematics involved. I've often seen it referred to as a real-time pitch tracker but I'm guessing that depends a lot on the system it's implemented on and I didn't want to do a whole bunch of work developing it if I wouldn't be able to fit it on the kit.