Wireless receive module... like a switch?

I'm too lazy to run a test of this, so I'm hoping someone knows from experience.

As we all know, the wireless receive module accepts multiple connections, which can be chosen from a list on the panel. When a different input is selected, Reaktor resets itself as it would if a switch were triggered.

As an ensemble amasses more and more switches, changing a switch state freezes up the program for an increasingly long time. Do wireless receive modules contribute to this problem, even if only one input is checked in the Properties dialog?

If so, I say "Blechhh!"

 

The state of a wireless connection, unlike a switch, does not play into deciding if part of a structure is active or not. Therefore, I'd say most likely it does not affect anything. The reason why switches do this is that the point of them is to enable people to disable parts of the structure which are not needed, hence saving CPU. When you flick a switch, Reaktor has to decide which parts are needed, turn off the old ones, and turn on the new ones.

Forgive me if I missed the point. Piss tired.

 

I'm afraid this isn't the case. I just ran a test with two modules feeding two Send terminals, and one Receive terminal. When I switched between the two Sends in the Receive panel, the modules feeding them activated/deactivated.

This leads me to believe that Receive modules, even when used just for their single-input wireless capabilities, contribute to the switch checking delay. So I can't use them anymore, as my ensembles are already bogged down by enough switches.

Friggin frak. Here's to wire clutter!

 

Hi EMISnode,
the send-receive modules are very interesting. Their abilities and possibilities are described not sufficiently, i.e. one must experiment even. In particular the sequence of the entries is strongly confusing; you must try out by yourself; also a description uses few (tip: exchange the order of the entries) a large advantage beside the not necessary connections in the structure is that the number of the entries can be much larger than 40. I.e. one can use in the adjustment of "switches" in contrast to the genuine switches more than 40 switches! Sometimes it seems to crash R4 - not sure: you have to make experiments.
ciao herw

PS: BTW why do you need such many switches? If you want to use them in a matrix - there are other powerfull possibilities.

 

What would these be, Herwig?

 

1st thought:
If you use a matrix you have to consider every possible connection between every source and every target &#8652 many wires in the structure
2nd thought:
how many wires you can really use?(only same number of inputs!) &#8652 constructing virtual wires!
3rd thought:
how to construct virtual wires: an address bus to call receive modules
4th thought:
possible application? modular synth

ciao herw

 

I usually compose and perform in the standalone app, so I had to create a flexible channel strip mixer to handle signal routing and generic fx, which I use in every project. Every distortion circuit, compressor, eq band and send requires a switch, multiplied by the number of channels (typically 4 stereo). The sends require switches for pre- and post-fader funcionality. If I was unable to turn things off, the mixer would eat a third of my CPU by itself.

Couple that with one or two switch-heavy synths and a percussion sequencer, and not only is my CPU maxed, but clicking a switch can take up to 2 seconds.

Eventually, all of the synths I use will be custom built or modified, and they will have minimal switches, so the mixer will be the only switch-heavy instrument. The delay should be tolerable then.

But this still negates the possibility of using wireless connections, as any delay at all is too much.

There should be a simple Receive module that has no switching functionality. Moreover, one should be able to isolate Reaktor's switch reset behavior to a specific macro or instrument.

 

yes - i understand

ciao herw

 

As I've said several times, the send/receive functionality needs to be torn out, breaking existing ensembles, and redone.

 

James Walker-Hall taught me a lot about the use of event signals and clever math in mixers. A lot can be done in the event-math domain with all of your controls *before* you hit the audio signal and this saves a lot of CPU. In theory you should be able to make something that has one mixer module for each "buss" of the mixer (L, R, effect 1, effect 2, etc), and that should be the only thing in the audio path (OK, maybe 2 mixer modules for pre/post fader effect sends). Perhaps you know all this already, but if not check the mixer on CL-909xi.

I agree though, a simpler wireless connection option would be nice, I don't think I've ever made one of my receive modules visible!

- CList

 

I will definitely take a look at your mixer design for some pointers. My mixer does it's absolute best to keep the audio signal at the very end of the control chain, but I'm sure there is always room for improvement.

It has 4 stereo channels (switchable to mono) with 3 stereo sends per channel. Each channel has distortion, bit reduction, a 4 band parametric eq, a cutoff/resonance filter and a compressor. With all of those frills switched off, the mixer consumes around 5% of my 1.5Ghz Powerbook's cpu. That's not too bad for me. It's the effects that really add it up, so those need to be switchable.

By the way, I plan on releasing the mixer in the user library soon. I just have to document it and it'll be ready.

 

Hegel actually uses receive modules for audio switches throughout. The final version now approaching beta does some clever things to simply the design, in partiuclar, the receive modules have an internal connection to a list module which then controls event logic. Sometimes the list module also drives a controller module and the controller module then has an internal connection to other switches. This made it alot easier to build complex switching paths.

Actually I've been very happy with the improved handling of internal connections in 4.13 where previously they all disappeared occasionally, the current release is stable. It took 18 months to reach a stable state. I'd much rather keep the stable software than have a redesign and have to wait another 18 months for it to work again! If anything I'd like it internal connectinos could provide polyphonic connections between instruments, and more things like lamps and so one had internal connecitons options, so then lamps could be used instead of controller out modules for internal connnections.

 

I just can't imagine how adding a simple 1 port Receive module would require a total reworking of the connections system, although I agree with John that it is rather convoluted right now and could use an overhaul. I think it could be done without breaking backward compatibility though.

 

Oh Geez

Ok I feel a bit sheepish now. I started this thread under the assumption that switches, in of themselves, contributed to the "connection reset" delay that occurs when a switch is clicked, a new connection is made, or an instrument is muted.

When I found that the Receive module behaved like a switch, I immediately assumed that having them in an ensemble, even if they aren't being used as switches, would contribute to the delay.

But after some review last night, I've come to realize that switches and Receive modules do not contribute to the delay at all. I used to think so because whenever I had lots of switches in an ensemble, clicking one of them caused a long delay. But that was only because the ensemble also had a lot of audio connections, many of which happened to be going into the switches.

To wrap up, I've concluded that the number of audio connections is the only significant factor (other than CPU use) that contributes to the "connection reset" delay. I'm sure event connections add to it as well, but not noticeably. One could have only one switch in an ensemble, but if there are a large amount of audio connections, clicking the switch would hang up Reaktor for awhile.

This means that I can continue to use Receive modules as liberally as I please, which I've only ever used for event signals. That's the good news. The bad news is that I wasted an hour last night replacing all of the Send/Receive modules in one of my instruments!

 

If it makes you feel any better, I've got good reason to beleive that this audio activation/deactivation delay problem will be fixed in the next release (though I have no idea when that will be).

- CList

 

harm ;-)
ciao herw

 

Mmm, tasty. But if this, and other performance enhancements (for the Mac, mostly) don't make it soon, NI may forfeit my upgrade fee. MAX/MSP is looking really strong now...