Reaktor 6 Core oversampling

Discussion in 'REAKTOR' started by TriggerFish, Sep 14, 2015.

  1. TriggerFish

    TriggerFish New Member

    Messages:
    24
    I was very surprised to find this in the Core manual:
    "In the current version of REAKTOR Core the clock rates can be only lowered, not raised. Thus, oversampling is currently not possible"

    Is this really the case ? It would seem like a big oversight. Or maybe it's just referring to the provided resampling blocks ?
    I've seen some suggestions that oversampling should be possible using scoped buses, not sure how though ( I haven't had time to get familiar with those yet and it's been a few years since I last did some low level Reaktor work ).
    In software, creating 2x up/down sampling blocks with polyphase half band filters is really fairly easy ( I personally prefer IIR to FIR filters for these tasks ), I would have really hoped that you can do the same thing in Reaktor ?

    If you can do it, are there any examples in the Blocks that are not locked before oversampling occurs ? Or are the filters just not oversampled outside of Monark ?

    EDIT : After writing this I found some ADSR tutorials on oversampling in Reaktor 5 so I guess it is still possible.
    Though I'm curious whether it's easier now, and also why the manual is misleading this way.
    Also curious whether anyone has found some examples within the existing blocks.
     
    Last edited: Sep 15, 2015
  2. EvilDragon

    EvilDragon Moderator Moderator

    Messages:
    14,235
    It is possible they might add oversampling possibility in a later update.

    For the time being, you can set the ensemble sample rate to a higher value, then downsample in various degrees, where necessary, instead of oversampling. The result would be identical.
     
  3. tenandtracer

    tenandtracer NI Product Owner

    Messages:
    163
    You'll find some oversampling techniques most recently used in the Dual Sallen-Key Filter included in the Blocks Library.
    Quite a lot of R5 Saturation macros have some form of oversampling. Also have a look at the 2xOSC Synthesizer from the Factory Library - both the 'Multy-Filter' and 'Multy-Ladder Filter' have some 3xOS going on (they're labeled Filter 1 - Filter 2 in Primary. Drill down into the Core Cell to locate the Up/Downsampling code. My knowledge on the topic is pretty limited, however, and these may not be what you're after.

    It seems that the new Core SR.R and SR.C clocking functionality, paired with the many interpolation/smoothing macros in the Blocks Framework - and plenty of value/range scaling and clipping, have somewhat superseded these previous methods/solutions.

    This is just speculation and I may be completely wrong. I would love if someone with more R6/Core knowledge could elaborate on this topic? I'm considering taking the time to put together a handful of technical/tutorial documents that provide some more in-depth information about the new clock framework - best practices and topics such as oversampling. I started something similar for R5, but abandoned it due to lack of time and limited interest (and fear that Reaktor was never going to be updated).

    Now's the perfect time to follow through :).
     
  4. Chet Singer

    Chet Singer NI Product Owner

    Messages:
    791
    Oversampling an R5 core-based instrument isn't difficult, and I don't see why R6 would be any different. You just need to make your own sr.r and sr.c and send them into your core macro. Remember to add LP filters prior to your audio outputs or they'll alias and negate your efforts. My Silverwood Bb Clarinets ensemble runs at 4x oversampled using this method.
     
  5. TriggerFish

    TriggerFish New Member

    Messages:
    24
    Cool thanks all for the replies. Tenandtracer I personally would be very interested in some doc on the new clock framework.
    For what it's worth I've got a lot of experience writing DSP code in C++ and other languages but not really in Reaktor, though I did do some experiments there a few years back.
    Regarding the interpolation & smoothing macros I don't think they're intended for sample rate conversions, SR changes require very steep and well designed filters to avoid aliasing, simple smoothing and interpolation don't really cut it in general.
    In any case I will have a look at the examples pointed above, thanks !
     
  6. Vadim @ NI

    Vadim @ NI NI Team NI Team

    Messages:
    244
    Interpolation is an approximation of those "very steep and well designed filters" with a quite efficient quality/CPU tradeoff. Of course better filters in principle can be used.

    As for what the manual is referring to, the current ways of oversampling are rather workarounds than "proper solutions". The ones used in the library require multiple copies of the algorithm with manual "forwarding" of the states. The oversampling done by generating faster SR clock from the primary side is not so CPU-efficient.

    Thank you very much for your kind words and belief in our engineering skills. ;) We probably should have held off the update until we have "proper" oversampling and other features you guys have been moaning so loudly about upon R6 release ;)
     
    • Funny Funny x 1
  7. TriggerFish

    TriggerFish New Member

    Messages:
    24
    Thanks for your answer Vadim and no need to take offense - I've got a lot of respect and belief in your technical and engineering skills, and I've learnt a lot from your filter book and tutorials. And I do think that Reaktor 6 is great in its current state.

    However the lack of oversampling documentation at least, or templates / macros ( even if they were currently not very efficient and due to be optimized later ) in the ZDF framework is odd, given that nonlinearities are what makes filters sound good, but oversampling is required in most cases.
    As a result the framework feels like it's missing a key component. So yeah, sorry for moaning, but I hope this will be fixed / improved :)
     
  8. Vadim @ NI

    Vadim @ NI NI Team NI Team

    Messages:
    244
    I'm not sure it's appropriate to document the workarounds in an official manual ;) However we could discuss them in another public form, e.g. here.
    1. One possible solution is upsampling the entire ensemble and then downsampling the parts which don't need the high sampling rate. This is probably easiest and most readable. The resampling macros are provided in the library and documented in the manual.
    2. The "manual oversampling" approach is well illustrated e.g. by the SKF filter in the Blocks. Compare to the non-oversampled TSK NL filters in the Core Macro library. You can see the OBC wires responsible for sharing the states between two copies of the same algorithm. In principle you can simply exchange the oversampled path in that structure with your own stuff. So I guess you can consider the SKF as the template.
    3. The other possibility is to generate the oversampled clock from the primary side. This will have certain CPU overhead. Also there are no ready to use resampling macros which one can use in this case.
    So the 1st and the 2nd options are more or less "ready to use", right?
     
    • Like Like x 2
  9. TriggerFish

    TriggerFish New Member

    Messages:
    24
    Thanks Vadim. I guess my point was mainly that by just using the software and manual it's not really clear what you should do, but thanks for detailing these options it's very useful.
    I don't like 1. much because it makes it difficult to integrate your design with other ones ( like in blocks ) without running them at an necessary high sampling rate.
    But 2. and 3. sound good and I'll have a look in details.
     
  10. alcofribas

    alcofribas New Member

    Messages:
    22
    To have true upsampling in Reaktor would mean to be able to transmit more than one event per system clock tick in wires and buses. This probably means a lot of work inside the guts of the beast.

    The tricks that were used in R5 will have to do for R6 for the time being, but life should be a bit easier in R6 because of Bundles. Too bad they can't carry OBC connections.

    We should be able to get better reusability of macros inside of an oversampled zone of, but they will still have to be special modules, built for the purpose, with OBC and Array ports even for purely functional stuff like addition or multiplication.

    Also, conventions have now been established on how to read and transmit information about sample rate changes in a multi-level architecture. That also should help with reusability.

    Perhaps some conventions should be agreed upon so builders of oversampled libraries can share. Or we wait till Reaktor has true upsampling. How long will that be?
     
    • Like Like x 1
  11. alcofribas

    alcofribas New Member

    Messages:
    22
    Concerning the presently available smoothing technology in R6, me too I was first amazed at how primitive it is when I first looked inside those macros. You learn in DSP manuals that a good up- or downsampling filter should use a FIR with zillions of coefficients, and here we have four (I think) coefficients for audio and two for control! But we have been taught the standards of HiFi, and here we are dealing with a synthesizer. Those beloved vintage analog synths used lo-fi opamp technology.

    Better smoothing filters will be needed for some critical spots. I should add that IIR filters work fine and are much cheaper than FIR, and that phase response is rarely important. And we can design them ourselves.
     
  12. alcofribas

    alcofribas New Member

    Messages:
    22
    I keep forgetting to say that I started a thread just for technical discussions of R6 Core, to keep things in one tidy place, and that thread will soon get buried on page 2.
     
  13. Vadim @ NI

    Vadim @ NI NI Team NI Team

    Messages:
    244
    When you talk about resampling taken outside of a context, of course you're aiming for the best possible quality. For instance, if you just want to convert a WAV file from one SR to the other. When you're using the oversampling to improve the quality of an algorithm (e.g. reduce aliasing from a waveshaper), it doesn't make much sense to have the resampler quality much higher than the quality delivered by the algorithm if run at that SR. A naive waveshaper will still alias even at a higher SR, and from some resampling quaility on, the quality improvements from the resampler will be anyway masked by the aliasing from the waveshaper. So maybe you wouldn't want to spend extra CPU on better resampling.

    For comparison, any delay which needs to be modulated will also need to "resample" (that's what the interpolation in the delays is about). I haven't heard many complaints about Reaktor delays using "only 4 points" interpolation.

    Anyway, Reaktor Core, being an open DSP system, let's the users build their custom resamplers. That's what Reaktor Core has been (partially) about ;) I mean, is it an obligation of NI to deliver all possible DSP algorithms upon the user request, or Reaktor, being an open DSP platform, allows the users to make their own DSP contributions? ;)
     
    Last edited: Sep 15, 2015
    • Informative Informative x 1
  14. Chet Singer

    Chet Singer NI Product Owner

    Messages:
    791
    Heh, this idea never occurred to me. I may revisit that clarinet and try this technique.
     
  15. alcofribas

    alcofribas New Member

    Messages:
    22
    I've already given some thought to this approach, and this means that for efficiency you'll probably have to minimize the number of audio boundaries between your macros in Simple. So in general you'll have to go for big Macro Cells with few interconnects between them. If you are designing an elaborate synth, that means for example turning your audio Switches into controls for multiplexers, and pushing those multiplexers inside the Macro Cells. Personally I much prefer programming in Core anyway, the workflow and the looks are better. But there will be a need for more elaborate Core libraries, home-built or factory-provided.

    Ah, that's where I have to go to see how you do oversampling yourself. I would never have thought of going to see in Blocks, thanks for the tip.
     
  16. Tr97

    Tr97 NI Product Owner

    Messages:
    96
    this is an example of an oversampled tanh-shaper. but it is a heavy cpu eater at 8x oversampling cause it uses an simple brute 128 fir up- and downsampling (convolution) filter. the oversampling eventstream is produced by a corecell and an event merger. estimate it could be possible to reduce the cpu usage by >75% with some filter optimizations.
     

    Attached Files:

    • Like Like x 1