(Somewhat OT) Reaktor re-write & backwards compatibility

Discussion in 'REAKTOR' started by Moujik, Jul 24, 2021.

  1. Jonathan Tremblay

    Jonathan Tremblay NI Product Owner

    Messages:
    394
    I'd agree if it meant more efficient audio processing/programing, or even just multi-core, because right now when using the Table Framework my CPU usage is much more significant. Along with audio-rate modulation regardless is a signal path is active or not.
    My Mono wavetable synth eats up around 30-40% easy using table framework, audio-rate mods, and 8 mod slots. Tough to get into making stuff when the cycles add up too fast. Guess hardware still beats most softsynths for now, or maybe it's just Reaktor, since I know plugins like Serum easily have over 16 mod slots and tons of voices. Or maybe just my inept implementation, but I doubt that since I've had to optimize the f**k out of it just to make it go down to that CPU usage to begin with.
     
  2. colB

    colB NI Product Owner

    Messages:
    3,854
    The idea that multi-core could/would be the cpu saviour of Reaktor is a fantasy. Over the many years folk have been asking for it, not a single person has presented an implementation strategy that would make sense in the context of Reaktor and would still provide a significant cpu saving, particularly in a DAW where you can already run multiple instances of Reaktor on different cores.

    Parallelism via simd extensions is a more likely fit, but would still be very difficult to implement in a user friendly confusion free way in core. And would be difficult to get the most out of.

    Most likely cpu saving improvement to Reaktor would be code re-use. Cache inefficiency seems to hit Reaktor particularly hard due to the massive code redundancy in complex instruments and large ensembles.

    Core iteration could help too for similar reasons.

    Parallel programming is hard, concurrency even harder. Even iteration can be tricky in a dataflow context. Many users already find Core too challenging without any of these technologies :)

    None of these things would require a re-write.
     
  3. Jonathan Tremblay

    Jonathan Tremblay NI Product Owner

    Messages:
    394
    I know :D:D:D
     
  4. hlmm

    hlmm NI Product Owner

    Messages:
    37
    As I see it, sooner or later Primary will go/will be replaced by something new (vector interface, etc) and Core will stay. So yes, there will be some work to be done porting existing projects but only Primary-built parts. That would make sense to me. Just my wild guess of course...
     
  5. colB

    colB NI Product Owner

    Messages:
    3,854
    Seems unlikely. The whole marketing strategy for Reaktor for years now has been based on Blocks. If Primary goes, the whole Blocks Library would need to be completely rewritten. All current Projects using Blocks would be broken. It's just not a viable option.

    More likely would be to keep a legacy mode/layer that can still load and run Primary based instruments and ensembles, but have that run 'inside' a new top level that is core based. And remove the option to create new projects in Primary, but keeping the option to edit existing ones.
    This also seems unlikely purely from a cost of maintenance point of view. But maybe the best option.

    This would flip the 'Primary easy : core difficult' mind frame as well, because core would be the first thing new users would be required to learn - so core would be Reaktor.

    Obstacles to this:

    * A completely new GUI system would need to be written to give core direct access at that new top level - this would be good, but costly.
    * core would need access to the file system, sample maps, midi, Osc, the audio system...
    * iteration in core would become essential
    * Cpu efficiency in core would need improvements in order to match the performance of some Primary modules
    * (a big one this!) Improvements to compile times and particularly the freeze/bogging down problem that can occur with large core structures would need a solution.

    At the moment, the number of users really pushing core to its limits is fairly low, and those that do are usually experienced builders, and can find workarounds for compile problems, or at least understand the problem.
    However, New users often start with a "new synth to beat them all" project with every feature known to humanity and all the controls. If this was attempted in pure core, they would very quickly hit problems that are difficult to explain, harder to understand, and even more difficult to solve.
    With the current version of core, sometimes the best solution is to split a large core cell in to two or more separate core cells within the main primary structure. That would not be an option with no Primary layer.

    It's easy to underestimate the challenge here. Core really needs to compile the whole project in just a few seconds or Reaktor starts to feel broken. Other compiled programming languages - like C++ - take way longer to compile large projects, but that's OK, because users don't sit through that process every time they run the software, or add a block, or load a patch.

    So there is a lot of work to be done before Removing Primary completely is viable. I think this is a difficult sell in a planning meeting.
     
    • Like Like x 1
  6. EvilDragon

    EvilDragon Moderator Moderator

    Messages:
    19,474
    Are you doing custom SR clocking of the Core cells to shut down their processing per voice or not?
     
  7. Jonathan Tremblay

    Jonathan Tremblay NI Product Owner

    Messages:
    394
    I did, but ended up going with primary switches instead that activate when modulation amount >0.
     
    Last edited: Aug 5, 2021
  8. EvilDragon

    EvilDragon Moderator Moderator

    Messages:
    19,474
    Ugh, general reset hell :)
     
  9. artao

    artao NI Product Owner

    Messages:
    66
    Last edited: Aug 7, 2021
  10. Paule

    Paule NI Product Owner

    Messages:
    7,397
  11. colB

    colB NI Product Owner

    Messages:
    3,854
    Blender is free and open source, not a commercial project. So the problems associated with a total re-write do not apply in the same way.
     
  12. artao

    artao NI Product Owner

    Messages:
    66
    Anyhow, I would run 6 and 7 side-by-side. I have a feeling a new UL would get populated pretty fast.
    Perhaps there could also be a conversion path or system of sort. Conversion SDK? I dunno.