1. Please do not install macOS 10.15 Catalina yet, as Native Instruments software and hardware products are not supported under macOS 10.15 yet. For more info, please go HERE!
    Dismiss Notice

Core Accel / Rit anyone?

Discussion in 'REAKTOR' started by Catman Dude, Oct 12, 2019 at 11:28 PM.

  1. Catman Dude

    Catman Dude NI Product Owner

    Messages:
    352
    I searched around the forum and the U/L for any signs or clues, but there didn't seem to be any serious ones.
    Has anybody tried, or better still, succeeded, in creating an instrument that can induce an exponentially accelerating or ritarding sequence of gates based on some slower gate rate and a user-selectable number of attacks???

    Is this really hard in Reaktor core? (It has been for me, heh heh.)
    I didn't think it would be such a puzzle. I started with a block of Mitch Burton's, PHIL, which does either a single clock divider or a clock multiplier. I was mostly interested in the multiplier, as that is trickier. I didn't love the constant pulsation of PHIL's multiplier, so I applied a masking method to it, which worked out really swell and happened quickly (especially compared to the as yet unfinished Accel/Rit!).
    I figured if that was a piece of cake, well, then why not this thing nobody seems yet to have tackled?
    Aha, maybe people have tried, and bodies lie strewn around in trenches or over barbed wire somewhere out there?

    The method I assumed would work would be to substitute, for the steady sample-counter in PHIL's multiplier, a constantly changing (longer to shorter or shorter to longer) sequence of one-shot sample counters (for the same number of attacks as the multiplier gets from the user) by either calculating on the fly an Accel/Rit based on one or another expon/log functions, or storing these in an array and picking them off, index by index, and plugging them into the multiplier's sample counter. I tested the function aspect using the 'Normalized Tunable Sigmoid' equation, and surprisingly again, that worked well and quickly. I can see in a demo ensemble that it's functioning exactly as one would expect. So the rest should be easy, right?

    Well, obviously not so. Is what I just described above as a method workable, in principle?
    It could easily be the case that I bit off more than I could chew ;), as far as my core programming chops are concerned.

    At the moment I'm stuck on both sides of the method fence mentioned above. I'm thinking of giving it one last go using a fixed table. BUT, would accessing such a table be any more likely to work than my miserable efforts at fishing my entries out of an array?? Possibly, since protecting my array from write-access while I am reading it was one of the nuts I hadn't figured out how to crack...

    SO, I would be very grateful to anyone who can tell me anything instructive about this mysterious lack in Reaktor (as far as I have been able to discover).
    thanks in advance,
    David
     
  2. sleen

    sleen NI Product Owner

    Messages:
    888
    The dominant model of musical sequencing is to implement a canonical pulse generator at a high rate and then engage in frequency division to the rate(s) desired for table lookups. This model only requires one pulse oscillator and is useful but has limitations and gives drum machines a bad rep.

    The alternative involves more than one pulse stream and without totally losing my mind amounts to essentially FM or frequency modulation of pulse generators (clocks*) with or without feedback loops, within clock ensembles**. In my understanding and experimentation the latter is better at approximating 'human' ensemble effects involving the asynchronous propagation of timing or phase information through ensemble topologies like drum circles vs drum lines and the agency of individual players who can keep, listen and adjust and reset their positions.

    *I don't know what an ideal clock is but I think it is more than a pulse generator.
    **Not reaktor ensemble but a clock collection or ensemble which is what communication scientists call them.
     
    • Like Like x 2
  3. p1afff

    p1afff NI Product Owner

    Messages:
    997
    Hey David, difficult to say if these will match, but did you have a look at Auto Rise AR, or Bezyeah Clock in the UL? Builder hmm also have exotic objects in the UL that might apply.
    You could also mod the NI Clock Divider or any other, could'nt you ?
     
    Last edited: Oct 13, 2019 at 12:58 AM
  4. Catman Dude

    Catman Dude NI Product Owner

    Messages:
    352
    Sleen, thanks for these thoughts.
    It's nice to know we are perhaps on a similar wavelength about pulsation.

    My latest efforts all fall within an old-fashioned block I call 'Round the Clock'. So the name tells you what I think is missing in the mechanical object that is a drum 'machine'. I wanted to be able to add Accel/Ritard to Round the Clock before releasing it. It isn't nearly all the way to what I call 'musical time', but it's a step in that direction. Musical time depends on implicit pulsation as opposed to explicit pulsation. Loud 'YES' to 'frequency modulation of pulse generators"! (Of course the tyranny of the DAW's tempo is a significant chunk of the problem.)

    Round the Clock filters out a lot of pulsation events, putting back in lots of the silences that are missing from mechanical musical clocks. Holes in the fabric are necessary. They allow for ambiguity and inference; time can blessedly hang suspended, allowing for inflection and modulation of the implicit pulse. (Again, that's only part of the way to musical time.)

    Round the Clock, like its predecessor (Poly Clocks +) allows for polyrhythmic confluences. While these are in their own obvious way mechanical, gears neatly nested together, such combinations impart ripples and waves into the fabric of time, causing a pleasant chaotic disturbance of the otherwise rigorous pulsation.

    I await others' comments, and perhaps guidance on the issue of Accel/Ritard.
    If nothing explicit emerges from our forum members, I will try the table lookup approach to bending the pulse...
     
  5. colB

    colB NI Product Owner

    Messages:
    3,014
    Catman Dude I guess what you are asking about is a 'clock multiplier' or 'ratchet generator', at least that what I got from your post.

    The problem with these is that you need to know or measure the rate of the input pulse.. e.g. in a Blocks environment where it should be able to respond purely to an audio rate input signal with some sort of pulse on it... The issue is that you need a whole cycle of the input pulse before you know what the tempo is. So startup is dodgy, and tempo changes are dodgy - there's no way round this.
    Instead if you use a much faster core clock as suggested by sleen, then divide down, you easily sidestep this issue. So why would you use a multiplier at all?

    The one area where it really does make sense is in the context of a sequencer. In that case, assuming the sequencer is generating an internal clock pulse, you already know the tempo, so startup and tempo changes are not really an issue in the same way. Additionally, having a ratchet system, means you can have a simple interface based on quarter notes or sixteenth notes, and still create more complex rhythms by manipulating the ratchets.

    sleen Interesting ideas about multiple interacting time pulses. Is there really much you could do there that would not be possible with a single pulse that is modulated though?
    e.g. shuffle feels can be achieved just with a clock divider and a feedback to the rate of the clock generator.
    Stuff like Euclidian Rhythms are produced with just a single pulse. Polyrhythms are more complex I guess, but I was under the (probably false) impression that performers would still have a collective implied/inferred pulse in their minds ear that binds the whole thing together?

    Just using a base clock based on 12 opens up a lot of possibilities - like MIDI clock. Add some swing/shuffle options and that covers most things?
     
  6. Catman Dude

    Catman Dude NI Product Owner

    Messages:
    352
    Hi Philippe,
    Ah, I thought you would know I am a devotee of AutoRise AR2! I use it in many of my sequenced ensembles. It's another wonder from Thala.
    However, it always deals with FIXED divisions of the beat. Everything in it falls strictly on some grid-point.
    I have often contemplated how I might disturb the regularity of AutoRise's clock, but the closest I have found to a really good starting point is Mitch Burton's PHIL. I might get there one of these days!
     
    • Like Like x 1
  7. Paule

    Paule NI Product Owner

    Messages:
    5,153
  8. hlmm

    hlmm NI Product Owner

    Messages:
    26
    Not very serious but something along those lines I have made as Expander for my Press tempo block.
    https://www.native-instruments.com/en/reaktor-community/reaktor-user-library/entry/show/13105/
     
    • Like Like x 1
  9. Catman Dude

    Catman Dude NI Product Owner

    Messages:
    352
  10. Catman Dude

    Catman Dude NI Product Owner

    Messages:
    352
    Thanks, Colin for your (as always) helpful and pointed insights.
    Yes, this is strictly clocks at this point, i.e. for sequencing. PHIL already has code to compute the incoming gate duration. And it's clocking is at the sample rate, which is quite fast enough for my purposes.
    And, holy cow, it appears to be working now! (I don't want to overstate the level of success -- there are glitches, and it has a primitive quality owing to the fact that there's only one row of exponential factors in the table currently.)
    The dodgy aspect may stem from the incestuous nature of the variables.
    And therefore lots of orange wires. :eek: (I'm not sure if a Latch-1 inserted somewhere would get rid of the garish wires...)
    Fortunately the glitches don't totally mess up the concept. I do wonder if the incestuous variables are making the compiler go a little crazy? I will include a pic of the structure, and perhaps you or someone else will see a way to improve the structure. Always optimistic! :)

    What I've done as a proof of concept relies on a single row of a core table (entered manually from my original demo ensemble), length 16 attacks.
    When the sample counter finishes a cycle (based at first on a division of the 'long incoming gates' by the integer-multiplier value, i.e. the number of attacks to fill, quickbus-named 'wrap') the clock divider updates a cyclical index, which reads the y-value from the table at that index, which y-value gets multiplied by the count of samples in a 'long gate', and this number becomes the 'SampDur' for the current cycle. And so on.
    And so there is a distinctive speeding up in an audibly exponential fashion, when it gets in its groove.

    What really made the difference was implementing a clock divider from the library, with N set to the number of samples calculated as the current cycle, a.k.a. 'SampDur'. This made the kicking up of the index get in sync, and thus the new 'SampDur' is likewise in sync.

    Lots more to try out, among which is an obvious need to make sure that the index gets reset to 0 on external reset; that's a glaring lack at the moment.

    AccRitAccumulator.png
     
  11. colB

    colB NI Product Owner

    Messages:
    3,014
    you still haven't explained clearly what you are trying to make, just some half explained hazy ideas and a lot of implementation details from an implementation that doesn't quite do what you want? or maybe it kinda does?...

    I think if you can lay out the functionality you are aiming at, in simple language, without any implementation details, then that will help a lot. And it will help you to get feedback as well.

    A description of how the thing would work from a user perspective, what the controls are, what they do in a production context, maybe a few use cases. Until you have that, you will chase yourself around in spaghetti circles.

    (Speaking of spaghetti circles, it's best to avoid those orange wires in core. You need to decide explicitly where to use a z^-1, or set up an OBC chain.)
     
  12. sleen

    sleen NI Product Owner

    Messages:
    888
    Hey Colin, yeah I think there are other things that are possible. The single pulse train is just one way and is useful practically for distributing sync, but also conceptually because our preferred musical system and notation assumes that all clients are proximal. The system itself impiles that verticality is syncronous. But approaching musical ensembles (and neural) like comm networks, that basic useful model doesn't exist for us ugly bags of water.

    You assumed correctly actually that there is a phase inference that musicians can understand in ensembles and even within an individual playing a kit. Thanks for seeing that. It could be called super time or something but in physics the contribution of individual periodic elements allows for the emergence of a time scale, the arrow so to speak. I should point out that network time is currently computed as an average of atomic clock positions which I suspect is wrong or at least could be improved. Sync in a digital network is different from physical systems and neural networks. Two pendulum on a wall eventually sync through the loosely coupled exchange of quasi particles called phonons. Time scale is like temperature from the root mean square of gas velocities. So might be tempo so here we can consider entropy. A typical drum machine with a single pulse train is very cold and feels that way. In topology it is a star with sync going to track clients. A human listener expends little energy syncing their own internal mind's clock to it and finds it boring. Allowing or encouraging a listener to fill in gaps, anticipate and play with positive and negative space, hinted at by the dude, is key for dopamine production and reward. But funk groove pocket and a kinaesthetic motivator to nod one's head or shakes one's bootay is probably not stemming from the aforementioned star and perfect sync. Drum machines don't in fact suck. They are just currently very simple.
    You asked why not pulse and subdivide and if humans are special by having a connection to the time scale inference or super time. We are I think, but so can our digital friends be. I think this is possible through physical modelling to allow exchange of phase not with pure information or positions as in a typical digital sense, but with feedback loops and the design of new networks where there is no master and phase is communicated physically with energy. Leaping ahead I imagined that this would amount to a phase modulation algorithm where the tempo is an imaginary and itself moving thing. I suspect this takes us closer to understanding human ensembles and helping drum machines breathe and groove.

    Dude sorry for the hijack. This is a tough subject that I have spent some t...effort on.