Polyphony without midi

It seems polyphony in Reaktor is inherently tied to midi, but I'm not sure as I'm quite new with Reaktor. My situation is simple, I have some sort of sound producing device that I transmit events to. These events should then trigger a new voice, with phase resets, adsr etc. Given this simple structure:



How can I accomplish that using the pulse event port? The modules are all polyphonic, it seems. Thanks for any help,

Regards

 

This could be polyphonic, with some changes:
0. Build it it inside an instrument
1. Change the pulse input to a gate.
2. add audio voice combiners on the output.
3. In whatever instrument is generating the pulses, route them into gate outputs.

Audio, outside instruments, is monophonic. Instruments can be polyphonic, but their audio outputs must run through an audio voice combiner because outputs are monophonic.

 

You can use the "To Voice" module (in Auxiliary section) to send events/audio to individual voices. You'll have to build something to keep track of which voice to send to, but no midi is needed.

 

Thanks for the reply. And yes, it could be polyphonic if it relied on midi (gate, notepitch, etc.) but that would require me to send midi around internally in Reaktor? I just read somewhere on the forum, a guy had a similar problem and people suggested not to go for this approach. Anyway thanks for the walkthrough, much appreciated.
Also, I noticed you omitted the lfo-phase reset in your mark up. Is this possible polyphonically - ie. do the reaktor lfo's have separate phase?

Hmm, yeah this was kind of what I was thinking, but maybe it wouldn't be that complex - a wrapping accumulator should be a basic voice stealer?

 

I was using Reaktor 6, you're still on Reaktor 5. I used library macros. If you use the sync input on that macro, it will restart the LFO cycle just as it did in your example.

And yeah, you can have a bunch of different pulse inputs, and use "To Voice" modules to pass triggers to different voices. So yes, you can avoid MIDI. The question is, do you have a real reason to want to? I don't see any advantage to it. It's very easy to send MIDI between instruments in Reaktor -- you go to the sending instrument's properties, and there are two ways depending on which version you're using. Reaktor 5 has midi routing in the title bar of the instrument IIRC, and Reaktor 6 it's in the instrument property under connections.

I'd be interested in knowing which forum post advocated against using MIDI. This is definitely not a situation I recognize where one method has a clear advantage over another. In fact I'd say using audio or control inputs to do it is more complicated.

 

Yes it seems. But will it restart the cycle independently - ie. per voice?

The reply by Contrast here for example: https://www.native-instruments.com/forum/threads/event-to-polyphonic-midi-note.77476/

The specific reason i wanted to do it this way, is, that I will have N amount of clones of the instrument i posted, with separate event triggers. Using events and wires seemed to be easier than internally route, say, 20 midi instruments around.

 

Yes, the LFO cycle will restart with every gate, per voice, so different voices will start cycling in the stereo field separately.

I have an example I'll upload this evening -- ran out of time this morning: It uses a Geiger module to generate gates and S&H to pick random pitches. I can set it's polyphony > 1 and it will send multiple streams of notes to the instrument, which will play them up to its polyphony limit.

As for your specific case, I'm unclear what 'N amount of clones of the instrument' really means in this context. If you want each instance of the instrument to have different knob settings, then you have to have separate instruments, and if you have multiple independent note/gate sources, by all mines wire them up.

In general it's simpler and easier to maintain to use polyphony to duplicate identical instruments. If you have multiple independent note/gate sources, you can put them all inside an instrument and set its MIDI routing once.

I wish you would explain what the high level end result is that you're trying to achieve. Then people can suggest the most direct and efficient way to accomplish it. Right now we're operating in the dark, and working from minimal information.

 

Swell.

Thanks, I really appreciate it.

It means just that, the structure will contain a lot of instruments similar to the one I posted.

I definitely agree, but this specific use case requires different settings per-instrument.

Sure, I'm sorry - I'm used to people only wanting to deal with the abstract part of the problem, not the implementation. It's a naive neural network. When a neuron fires, it makes a sound - generated by this instrument. There may be many successive firings, thus the need for polyphony. There exists many "neurons" though (N), with different settings. In reality each neuron represents a physical speaker arranged in a specific room, where each speaker/neuron has properties bound to its physical location.