Shared buffers for Flexi

I would like to have the option for Flexi modules to share the same audio buffer, so I could record something in one and have others playing it back in different ways, without having to drag and drop it across all of them. This builds a bit on a previous request I had for continuous recording in Flexis.


  • Can you please describe a use case using that feature?

  • I

    That doesn’t sound very practical. Of course you know you can have a single flexi feeding multiple tracks with different fx. If you want different pitch or speed then just load the same sample in different flexiis?

  • You don't even need to do that. Flexi fully supports polyphony and polyphonic modulations so you can play the same sample up to 16 times with individual start points, pitches, velocities or scratch the sample 16 times independently, using the Many To Poly module.

  • edited June 2

    Wait that doesn't seem to be working for me I don't seem to be getting plays from 2 positions. Edit scratch that I just don't see two play heads but they are both playing.

  • edited June 2

    @rs2000 yes, I’m aware that many things can be achieved with polyphony (that’s how I implemented this:, but if I want Flexis with different settings (slices and loopong) then it doesn’t work. My use cases are mostly related to duplicating certain hardware boxes:

    • Octatrack, which provides eight recording buffers, all of which can be played back by multiple tracks
    • Weird loopers/delays like the Cocoquantus, the Norns script called “mlre”, or Chase Bliss Thermae, reading from the same buffer with wildly different settings
    • Chase Bliss Habit, reading from parts of a buffer as a delay and other parts as the “surprise from the past”

    The last two would admittedly require Flexis to implement both looping and some sort of infinite mode (like SpaceCraft’s), and I would definitely prefer those two functionalities to be implemented before this wacky shared buffers thing ;)

    @pedro I currently do drag and drop a single clip to multiple Flexis, but it’s not that convenient for live use, more so because Flexis stop looping when you load a new clip.

    Thanks for chiming in though! I do get that this may be a bit “out there” and I certainly wouldn’t want to push for something that only interests me; your feedback does help to assess if that’s the case.

  • edited June 3

    @NoiseFloored Your suggestion is in line with the plan to introduce a sample type signal that would allow different Flexis to draw their wave data from a sample pool and do independent processing and playback.

    I would consider it unlikely to happen in the near future though, as it's more of a long-term conceptual change.

    ... because Flexis stop looping when you load a new clip.

    I agree that this one alone should be fixed as soon as possible!

  • @rs2000 thanks for that insight into future plans! Do you think that infinite Flexi or Flexi looper is likely to happen sooner? In any case, this is mostly my curiosity about what's possible and the future direction of the app's development rather than an actual musical need. I enjoy experimenting as much as I do actually producing something resembling music ;)

  • @NoiseFloored I've stumbled over my own wish for an advanced buffer/looper module a few times in the past.

    Let's design one!

    There will be a number of design decisions to make, like repeated forward/backward buffer readouts with speed control, polyphony and polyphonic modulation, realtime buffer filling with optional looped overwrite, how to determine the buffer length etc.

    If the concept is good enough, chances are that @giku will grab the challenge and build it 😉

    All comments are welcome!

  • @rs2000 I really appreciate your message; some of the considerations you mention I had already thought about, but others I hadn't. My idea is basically the existing Flexi with an Overdub button, a Loop Decay (or Overdub Feedback) knob and a Length knob in the Recording panel which work the same as they do in Bram Bos' Gauss. I wouldn't change anything about playback, including all polyphonic behavior. I'll mock something up during the weekend, create a new topic and tag you in it if that's OK.

  • this is very interesting. the one piece of gear i know that does that is the er-301 sound computer eurorack module by orthogonal devices, i use this feature a lot because you can there put a looper that records the input and stores into a buffer in realtime, then you can read that buffer with multiple different players (regular samplers, granular samplers etc...) and build very complex quasi-realtime audio manipulation layers.

    in fact Drambo instantly reminded me of the er-301 because of modularity and super clever interface, the big difference is that Drambo brings sequencing goodness and modularity on the table, which the 301 does not (you can build your own of course).

    anyway having shared buffers is a great idea imho. one issue that is still to be solved in the 301 environment is clicks when the recording head and one or more playheads intersects, it was on the 301 development roadmap but now it looks like the developer dropped the project (or put it to sleep). there were many useful threads on the 301 forum but that is down too now, unfortunately.

  • Welcome @hyena_innerscapes ! :)

    anyway having shared buffers is a great idea imho. one issue that is still to be solved in the 301 environment is clicks when the recording head and one or more playheads intersects, ...

    That's one of the very reasons why there is no "perfect" buffer module yet. Not sure if this can be solved at all without the typical side effects of crossfading - there may be multiple layers in recording so there's always a stored and live-recorded buffer that can be accessed independently, but there should be a means to get rid of clicks in a one-buffer setup as well.

  • thank you! very glad to be here, i discovered Drambo only this last week and i'm totally amazed by the goodness of it all!

  • thank you again!

Sign In or Register to comment.