Let's talk about arpeggiators..... Again.

NB: This is not quite the first time I've asked about this https://www.native-instruments.com/forum/threads/lets-talk-about-arpeggiators.316680/

I’m somewhat taken aback by how difficult it is to achieve a basic arpeggiator in Reaktor, considering how ubiquitous they are in a lot of hardware synths and DAWs.

After spending longer than I care to admit trying to create my own from scratch (working on a suggestion from the previous topic regarding iterators from a kind soul whom I forgot to thank), I decided it’s probably more trouble than it’s worth and tried adapting the arpeggiator that comes with the reaktor 5 macro library. Having some issues though, as ever.

• Tried adding a Hold/Latching option. Failed. The best I could do was create one where previously held notes are not overwritten by new Note On messages, and are simply added to the sequence.
• Attempted to create a means of expanding the arpeggio’s range by an octave or two. Also Failed. Couldn’t find a way to do it without using up additional voices which interferes with the notes held down for the sequence.

I suppose what I mean is that, uh, I failed on pretty much all counts to actually adapt this arpeggiator to suit any of my own specification in any shape or form. I’ve tried other arpeggiators out there, the closest in functionality to what I want being the Arpeggiator in Guido Weber’s recreation of the Juno 60 which I attempted to play about with, but the end result was extremely buggy, with old notes occasionally playing when keys are first held down and the voice cycle for the otherwise monophonic output never really worked the way I wanted it to; the Note On messages would often pick up on previously-played notes which created a delay-type sounding effect.

So yeah. Um. Little help?

(note: I still know next to nothing about how Core works)

 

hehe lol wibble.....

There's a reason that there are so few arpeggiators for Reaktor: Arpeggiator development in Reaktor will drive you nuts!

Seriously though, since your previous thread, and the little example I posted, I became interested in a 'proper' arpeggiator. It has been a LOT of work and still isn't finished.

Reaktor is great at generating and processing sound, but stuff like sequencing and arpeggiating is not easy in Reaktor, its probably a lot easier in a traditional programming language like c++.

It's quite a complex set of problems and as you delve deeper you will find issues that have no easy answer, only compromises to be made. The latching it a little tricky and you end up with multiple modes, because there is no single 'correct' way, but for me the bigger problem has been one of design decisions...

So for example - after getting bored just stepping through the notes linearly, you will want to add some sort of cascade feature (at least I did ), but then oh no, it gets hard. e.g. say you set the cascade on 5 up and 2 forward (5 notes up sequentially, then jump back 3 and repeat), but you want your arp to play from the lowest held note in the lowest octave to the highest held note in the upper octave... what if that is not a multiple of 5... either you need to truncate one of the cascades, or you need to start on a 'wrong note' or you need to end on a 'wrong' note.
At first I was truncating the final cascade, but that sounded a bit off, and complicated things in other ways... So I switched to finishing on the wrong note (but never exceeding the highest held note in the highest octave)...

There are other equally annoying decisions to make, sometimes requiring a complete re-write just to try out the different options... AAaarrrrg

---------------
FWIW, using voices for this is a dead end IMO (like I said before). The MIDI notes are just a monophonic sequence of ons and offs. The output of a traditional arpeggiator is just a monophonic sequence of notes. Why complicate matters by waiting for reaktor to turn the incoming MIDI into a polyphonic system. Instead, use the 'channel message module to directly grab the note on and note off messages, store these in a table or array (add note-ons at the index of the pitch value, remove note-offs and the off pitch value). Then do whatever you need to do to turn the table of notes into an arpeggio.

It's tricky because for anything interesting, you'll either have a LOT of iterating going on, or some complicated mapping and sorting to do. I went with the latter, and think now that maybe the former would have been a better choice. Either way, as soon as you start to extend the octaves beyond the notes being held, it gets much more complicated. The brute force iteration approach will be easier to implement, and the cpu overheads will probably be OK due to the event rate nature of the beast, but the mapping and sorting approach offers more flexibility and therefor more options for alternative modes of operation.

--------------
Here's another thorny question:
What do you do when the player hits a new chord ? Do you restart the arpeggiator from the bottom (or top), or do you start from the 'current' position but with a key change. Restart seems like the only sensible option, but then when you start using the thing for basslines, you begin to appreciate that the pattern fitting to the song position can be more useful than the pattern restarting on a new chord... more 'modes' to implement...

Like I said, it will drive you nuts

I guess we have to remember that the people who developed those hardware synths and DAWs were very clever people, so we shouldn't just assume that because a feature is ubiquitous, it must be easy to implement .

 

