possibility of aleph as sample playback machine

  • long time lurker, first post, after buying a new 128 and a white whale, which are great

    quick question about the hardware capabilities of the aleph:

    does it have enough onboard memory and processing horsepower to work as a sample player?

    i'm imagining loading banks of 4 short samples at a time - say drum hits - from the sd card, and triggering them via incoming gates to the cv ins, with the 4 encoders and switches mapped to do something useful, hopefully granularish

    from reading various posts here it seems doable, though there's undoubtedly plenty of coding involved, but wondering if the powers that be have an opinion on the feasibility of such a project

    (i've got c chops btw, but no dsp experience. i don't have an aleph as yet, though i've got some feelers out. the australian micro-dollar doesn't help...)

  • Woooah, i cannot answer your question, but this could make me keep my Aleph.
    Must be doable !

  • and here's me about to hit you up for possible trades for your aleph.

    i've gone and shot my own foot.

    anyway, let's see if we get any response to my question.

  • this is possible, but will require some serious backend development. getting audio data into the DSP via SPI (from the AVR32, which talks to the SDCARD) isn't implemented. AVR32 audio file reading isn't implemented. with these two in place, plus a bunch more glue, certainly you could do this. but, this is not a trivial matter.

  • thanks for answering.

  • there is an embryo thanks to tremendous help from Ezra answering my many questions, and explaining things in general.

    https://github.com/electropourlaction/aleph/tree/dev (tag "0.0.7 sampling")

    the current limitations are speed (edit: 4kb per second) and the audio file reading mentioned is not implemented, it only support headerless pcm files at the moment. some improvements not uploaded; optimized callback delay, simple file and memory checking.

  • @tehn:

    thanks for weighing in.

    the situation is as i guessed - possible but hard.

    the real question then becomes, is it worth putting all that effort in? and the answer, as always, is yes and no.

    the no camp in my head says, why do this for a quixotic 100 unit device that may only have a limited future?

    the yes camp says, it would be incredible, and make these rarest of rare crystal unicorn tear devices even more lustable.

    for me it kind of hinges on the availability of a unit at a reasonable price, which isn't helped by the diminishing value of the australian nano-dollar.

    postscript - maybe the various tasks involved here have other applications (sdcard reading, spi data transmission, etc.) that mean they are worth doing anyway.

  • I would have thought it'd be easier to do all this in max, using the aleph to supply the triggers/gates/CV from whatever other device you're using to generate that. Not that I'm dissing the aleph, which looks fascinating.

  • certainly, but I'm specifically trying to avoid using a computer, or more specifically, a big glowing screen.

  • just get a Volca Sample, I say: sync it to the aleph via cv, run lines as your granular delay and you mostly have what op describes

  • if your final goal is to simply trigger samples, the aleph may be overkill.

    if you're looking for an open-source sound platform that is fully standalone, and you have ideas that can't be implemented on other hardware, the aleph is an exceptional choice.

  • @analogue01 i was under the impression that samples cant be recorded live (directly to the volca)

    that's a deal breaker for me

  • @gli it can't, no. but op was imaging playing pre-loaded short drum hits, so it works for that scenario

  • "you have ideas that can't be implemented on other hardware"

    This is a bold claim... I'm intrigued.

  • i'm still personally pushing for that @strettara

    if not impossible elsewhere more convenient & dynamic/flexible


    @analogue01 true...missed that part

  • posting a question here from another thread, I don't know if this is the best way to do this but I have found no other way so far...
    somewhere in the code comments there is mentioned something about the callback speed for parameter changes, that number of changes should not be more than 1 per process frame, probably so that parameter changes does not cause drop outs or something... samples could be loaded during app startup and it works best if audio processing is turned off when this is happening, at least according to my tests, so would it be possible to temporary change/speed up the callback master clock!? I'm already setting the callback polling rate to 1 during sample transfer (it does not appear to take values less than that) but I wonder if whatever clock that is driving this process could be set temporarily to a faster rate, or is 4kb per second the maximum transfer speed over spi already possible?! not overflowing the spi event buffer would also be a concern... sorry for hijacking this thread with this question, but it relates somewhat to the issue of possibilities with sample playback from a user perspective in the end!

  • @tehn

    "if your final goal is to simply trigger samples, the aleph may be overkill"

    true, but i have a dislike for cheap plastic-y disposable feeling gadgets, and i'm drawn to the elegance and overall quality of the aleph, plus, of course, the aleph can do many other things

    i also wanted to do more than just trigger playback, e.g. glitch, stretch, granulate, reverse, etc.