Mutable Instruments alternatives in Reaktor\Blocks ?

ab459
ab459 Member Posts: 6 Sine
edited June 22 in Reaktor

Hi folks, did not follow to Reaktor news last year-two, maybe already exists some Mutable devices based modules in program ? Particularly interested in Mutable Rings. (Yes i know about Softube variant, but wondering in Reaktor too).

Tagged:
«1

Comments

  • Paule
    Paule BerlinMember Posts: 268 Saw

    Do you search the Reaktor User Library?

  • ab459
    ab459 Member Posts: 6 Sine

    Not yet, well, i meant mainly - something from official modules (assuming that usually the quality control of such products is higher lol).

    But, if no such, then ok, can check.

  • Paule
    Paule BerlinMember Posts: 268 Saw

    Can you build one?

  • ab459
    ab459 Member Posts: 6 Sine

    No, not sure. Sorry i meant already completed product.

    Well ok no matter, in any case main thing i wanted to make sure that i did not miss by chance already done modules for Reaktor.

    And perhaps, in some sense that's even good that we have different bases with different modules. Way less time to comparisons lol (more for music).

  • colB
    colB Member Posts: 241 Saw

    I've looked at that as an idea, but I really don't think it makes sense at all. For a few reasons...

    Part of 'the point' of Mutable modules is that they are each a little computer with controls designed so that they can be configured to perform multiple different tasks - hence the name 'mutable'. This is good in the context of Eurorack, because there is limited physical space in a rack, and limited amps available from the power supply, and each phyisical module costs a lot of money. So the idea of module that can do lots of different things - one at a time - is very attractive. And its worth the various compromises, like menu diving, limited control options, cramped control surfaces with tiny tiny trimpot knobs etc. etc.

    In the context of Reaktor, none of those benefits exist - we can create multiple instances at no extra financial cost, we are not space limited in our 'rack'. But the main thing is that there is no reason to have a compromised control set.

    e.g. MI Plaits has many different synthesis models the can be selected between, each being forced to use the same limited control surface. So it's powerful and versatile in the context of Eurorack. In Reaktor, it would be so much better to have each of those synthesis models as a separate Block, and the extra work to do so isn't really that much - it's mostly cut and paste to build up a unique front panel to bring all the parameters of the synthesis model to the user.

    Another issue is that MI modules are naturally limited by the cpu, memory, DACs etc, that are available at a suitable pricepoint. so e.g. something like clouds would be silly in Reaktor, Reaktor is capable of so much more in terms of features and sound quality for granular processing.

    There are also limitations in Reaktor that make some things more complex to achieve. The boundary between Primary and core is problematic for recording/storing audio, so real time sampling modules that use persistent buffers - like Beads, and maybe others (defnitely Morphagene, but that's off topic ;)) are impractical to implement in Reaktor.

    And then there's the fact that MI Eurorack blocks are small, usually with just knobs, switches and lights, while in Reaktor, we have extremely flexible GUI tools and mouse input, doesn't make sense not to make the best of what we've got, and let that guide the design and features of the module.

    And you can't self patch a Reaktor Block, so some of the patching techniques from hardware are not possible - another general reason not to make 'clones' (best example is not MI, but Makenoise Maths - most of the joy of that module is self patching, so if you built a clone in Reaktor it would be useless, because many of the things it's famous for would be impossible on the clone.

    There is another completely separate issue. One of the reasons that there are so many clones of MI modules, and digitals versions in platforms like VCV Rack etc. is that many of the modules are open source with few licencing restrictions. In platforms where c++ development is possible it is fairly easy for a competent programmer to port the code - they don't even need to fully analyse and understand all the details of the DSP, just modify the code interfaces, and compile. To 'port' to Reaktor, everything needs to be completely re-written, and because its a conversion between two completely different programming paradigms, all the code needs to be fully understood in every detail. This is as much work (or more) as scratch building a unique module to your own specifications, so given the other problems pointed out above, why bother.

    Much better is to use the MI code for ideas, and to learn some DSP tricks, then apply them to original work in Reaktor. That's exactly why Emilie made them open source - not so we could build clones.

    I looked through the Clouds code while working on a granular project, and I borrowed/converted some code for diffusion, but was ultimately unhappy with the sound, so did some research and wrote a diffuser that was better in the context of my build, but might not have been possible in clouds due to cpu limitations - not sure.

    I recently bought Beads for my Eurorack, and it's a great module, but there are things I don't like about it. If I was building an 'inspired by' Reaktor Block, I would definitely be changing things - what would be the point otherwise ;)

    Also, so far in my limited experience, good Reaktor stuff sounds better anyway. The really cool stuff in hardware modular is analogue. The digital stuff still has a way to go to catch up with the best vst plugins - maybe never will due to cpu/cost limitations.

  • ab459
    ab459 Member Posts: 6 Sine
    edited June 12

    @colB Hmm, ok got it. Thanks for some info. (Btw regards Clouds, I had similar feelings when trialed plug i.e. the sound\character quality it seemed is questionable. Although initially he was the main target.)

    There are also limitations in Reaktor that make some things more complex to achieve. The boundary between Primary and core is problematic for recording/storing audio, so real time sampling modules that use persistent buffers - like Beads, and maybe others (defnitely Morphagene, but that's off topic ;)) are impractical to implement in Reaktor.

    Damn that sounds sad. I love incoming audio tricks, was hoping for that lol

  • colB
    colB Member Posts: 241 Saw

    Damn that sounds sad. I love incoming audio tricks, was hoping for that lol

    More frustrating than sad. And I'm being maybe too negative, some stuff is possible technically in Reaktor - clouds probably is - Morhpagene definitely not.

    The problem is that There is an artificial limitation on the maximum size of an array in core which means that to get more than a few seconds of recording at high sample rates, you need to use awkward hacky workarounds that make development much more complicated and error prone.

    This might not even be a problem if the table framework had been extended to allow recording. Initially we were told it would be extended and improved, but this has never happened after many years. If you ask you will likely be told that they want to add features, but they currently have no plans to do so.

    It might be possible to do clouds inspired thing, considering its short buffer and poor audio quality, but then in Reaktor those are the things I would want to change :) Morphagene would be much more challenging.

    It is possible to do amazing granular things with Reaktor in terms of processing existing material then can be much larger samples. Table framework works very well for this.

    The sensible limit based on the maximum array size in Reaktor of 1048576 and the audio quality of clouds being 32KHz is 32 seconds, which is much longer than clouds, but then you have to write high quality resampling code :)

    And that's the problem, you have to decide on a maximum supported sample rate and downsample anything higher otherwise folk running at e.g. 96KHz would have a maximum buffer of 10 seconds... so some snapshots wont work when sample rate change because in Reaktor, that's not a parameter of the Block, but depends on the users Reaktor Audio settings... so the idea is achievable, but complex, and definitely not immediately portable from clouds to Reaktor.

    It's much worse for something like Morphagene clone - that's really not possible, but Clouds would be possible with some clever processing, just doesn't feel like it's worth it, for that level of sound quality - it's really not that good. It's famous and popular in Eurorack because it did something that was otherwise not possible in that context when it was released, but it really can't match the sound quality that folk expect from Reaktor IMO.

    Beads is much better, but its low quality modes - like the 'scorched cassette mode' - that have been raved about by many influencers, to me just sound bad - like poor quality bitcrushing/quantisation combined with some cartoonish modulation - just not great at all.

    So I guess if you want something like clouds, better to build from scratch using clouds/beads for ideas, and find some compromise on the buffer length problem.

    My best stab at a solution is to consider 48000 to be maximum quality, that provides a max buffer of 21.85 seconds, round that down, then make the buffer 20 seconds for 48KHz and 44.1KHz, and anything above that gets downsampled by a factor of 2 or 4. 20 seconds is more that we would need for a clouds like feature set. But it's frustrating because I want more flexibility than that, like Morphagene style slicing, and building up multiple layers via looping and feedback... but 20 seconds isn't really long enough for that IMO.

    I guess you could just say that maximum buffer size depends on the users sample rate settings, display them and the buffer length on the GUI, and be done with it... never really considered doing it that way lol... I suppose the problem there is that if they reduce the sample rate to enable a longer buffer for a badly conceived clouds clone, it also effects the quality of everything else they are using in Reaktor in their Rack or Ensemble.

    ------

    Anyway, the bigger reason for the lack of MI clones is that you can't directly convert c++ to Reaktor core, so it will never truly be a ported clone, so why bother when Reaktor can do better anyway. And the same goes for other MI modules. Anyone with the skills to grok the MI source code, and build at that level in Reaktor, would probably make their own 'inspired by' product rather than a bad clone... something that fits better into the Reaktor Blocks ecosystem... maybe? :-)

  • ab459
    ab459 Member Posts: 6 Sine

    It is possible to do amazing granular things with Reaktor in terms of processing existing material then can be much larger samples. Table framework works very well for this.

    Yes, need say (as a granular stuff sucker) i always keep in mind how good Reaktor does it, despite have a bunch of vst granular plugs. Even old factory Travelizer, in my opinion a beautiful example of a cleanest scan, with zero cpu usage, always admired him. (Why in particular I assumed that many other things here could also do well lol).

    But ok.

  • Paule
    Paule BerlinMember Posts: 268 Saw

    You can use my actual MS-20 clone v2.2 with Audio In and 900 snapshots. No it isn't a Block but patchable coloured cables in the salamanderanagram sys:

    It's not so small as a Block but a light weight on cpu.


  • ab459
    ab459 Member Posts: 6 Sine

    @Paule Thanks, looks interesting, will try.

  • colB
    colB Member Posts: 241 Saw

    Try searching the user library for "resonator", that might throw up some stuff that has similarities to Rings...

  • Paule
    Paule BerlinMember Posts: 268 Saw

    My clone contains a Ring Hack.

  • middle_hat
    middle_hat Member Posts: 5 Sine

    Thanks @Paule!

  • Paule
    Paule BerlinMember Posts: 268 Saw

    And really dirty sounds.

  • Nico_NI
    Nico_NI BerlinAdministrator Posts: 654 admin

    Interesting read overall, @colB knows it inside-out 🙌

Back To Top