haha, so I have discovered!!

Yeah, that's the impression I've been getting with it so far. All my more interesting/more fun experiments have been with FX processing, though I think the fact that sequencing is harder to achieve draws me to it more somewhat. If I can't figure something out or it doesn't work it'll bother me till I actually get it right!

Regarding the polyphonic voices, the main reason I wanted to go down that road in the first place was simply so I could have release times of my amp envelope that aren't interrupted by new Note Ons; I've found that there's a voice cycling macro inside of R5's factory arpeggiator that actually does the job reasonably well, or at least, far better than what I've been able to piece together myself -- so I've just been using that.

Also, since yesterday I've actually managed to sort out the two main issues I mentioned (still working with the R5 arpeggiator since it does the job well enough as a template) - putting in a range knob was easy enough, just created a macro that adds +12 to the pitch every time the arpeggiator cycles thru all the notes being held down. Just a matter of a counter and a couple of modulos.
As for the Hold function, I realised that simply putting a gate signal thru a separator will not turn off old Note Ons (not sure what else I was expecting in retrospect), but found that I could separate out the polyphonic gate signal as it comes in and feed them thru a bank of value modules all triggered by the same monophonic On Velocity module, before putting the polyphonic signal back together again on the other end and sending it into the arp - sort of a parallel Sample & Hold circuit that's refreshed every time a new chord is played. I'll attach some screenshots for clarification's sake; and also for the benefit of anybody possibly wondering how to achieve the same things (but for all intents and purposes I found it was just a lot easier to adapt stuff that was already available in the factory library)

As for the different modes of sequencing, I never actually got that far since the ones already put together in the factory arp were fine. I don't mind little glitches in it though, like starting on wrong notes or even the patterns screwing up a bit; adds a little lack of predictability to it. All part of the charm!

Yeah I'd always opt for restarting; though my first attempt at an arpeggiator involved just pressing the one note down and then defining what sort of chord you want to play from that ahead of time using a dropdown or two - proved a little too convoluted though, and also rather impractical without quantizing the pitch info to a particular scale -- which personally I don't like doing unless I have to.

hahaha yeah, I tend to forget as well that the primary level of reaktor is a much simplified environment of what is actually an incredibly complex field of expertise to work in - easy things to forget when I've never built a hardware synth or sequencer in my life

At any rate, onwards and upwards!

here's what I've done:

 

You don't need polyphony in the arpeggiator for that, just a separate module after it that sends every new note to a different polyphonic voice, cycling round the available voices.
The only limit is that the gate can only be open as long as the arp note time. The release can be much longer. But if it's working in poly mode, then no problem, there is no 'wrong' approach as long as it works and is reasonably efficient and bug free.

OTOH, there are possibilities with a polyphonic arp that could not be achieved with a mono one, like multiple simultaneous complementary patterns, or cascades and/or polyrhythmic counterpoint... You could end up with similar effect to those achievable with a delay, but unique and not possible with just a mono arp and a delay... and the potential for a generative intervallic and chordal bonanza of epic proportions!

Time for more research :-/

 

Hey Berlov!
you're right that managing midi input information in reaktor to build a polyphonic arpeggiator is not an easy challenge. I found myself this issue, and abandoned the idea of reading midi in, and decided to generate the note data directly in the ensemble instead of reading midi. This transforms the arpeggiator idea into a sequencer with an arpeggiattor flavour.

I'll be really happy if you find and share a practical solution for this, as it will be very useful for the kind of instruments i do.

If you want to check the final outcome of my personal process with this kind of sequencers, you can check this:
https://www.native-instruments.com/en/reaktor-community/reaktor-user-library/entry/show/11057/

maybe some of the midi processing ideas in the patch can be useful for your future developments

cheers!

Santi Vilanova
www.playmodes.com

 

Look at the older thread that he references in his first post here. In that thread, I uploaded a basic arpeggiator. It demonstrates how to process incoming MIDI via the Channel Message modules. That's the best approach for an arp IMO

 

Thanks ColB,
i'll check it out and see if i can integrate it with my midi processors!

 

I agree an arpeggiator in Reaktor is a lot of work. My most recent arpeggiator is a premiere ensemble (I charge money for it). It is polyphonic, as it also contains chord generators and other stuff. https://www.yofiel.com/downloads/audio-apps/godel5-reaktor-5

 

For talk about:
https://www.native-instruments.com/forum/threads/automatic-arpeggiator.156795/

 

