as soon as I typed the question I suspected that might be the case! but thanks for confirming. Nice work and thanks for uploading
DT2: This is another techno track, based on loops with werp - tuning is modulated by square LFO which is modulated by square LFO ![]()
(And heavy use of the NOT trig condition - that alone would be worth the upgrade to me ![]()
![]()
)
HD (set video quality to 1080):
Still gotta wrap my head around what the NOT condition is 
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
) The unpredictability is what makes (made) this so great in the club or even on the couch 
Can we play up to 128 preset slots with external midi in Preset Pool mode ? ![]()
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 ?
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
**
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.
I thought it was sampling at 48khz?
Ah, so 8 minute recording lengths are unlikely then?
thatās an Empress Echosystem
Wasnāt it 24 bit 48 kHz?
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 
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
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.
Very nice to have you here 
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.
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?
Haha glad to be around, embedded stuff is fun 
@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.
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.
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ā¦


