Introducing Digitakt II

as soon as I typed the question I suspected that might be the case! but thanks for confirming. Nice work and thanks for uploading

1 Like

DT2: This is another techno track, based on loops with werp - tuning is modulated by square LFO which is modulated by square LFO :smiley:
(And heavy use of the NOT trig condition - that alone would be worth the upgrade to me :smiley::star_struck::partying_face:)

HD (set video quality to 1080):

9 Likes

Still gotta wrap my head around what the NOT condition is :slight_smile:

2 Likes

NOT (/A:B) trig condition: It misses/leaves out/skips the trig at any nth repetition of the pattern.

That missing beat once in a while is IMHO a very important feature of many classic Detroit techno tracks (metroplex, axis, tresor) - cannot cite one LOL, maybe just altered memory. But I love it. And now it is so easy to programm. Also a shift of the beat (like just every 5th repetition or so) is easy now: e.g. one NOT trig 4:5 con followed by a trig with 4:5 condition. (ā€œSkipped heart beatā€ gives me the chills :smiley: ) The unpredictability is what makes (made) this so great in the club or even on the couch :smiley:

10 Likes

Can we play up to 128 preset slots with external midi in Preset Pool mode ? :loopy:

I don’t understand clearly midi presets.

It is not possible to load a MIDI preset to the preset pool

?
Can we play them with external midi in Preset Pool trig mode ?

2 Likes

Mmmm, given that we can transfer samples that are >66s in length, the limitation definitely isn’t in the playback buffer size.

If there is a recording buffer limitation due to hardware constraints, it would be a RAM buffer issue I would imagine - but this all depends on how they are handling the recording.

There is 640KB L1 Cache (ultra fast SRAM), 1024KB L2 Cache (little slower SRAM but with Error Correction Code protection), and 512MB of DDR3L memory, of which 400MB is allowed for already-stored samples (RAM pool). I can’t see what ADCs or DACs are being used from the images provided, but we can assume they communicate to the SHARC SoC using some sort of serial interface.

This SoC also includes 2x Digital Audio Interfaces (DAI), which includes RAM FIFO buffers, SPORT interfaces, Asynchronous Sample Rate Converters (ASRCs), and most importantly connects to the system crossbar memory interface. It is difficult to guess more about the signal chain from input to memory without having a device in-hand or having some idea of how they are using this SoC / what interfaces they are using.

I drew some possible basic data paths. We know that these samples are 16-bit 48kHz stereo, so we can assume roughly (16 bits) * (48kHz) * (2) = 1.536Mbps == 192KBps data stream exists for a stereo sample. This could be actually sampled in at a higher rate by an ADC IC and downsampled to 48kHz in the DSP; I don’t really know, let’s just assume it isn’t.

The memory architecture, in combination with its separate on-chip buses, allows two data transfers from the core and one from the direct memory access (DMA) engine in a single cycle. Let’s just assume we receive our sampled data stream by something like I2S, it exists in a RAM FIFO and then transferred to DDR3L using DMA.

This maximum sample length @ 192KBps is only 3.33s in the L1 cache and 5.33s in L2 cache, so not likely it is being stored in either place for long, if at all.

66s of this 192KBps data stream is 12.672MB. If we assume the remaining 512MB - 400MB = 112MB of DDR3L RAM is used partially for live program data and partially for live recording intermediate storage, we can assume 100MB is required by the system to run: this leaves us with 12MB, which is suspiciously close to our above number of ~12.672MB.

Lot of assumptions here, but if they can optimize and reduce their live program RAM usage this would probably lead to increased live recording length limit.

** EDIT: Thanks to hautpocket for pointing out it is 48kHz, not 44.1kHz :slight_smile: **

5 Likes

Could see this also being used for a pseudo mute automation for the end of a 16 bar hip hop punch line to come through. Neat stuff. Hope mine arrives next week.

1 Like

I thought it was sampling at 48khz?

1 Like

Ah, so 8 minute recording lengths are unlikely then?

1 Like

that’s an Empress Echosystem

Wasn’t it 24 bit 48 kHz?

1 Like

Definitely not 8min, as that is 92.16MB.

I could see it increasing to 100s maybe if this is actually the reason for limitation. I’m sure Elektron has squeezed out a lot of the optimization already, but there is always hope for more :slight_smile:

Again, this is all just speculation with a lot of assumptions on how they are using this SoC given what we know, so definitely take with grain of salt

1 Like

The ADCs sampling the data in and the DACs interpreting the data to drive outputs are 24-bit, yes. In this case, the data streamed in is normalized and decimated I believe before it is stored. Depending on the ADC used, this could be done at the ADC or this ADC transfers (24 bits) * (48kHz) * 2 = 2.304Mbps == 288KBps data stream. It is unlikely that this is written to the RAM as 24-bits, though; the decimation would almost certainly happen before this.

Decimation can be done by the IIR or FIR filters on the SoC too, technically a form of low pass filtering.

3 Likes

Very nice to have you here :smiley:

3 Likes

You don’t have to use a continuous, pre-reserved chunk of memory for recording a single stereo signal, that’s just how they chose to do it for now. No problem using all free memory as a recording buffer, if they want to. Or even recording many hours to flash, if they want to. It’s just not in the profile of this device. OT III would do it.

2 Likes

I love that you took the time to dive into this! Great community here. Ok, so you have a fairly high degree of confidence that this ram architecture precludes any other mechanism of capturing audio of a 5-10 minute+ length as in the octatrack?

1 Like

Haha glad to be around, embedded stuff is fun :slight_smile:

@Selvi above is correct too. If they wanted to get wild with how they are managing memory, they have a lot of playground room here and definitely don’t need to restrict to single chunk of space. Only limitations are how the devices are pinned out on the board, but the SoC is an incredible platform if they have left these options open as far as what can route to what, there are loads of options on how to process the and store the data with a snappy 1GHz core clock and DMA. Depends on what they are using the rest of the SoC and memory interfaces for simultaneously too.

Perhaps they could go to 12 bit or 8 bit recording for longer recording time? Or just mono.

1 Like

Former developer here. It’s a design choice, because of the intended profile of the device, not a technical limitation of the hardware. Not in 2024.

2 Likes

Is this like, 1985?

Hearing the A/B examples earlier made me sad, because I like one much more than the other, from the flair or general mood the sound gives me, and I guess I know which one this is.

You win some, you lose some…

3 Likes