I'm working on a little something - it's a quantizer block that snaps incoming 0-1 range singnals to midi notes played on a keyboard, mapped to up to 5 octaves. This should make building crazy arpeggiator block patches really easy! You'll just have to plug in some low-frequency oscillator as an input (I'll provide an example ensemble using the rounds lfo, but I'd try weird, complex oscillators to achieve more interesting results).
I'm actually amazed nothing similiar exists on the UL (to my knowledge, at least). It will be ready in a couple of days I think.

for polyphonic arpeggiators you'll need a bit of primary processing attached to the core macro, but it shouldn't be difficoult to modify i reckon

 

Hey E.M.!
for what you describe, i think this ensemble i made some time ago is kind of similar:
https://www.native-instruments.com/en/reaktor-community/reaktor-user-library/entry/show/10115/

it uses clusters of waves to trigger notes whenever the oscillators reach 0

 

Wow, that looks nice, I'll check it out!
My design is a little different, and I think I'll implement a way to use the block as a standard arpeggiator as well. I'll keep you updated

 

So, there you go: my take on an arpeggiator block!
Features a latch mode and automatic notes extension to up to 5 octaves.
Since it is a block you won't be able to use it directly with other MIDI equipment: you'll need to hook a Util/MIDI out at its output.
It can also be used as a sort of quantizer, but that's a different story.
Have fun!

 

hey. there is a paid ensemble called Phrasendrescher. you can deactivate the internal chord generator and use it as polyphonic arp.
tough, i have never done it.

 

Thala give a link, please. I don't found anything.
EDIT: Ah - found it on aggregato.
--
Why don't you extract quatsi by Chris List from Koyaanisqatsi.
There is a detailed manual by the author for use this arp on other places.
https://www.native-instruments.com/de/reaktor-community/reaktor-user-library/entry/show/3517/
I use it at last for the Seamonger ONE noisy demo

 

Actually I don't think that diving into that monster ensemble just to hack an arpeggiator is a good idea!
Since @berlov wanted to understand how to implement his own arp in reaktor, here is my suggestion: don't waste time in primary! Primary is actually WAY more difficoult than core. It can seem easier at first, but as soon as you delve into event processing, event ordering, etc it becomes a nightmare of unreadable spaghetti-code.
The way I implemented my block is the following:
1) an array of 120 integer values is used to store the status (1/0, corresponding to On/off) of incoming MIDI notes
2) an iteration is triggered by every MIDI Note On/Off message and each time the Octave knob produces a new value: this iteration reads all the array. For each note that has a value of 1 ( = note on) it reads the value of its octaves (up to the Nth octave, selected by the Oct knob), and writes back that same value OR 2 (that is 10 in binary). This allows to differentiate between notes triggered by the MIDI input, and those activated by the Octave function.
3) Each positive value is copied on a second array, which represents the notes that the arpeggiator will play. An integer value stores the actual size of this array
4) On each clock tick a counter is incremented. This counter ranges from 0 to Size -1 and is used to read the correspondig position of the second array.

Hope this helps

 

That sounds like a good approach. I went by a more efficient but much more complicated route, then came to the conclusion that just iterating over all possible notes each time would probably have been a better option. It sounds like a lot of processing, but because it only happens when notes are played or released, the overhead is not really an issue.

My approach was to use a map of the full 128 to track active notes, but with an additional array of a single octave, and use modulo 12 to put every new note onto that keeping a count of duplicates. Also keeping track of the highest and lowest active notes. Then a sorted modulo 12 array can be kept and the sorting is much cheaper because only maximum 12 items are being sorted rather than 128.

Just brute forcing it would have been simpler

 

sure thing! sorry, my intention more was like: maybe he just wanna use something like that for having quick results, instead doing sciences.

 

Yeah I used to be a bit of an optimization maniac, but lately, as long as it works and it can save me endless hours of rewiring and debugging, I go for the most straightforward route! I wonder if R7 will finally implement core iteration...

 

i did the something very similar recently, modulo then sort, except i did in primary with old bubblesort from UL, but i am very at home in spaghetti code. it is/will be a first order markov chain for chord training and crazily it works just fine just in primary. after not few ugly abortions trying to do almost anything with midi, it appears getting it sorted in order of note number to voice right off the bat alleviates a lot of it. at least up till this point

that said, is anyone familiar with the arpeggiator on the kawaii k500s? now THAT is an arpeggiator worth aspiring to. not saying in reaktor, but also not not saying that