Limit on #IC's?

While working on an ensemble, I suddenly don't get any events from new IC's I create, unless I remove other ones.

Needless to say: this kinda breaks my workflow. Is this supposed to be like this or is there something I need to know?

I must have something like 15 IC's in there now, but i was planning on using some more, and it would seriously compromise the oversight if i couldn't do this...

Thanks for any tips,

Nicolaas

 

? you can use hundrets of IC's and more. I remember that you have to rename the IC's which means there is a limit of IC's with same name.

 

That's strange, because this was an IC with a unique name. In fact, there were two (with different names), and once i deleted one of the IC's elsewere in the instrument, one of the two in the macro i was trying to set up started working.

But i was experimenting a bit more yesterday with adding new IC's, and on the top level of he instrument they did connect. Could it be because the one i'm having trouble with is burried in too many macro's so that the path gets too long or something?

Anyway, I'm glad it's something that can be fixed, even though it probably means that i have to adapt my structure to this situation. Now i just need to figure out what the problem is...

 

I found the problem: there seems to be a built in step filter in the IC code that blocks events with the same value as the last.

See the test ensemble: the button state is passed when in toggle mode, but not when in trigger mode.

Is this a bug or a feature?

 

I confirm this step filter situation, I recently built a little program change triggerer that I had to hard wire to the other instruments if I wanted to be able to recall repeatedly the same snapshots. In my case it wasn't such a big deal, but I can imagine other situations where it is a real pain in the butt.

 

There is a workaround: you can use a flipflop so that there's a different value for each trigger, and then use a value after the receive.
It's still a PITA though, but i'am glad i don't have to hardwire all this.

It goes against the concept of reaktor, but i'd be happy if there'd be more flexible ways of feeding data around in a structure then through wires. The quickbusses in Core are a step in the right direction me thinks, but i think it could be taken further. Anyways, we'll see what future brings (and for the moment, that certainly isn't R6 )

 

Well, for me it seems that in your case connection between two IC sends works only when first IC send from Router sends values together with events to second IC send, but not events themselves. When you connect Router straight to Event Watcher it sends events, but value is always 0, while when you press Toggle button it sends values of 1 and 0 and events. I understand that's how Router the work of Router, but it seems that IC sends can receive events only with values. I'm stuck.

 

I'm not entirely sure if I get you right here, but it seems to me that indeed, the IC's detect values, not events, and that they only fire an event upon a value change.

I'm not sure either if I get the underlying logic to justify this behaviour (in fact, I'm sure I don't get it), so that's why I rather see this as a bug (unless someone could point me to a case where you really need the thing to behave this way, and not like an ordinary wire).

 

Yes, that's what I was trying to say. I think it's just the way IC sends work, it doesn't look like a bug, but still..

 

Using many send/receive connections, perhaps splitting and perhaps steered by IC-send/receive and internal connections is not the simple part of REAKTOR.
Their behaviour is logically but they do not work allways like normal user is thinking.
So you cannot get a general answer. F.i. the behaviour in my modular m1 is very tricky using send/receive and IC-send and internal connections.
You have to study the behaviour with very (very!) simplest examples. F.i. it is important if you use polyphony (nevetheless IC-sends are monophonic!) and how many splittings are behind sends.
Then there is the problem with the internal step filter (a well known behaviour). How do you send more than one event with same value? It is simple to solve when you use only positive values a. Add before the IC-send an event corecell which has two outputs. The core cell sends a and -a. Just behind the core cell add a primary event merge module and connect it to IC-Send. Add behind IC-receive a separator which filters the negative values. So you get every event with same values.
Another problem is when watching internal connections with event watcher: there seems to be some events which are shown by the event watcher but only one value is used! There is a logic system in it but as i said before it depends from the application.
My tip is: test special situations.

ciao herw

PS: send/receive are made for audio and event connections mainly for floating point numbers.
IC-send/receive connections are mainly made for integer values and are only events.

 

I know, but it's not the only kind of event. Sometimes (as you probably know) the value of an event does not matter, it's the fact that is there that's represents the data. In this case you can send events that all have the same value.

IC's do not allow this kind of data transfer, and i think that is or a bug, or a shortcoming in design.

 

It is no bug because the sense of the IC-send is to control something. So if something is controlled why should it get the same value again? But in my last post i described a solution too.
As Ernest writes better you can use normal send/receive connection if the event are no control events but normal events.

 

Please, take a look at attached pictures, did I make it right? I don't know if it's right in terms of polyphony. And thanks for explanation.

 

We posted at the exact same time, i didn't see your reply.

Thanks for your explanation, there's nothing about this in the manual- could be made into a better known behaviour if they'd add that.
Anyways, thanks for your tip!

I thought Send/Receive were mainly for OSC, and that IC had replaced the Send for connections in the same instrument.

nicolaas

 

no - IC-send/receive modules are only monophone and no audio! So you cannot replace send/receive modules with IC-send/receive.

 

Interesting. So do you think there is any difference in CPU load between the two? I've been constructing this ens using all IC's and no Send/Receives with the intuitive logic that if it says "internal" and you want to use it for something internal to the instrument, it must be the best option.
The manual is not really helpful on how to choose between them...

 

but only in the same instrument - IC-send can be used in an ensemble so they are able to send from one instrument to another!

 

Check this as well:

http://www.native-instruments.com/forum/showpost.php?p=503435&postcount=18

and:

http://www.native-instruments.com/forum/showpost.php?p=503477&postcount=19

 

sorry the links base upon a wrong research. The IC-send are working very consequently and logically.
You have to study the idea of their behaviour - every value you send has a „bandwidth of values” f.i. an integer z has a bandwidth of z-0.5 ... z+0.5 which means that the 0 has only a bandwidth of 0 ... 0+0.5.
As i said in another post IC-sends are mainly made for sending control signals mainly integers.
The behaviour of bandwidth is used by knobs and mouse areas etc. too.

The problem of such behaviour is that it is very logivally but no one thinks like this. So a manual has to point to this.

ciao herw

 

Okay, thanks for explanation! At least now I know it.