1. IMPORTANT:
    We launched a new online community and this space is now closed. This community will be available as a read-only resources until further notice.
    JOIN US HERE

Sharing Sample Maps Between Modules

Discussion in 'REAKTOR' started by mike-dean1, Sep 11, 2013.

  1. mike-dean1

    mike-dean1 NI Product Owner

    Messages:
    38
    Hi,

    I'm have a stacked macro that uses several sampler based modules. I want to be able to have a single sample map that can be shared across all the macros so that when I update one, the change is reflected across the board. I tried saving one map and loading it in the other, but obviously they don't update when I change the map. The idea is that I want to be able to switch between modules like the Grain Resynth or Pitch Reformer using the same set of samples.

    Anyone know a way to do this?

    Thanks,
    Mike
     
  2. salamanderanagram

    salamanderanagram NI Product Owner

    Messages:
    3,454
    i don't think that's possible, sadly.
     
  3. mike-dean1

    mike-dean1 NI Product Owner

    Messages:
    38
    Hm. Fair enough. Was afraid of that... Thanks.
     
  4. medicine tactic

    medicine tactic Forum Member

    Messages:
    26
    Yup, this is near the top of my Reaktor wish list, along with "pooled" macros (where changes are reflected in all instances at once).
     
  5. pentrite0

    pentrite0 NI Product Owner

    Messages:
    83
    +1 for the "pooled" macros.
    Also, a "shared" option for Wave-Tables (even at core level) could save ressources.
     
  6. salamanderanagram

    salamanderanagram NI Product Owner

    Messages:
    3,454
    you can share audio/event tables
     
  7. pentrite0

    pentrite0 NI Product Owner

    Messages:
    83
    Yes, at Primary level.
    It would be cool if it worked too at Core level. (i.e. one table shared betwen multiple Core Cells)

    And when you save a table that you made with a Primary Audio Table, and reload it in a Core Table, everything with an absolute value above 1 is wrapped.
    Also, the possibility to write directly in a Core Table would be a great addition :)

    By the way: the possibility to switch betwen Tables in Core would be nice too (the actual Core Routers don't accept that type of connexion).
    Actually, if one want to switch betwen Tables in Core, he has to switch betwen Read modules, wich is not the smartest way to do (for exemple, if you read the table with a 6 point interpolator, you have to double all the Read modules, and insert 6 Routers and 6 Merge modules)
     
  8. salamanderanagram

    salamanderanagram NI Product Owner

    Messages:
    3,454
    in core sharing tables is unnecessary because you can use the OBC connections to attach to as many read modules as you like.

    also you can easily load files in core without wrapping them by using .txt files instead of .wav, it's not the table's fault it's the .wav format that does that i think.

    it is annoying that you can't write to tables or load files in arrays, either one would achieve the same purpose..
     
  9. pentrite0

    pentrite0 NI Product Owner

    Messages:
    83
    Is it possible to save a table in Txt format ?

    Anyway, I've added a "normalize" option to my Table Filter, it's in the starting block.
    I'll probably release it tomorrow, I just need to add a "user-friendly" interface and a text of explaination in the front panel !
     
  10. pentrite0

    pentrite0 NI Product Owner

    Messages:
    83
    I've tested the .txt solution: it does not wrap-around but the admited total length seems to be shorter than whith .wav.

    Here is the Table Filter:
    http://co.native-instruments.com/index.php?id=userlibrary&type=0&ulbr=1&plview=detail&patchid=13359
    To load the "Carbon+Oki" (total length=1 550 770) in the Wave Osc, I add to make it with a .wav file, the same with .txt didn't worked.

    Haven't tested all the windows to see wich one makes the lowest ripples in the pass-band, should be the key to reduce the use of normalize, but this will automaticaly have a drawback on something else (transition width, stop-band attenuation,...)