Midi->IC->Switch problem (Event order and Global event resets) HELP!

Hi all, and thank you in advance for your help!

I've been stuck for some time with a building problem that I can't find the solution to. I have read the manual, and I have read the threads in the forum regarding GRE and event order and initialization. Still, I cant figure what I am doing wrong. Please be gentle since I am no expert builder...

*PLEASE NOTE* that inside the .ens, there are several text boxes with detailed descriptions of what I intend to do and what the problem seems to be. Inside the .ens there are also 2 event watchers (including the one by Clist)

The basic idea is,
I want to switch between different sound producing modules "on the go" (in the example I put oscillators for the sake of simplicity, but they will be a lot of other modules in the future) by means of midi values provided by the Note In module, scaled and sent to an IC send controlling a Switch.
It is important to note that I DO WANT to use SWITCHES, in order to cut down as much CPU usage as possible. (In the .ens example, it seems stupid to get into the whole GRE/Switch issue because some oscillators, but then I intend to replace those oscillators with a lot of other stuff for which is imperative to manage CPU consumption.)

The thing is that no matter how many combinations and dispositions of the EventOrder and other event modifiers I try, I still can't get it to work properly.
The functioning of the IC controlled Switch and the functioning of the oscillators are out of sync when the switch is changed. It does not happen when the same note repeats or no change is made to the switch, which I believe is a very clear symptom of GRE/Event order issues.

I was trying to somehow control the order of DIFFERENT events from DIFFERENT sources and block unwanted event triggering in order to solve this (by this I mean making sure that the control to the IC/Switch signal was sent first and then the Pitch and Gate events), but with no luck. If you check the EventWatcher connected to the outputs, you'll notice that the event ordering gets reversed when the switch and GRE do their things. I don't know why, since I placed Event Order modules in the first place.

The only thing I came up with, is using an event delay from the user library applied to the midi fed into the oscillators to force the switching and the playing into synchronization (around 45ms of delay!), but I dislike this because it limits the capacity of switching the sources with relative speed. At one point the oscillators will start failing in producing the tone.

This is a very annoying error wich causes unwanted sound from the previously used source.

Is this really a GRE/Event related problem, or maybe the IC connections and the Switch operate at a lower speed than the rest of events, like the gate and pitch? (with 45ms aprox of delay)?
And of course the obvious question... How can I make it work?

Anyways, you'll surely get a better picture by taking a look at the .ens.

Salamanderanagram, Clist... Are you There?

Thank you very much!

 

Anybody?

 

i don't think is a good way to use switches unfortunately. you pretty much don't want to use a switch any time audio will be playing.

there is a core method that allows you to turn off un-used components without causing a GRE, but you'll have to program everything in core to make it work properly.

PS - i too a quick look at your code and no offense but there is a lot of unnecessary stuff happening in there - for example you often have an event impulse macro directly before a separator that is filtering out all of the 0 events, so why bother triggering them in the first place? then once you're not triggering the 0 events, you don't need the separator either! i only really checked out the event stream order macro, but i was able to cut out a lot of stuff without affecting the workings of the macro at all.

 

This might help. I replaced your MIDI INPUT module with a Core Event Cell. Core Event outputs seem to handel GREs better, and they output to Regular Reaktor top down out of the modules.

 

Salamanderanagram: Thank you for you oppinion, and no offense taken at all! I know that there are surely plenty of errors, I do not consider myself an expert builder at all. The thing with the separators that you mention is that I was getting a lot of zeros in the event watchers. Since some of the alternatives that I tried without succes, had to do with the sound stopping from the oscillators after a brief time, I thought it had something to do with those events with sent value "0". So I thought of terminating them there in the separators.

owen_vallis: Thank you very much for your help! But, although I do see the events in a more ordered way than before, and the macro you've made surely is more simple (and I therefore suppose, efficient) The tiny bits of sound from the previous oscillator can still be heard.

Is really the switch option a "no-way" thing?

Once again, thank you for your help!

 

I think it would help if you explained what you ultimately want to build, maybe there is another solution than using switches or programming the ensemble in core?

Also, I think that even though audio events use a lot of CPU, if you block an audio event with a router, it will still blocks events from traveling upstream and can save CPU.

Perhaps you can find ways to save CPU in your other structures so that you can just use a Scanner/Selector module to switch between signals instead of a switch?

 

yeah, i regularly find egregious event programming errors in my own code, so you're not alone! i just thought it might help to point that out.

the separators may indeed be helpful, for example, however, there is no reason to explicitly trigger a zero heading towards said separator if the bottom port in un-used.

i was able to fix your event orders but the sound glitch was still occurring, i'm not sure you can reliably flip a switch in this method without causing problems.

 

i think my first UL upload, optimus rex, uses switches to turn audio sources on and off, but i can't remember. one of my early uploads certainly does, but i have no recollection of how it was done. probably the coding is pretty ugly but you could take a look.

 

My idea was to send midi out data from a music notation program (i.e Sibelius or Finale) into reaktor with the intention of programming complex glitch-type rythmic sections of several layers at once.

A very simple example of this would be the following: From the notation program, I would create a staff that will be my "rythm" for a given instrument, and inside reaktor, receive the midi gate patterns and feed them to a set of samplers with a snare drum, for example.
Then I would create another staff for programming the changes of effect or sound source for that instrument. For instance, if my "instrument 1" is a snare, by switching between types of samplers i would have a lot of control within individual notes to switch between sounds (like simple sampler, grain, loop, etc...) in a musical and organized manner.
That's the funciton of the "midi pitch scaler macro" for instance. Supposing that I'll have 12 different sound sources or effects on a given instrument, if I scale the midi input that comes from the second staff of the notation program into one octave, i can write easily inside the notation program pitches within one staff to control the switching of the instrument.

The idea of replacing traditional step sequencers and midi programming "a la piano roll" with music notation has a lot of benefits for me. For instance, the easy implementation of polyrythms, odd time signatures and time signature changes. Being able to visualize and edit the score as if it was an orchestral one, and not to mention the ease of managing thematic/derivative material.

Of course, you get the idea that you can then create more staffs within the score editor to continue to "modulate" the same instrument.
For example, with another staff added to the "group 1 instrument" I could modulate the pitch of the samplers, or the loop lenght, or whatever.
Then, I would repeat the process by creating new groups of staves for adding layers of instruments.

Being this said, it is clear that CPU consumption goes over the roof if all potential modules are turned on at all times. That's why i thought of switching, so that only the modules selected by my "second staff" in the notation program are turned on. Saving a lot of CPU.
And also, that's why I intend to "order different event sources in a definite way".

 

After several experiments and tryouts, i've come to the conclusion that using switches for theese kinds of purposes is indeed just impossible. For instance, i've found that the potential speed of the switch is somewhat low (they work at a low speed). Above a certain speed the switch fails. It is impossible to control the switch in a rythmic manner without having inconsistent tempo results.

 

word.

 

only two short remarks:

• midi messages from computer keyboard or extern midikeyboard are different; midi messages from QWERTY-keyboard have only a GUI-clock-rate of 25Hz.
• IC-send modules have inside a step filter. So they will never send two identical values.

ciao herw