1. Hi everyone,

    Apple just released Logic Pro 10.5 for MacOS 10.15. We found out that Crush Pack, Mod Pack, Replika, and Replika XT will crash.

    Our teams are currently working on a fix, and we hope to have this out to you as soon as we can!

    Best wishes, 
    The NI Team

    Dismiss Notice

Poly Blocks (maybe?)

Discussion in 'REAKTOR' started by colB, Aug 19, 2016.

  1. colB

    colB NI Product Owner

    Messages:
    3,251
    I've uploaded a test ensemble to the User Library - get it here.

    This is to get some feedback on my attempts at developing a system for polyphonic blocks.
    First of all, I'd like to get an idea of cpu load for different users.
    It would also be great to see how people get on with the minor hassles of using this system - the poly output connections and the MIDI voice slaving.

    I think the most likely use for this will be to add some polyphonic capability in the context of a mostly monophonic structure, but it doesn't have to be. It's pretty easy to build a polysynth with suitable polyblocks, just less cpu efficient than creating one in the more traditional manner.

    Anyway, if you try it please feedback with comments, questions, bug reports, suggestions, criticism etc. :)


    Col
     
    Last edited: Aug 19, 2016
    • Like Like x 4
  2. colB

    colB NI Product Owner

    Messages:
    3,251
    FWIW, if you want to get a feel for this as a playable synth, go into the ensemble structure and remove the connections to pitch and gate inputs on the envelopes, the supersaw and the two poly oscillators. Then on the Panel, double click the main pitch setting on the supersaw to zero it. Now it should play as a standard MIDI polysynth.
     
  3. mosaic_

    mosaic_ NI Product Owner

    Messages:
    490
    My i5-4200U at 2.30 max GHz gives me 70±2% at 44100 Hz, but with an "Over" every second or two that sometimes causes dropouts. There's a lot going on in this patch, so it's hugely impressive nonetheless.
     
  4. colB

    colB NI Product Owner

    Messages:
    3,251
    Thanks.
    I have a couple of possible ideas about the "Over" that's causing dropouts. I watched, and even on my system, I'm getting the occasional red bar. I think it's partly to do with the way I'm drawing the display for the envelope. I've put in a fix for that, so after a few other things I want to try, I'll post an update to see if that makes it more stable.

    ---------------------------------------------------------------------------

    In general, the main cpu drain is the audio processing. It would be possible to rewrite some of the blocks to be more efficient, but that would take the edge off the quality which kind of defeats the purpose. It would make a difference if there were polyphonic connections at instrument level, but the cpu would still be very high.

    Another issue I've not found a great solution to yet is a good way to smooth the controls monophonically, and pass them to the polyphonic process efficiently. The Blocks modulation system is great, and works really well in a monophonic context. Unfortunately, when you make it polyphonic, it's not so great. The system binds the modulation to the individual controls. That means that for every modulated control, you also have extra A & B controls (and an additional C sometimes). That's fine in mono where you can pass the control data at event rate, and do smoothing in the main process core cell. In polyphonic mode, it's a different story. If you just switch to polyphonic mode, the smoother is processed per voice - very costly. On the other hand, if you run the smoother in the monophonic control module, then you have 3 audio rate signals per control (4 if using an extra 'C' modulator) to pass over to the process module.

    My current approach is OK, but not great, I'm sure there is a better way.
     
  5. salamanderanagram

    salamanderanagram NI Product Owner

    Messages:
    3,445
    my machine is pretty poor, but it overloads and turns off reaktor's clock immediately.

    obviously you already know my opinion which is that we should just use macros for polyphony.

    another thought is you could get 4 voices by overclocking reaktor by 4x. it would probably be more efficient than this, but limited to 4 voices. probably you would need a complete overwrite of the smoothers, too.

    EDIT - now that i'm thinking about it, this really wouldn't work with anything that needs feedback, without subsantial modification. bummer.

    RE-EDIT - upon more thinking, it should be possible. weird, but possible.
     
    Last edited: Aug 20, 2016
  6. colB

    colB NI Product Owner

    Messages:
    3,251
    OK, I uploaded a new version. The only change is an update that hopefully reduces these "Over" occurrences.

    Will get a less demanding demo up soon as well.
     
  7. colB

    colB NI Product Owner

    Messages:
    3,251
    I totally get that. Unfortunately folks don't seems to be buying into 'macros' these days, Blocks rule :(

    The idea here is partly to see what it would be like to have real blocks, but with polyphony, so one goal is to get as close to the same workflow as possible. Other than that it's also about the technical challenge of just getting it to work at all. e.g. getting the inputs to accept both poly connections and monophonic audio connections, and getting the poly outputs to dance around the Reaktor initialisation system to provide bus indices at init, but zero after that to protect speakers from DC in the case of user error... maybe not the most practical outcome, but close enough to get a feel for what poly blocks might be like if they existed, and an environment for developing polyphonic processing ideas - like the delay in the demo example.

    Cpu is high :(. I will get a less crazy example up soon.

    BTW, check out the internals of the SUPASAW. I was always intrigued by reports that the original Roland implementation used a clever trick to get seven saws from a single oscillator. All the clones seem to use multiple discrete oscillators. This implementation uses a single audio rate oscillator and two event rate LFO's to generate seven detuned saws. It's based on an idea in the comments sections of this blog post. The suggestion didn't quite work as described, but a bit of tweaking and brain bending sorted that...
    EDIT: Just tweaked it so there are no LFO's, just a single ramp oscillator scaled and added to itself in various combinations.
     
    Last edited: Aug 21, 2016
  8. mosaic_

    mosaic_ NI Product Owner

    Messages:
    490
    The new version is a definite improvement with CPU stability. Average usage is about the same. What did you tweak?
     
  9. colB

    colB NI Product Owner

    Messages:
    3,251
    The display for the envelopes was being clocked by the system display clock. Problem was that it is fairly heavyweight because it redraws the ADSR graph using 100 multi-display objects, so with three envelopes, each time the display clock fired an event, they all got updated. So I put a filter in so that they would only be updated if there had been a control change - a little macro that filters the dclk based on the ADS&R control input activity:
    dclk filter.PNG

    Simple but effective.
     
    • Like Like x 1
  10. colB

    colB NI Product Owner

    Messages:
    3,251
    Just uploaded another test ensemble. This time a simple polysynth. Should be much less cpu intensive (fingers crossed!)
     
  11. herw

    herw NI Product Owner

    Messages:
    6,403
    From your first example i see that the ADSR-display is not actualized by the modulation of the ADSR-Knobs? So isn't it possible to start the display-iteration only, when any of the knobs changes its value?
    ciao herw
     
  12. colB

    colB NI Product Owner

    Messages:
    3,251
    Exactly. I wanted to ensure it was being processed on the display/gui thread, so ended up with this. I guess doing it directly from a knob event should also put it on the gui thread, but wouldn't it still be updated more often than required?
    I assumed that controllers are polled more often than the frequency of the display clock, maybe that is wrong.
     
  13. herw

    herw NI Product Owner

    Messages:
    6,403
    right, your trick is fine and looking at CPU-usage shows 0.
     
  14. colB

    colB NI Product Owner

    Messages:
    3,251
    Just have to remember that it's still not zero cpu. It just doesn't show on the meter because it's not on the audio thread.
    If there is enough load on the gui thread, and the audio thread is close to the limit, you can get overloads as a result. With something like blocks, it's easy to forget when developing that someone might use multiple instances of the same module. If the design means that the cpu load is unintentionally synchronised across all instances, it doesn't matter if it is only on the 25Hz display clock, it can still cause problems. I fell into this trap.
    Normally I would expect the load to even out because Reaktor is processing the audio in buffer chuncks rather than per audio tick, but when the cpu load is getting critical, sometimes the OS still can't find enough gaps in one process to service the other. I think that's why increasing the buffer helps, makes it easier to spread the load.
     
  15. Catman Dude

    Catman Dude NI Product Owner

    Messages:
    480
    Really nice work! I haven't looked inside yet, but I am surprised and enthusiastic about your re-angling of blocks into viable poly-synth forms. I will see about developing some snaps for this, regardless of its 'test' status. :):thumbsup:
     
  16. colB

    colB NI Product Owner

    Messages:
    3,251
    Have at it :)

    David from Toybox (bolabo) has come up with a nice solution to avoid having to have a 'VOICE MASTER' module. So that's the way to go. It's important to try and use the same shared table as other polyblocks using the same system, otherwise they will not be inter-compatible.
    I think at some point (assuming NI hasn't made it irrelevant by allowing polyphonic signals from instruments - which would be ideal), we should come up some format that is in some way extensible, but also compatible, and update all blocks using the same system to that.... in the future... maybe ;)
     
  17. Catman Dude

    Catman Dude NI Product Owner

    Messages:
    480
    On the evidence of your test ensemble, I'm surprised NI hasn't jumped all over polyphonic blocks.
    Maybe those interested in pushing or pursuing the poly-building possibilities should start a forum-conversation about what the potential directions and limitations might be for making a 'protocol' for poly-blocks. (Clearly you and Bolabo are at the forefront here).
    I'm very interested, but need to do a lot of research, as so far I've gone along with 'blocks are monophonic'.

    That said, I think this is the most interesting development in blocks I've seen since I started in Reaktor.
    Your ensemble demonstrates the power of just a few voices in poly-mode blocks, with the usual excellent blocks' audio engine behind it.
    I happen to find your 3-voice version pretty compelling, as it fits right into my musical needs.
    I'll try to follow what's happening here (when I open the 'Voice Master' I see no modules??), and look at the Poly synth in toybox.
     
  18. colB

    colB NI Product Owner

    Messages:
    3,251
    I'll give a brief explanation of how the basic idea works.

    Direct connections between Instruments can only be monophonic.
    However, Instruments can include client instances of shared a Event Table or Audio Table.

    So the basic idea is to use a shared table as a polyphonic audio bus.

    During initialisation all blocks that are part of the system generate a unique ID for themselves and send it downstream to other block they are connected to. And monitor their own input for an ID to be sent to them.
    Then after initialisation, they write their poly output to indices of the shared table, and read their poly input (if any) from other indices based on ID(s) that were sent to them. If you get all that to work, you have a framework for polyphonic connections between instruments.

    The tricks is in ironing out all the technical details. e.g. It's important for this to be inter-compatible with standard monophonic blocks, so the inputs need logic to switch mode depending on whether poly or mono has been connected to them...
    I chose to to have separate mono and poly outputs - where the mono out is a mix-down of poly voices. I think Toybox block are slightly different in this respect, I need to spend some time analysing Davids solution, and working out if there are any other possibilities.

    I used the 'VOICE MASTER', because for this to work, all Blocks need to be set to the same number of polyphonic voices. You can tell them all to slave their voice count to some other instrument, so I figured if they all slave to a dummy instrument, then you can just change the voice count for that instrument and all the rest follow.
    Toybox works slightly differently in that there is a fixed maximum number of voices, and the shared table is used to share information about the number of currently active voices. Any inactive voices will be turned off via clock gating. Something like that anyway.
    EDIT: not sure about this now, I've been looking through some of the Toybox poly stuff and can't find any clock gating - it seems to be just a fixed number of voices for all block, which os not a bad way to go - as long as users all know not to change the voice count ;) That was the point of the voice master - a place to change the voice count...


    It really would be much better if this was all unnecessary - there is definitely an overhead using tables for all those audio streams, and working with shared tables is one of the most crashy parts of working with Reaktor :)

    And it does have the potential to sound amazing!
     
    Last edited: May 23, 2020
  19. Catman Dude

    Catman Dude NI Product Owner

    Messages:
    480
    Fantastic explanation. I saw all those tables, the 'Unique ID' macros, but I didn't get that it involves a 'notification system', where the 'notification center' is the shared Audio Table (well, in a sense).
    The mode switching I'm sort of familiar with from David's Level Sequencer, which I played with, which allows for outside inputs to override internal ones, using Port Switch modules, though that's not quite switching between Poly and Mono.
    I also saw in your code the Voice combiners leading to 'mono' outputs.

    Above all, I think the sound that results is a real 'game changer'. I loved listening to my mostly monophonic but periodically polyphonic MIDI track settling sometimes into 3-note chords, or revealing the legato counterpoint when it's there, and having the sound be clean and rich, not grainy.
    I'm kind of shocked that NI hasn't seen this as a fantastic direction for Reaktor, but well, I'm not in their game.

    I will apply your explanation to the modules to get the hang of the system.
    I say 2 thumbs way up! :thumbsup::thumbsup:
     
    • Like Like x 1
  20. Catman Dude

    Catman Dude NI Product Owner

    Messages:
    480
    I have the impression now that the 2 versions of polyphony (your test with 'Voice Master' and David's, without) are in essence the same.
    (Probably necessarily so because of the Audio Table as Polyphonic audio buss.)
    David's Gen Idx core cell makes one critical part of the process a little more transparent to the outside builder.
    (I am still a little unsure of how the algorithm ensures uniqueness, so if you want to explain how either algorithm does that, i.e. your Unique Id macro, it would be helpful.)
    In spite of such uncertainties, it appears that you have supplied outside builders with a 'blueprint' of how to convert monophonic blocks to polyphonic, as long as the methods used are consistent.
    And since you say David's is the way to go, I'm on board with that.
    His Synth Pack includes multiple polyphonic blocks so following his lead should enable me or another interested builder in making compatible polyphonic blocks. And thus creates the possibility of mixing and matching various poly oscillators with poly filters and poly adsrs, etc., for rich varieties of poly ensembles -- from originally mono blocks -- which is simply amazing!
    (I am about to grapple with the beast. I don't set my expectations too high at this point...)