An "event bus system"

Hi there!

I have Reaktor5 here and got into trouble with a new synth I'm creating. I have loads of modulation sources there and thought it would be nice to discouple the panel and modulation related stuff from the actual audio processing so that all the processing can be completly done inside of one core audio cell.

To decrease the number of cables for all my modulation sources and destinations I thought of a bus-system: Two cables transfer (nearly) unlimmited numbers of modulation events.
The first cable is a control cable, to transfer the number of the following event. The second cable is the event itself. So what actually happens is: You create an event by pressing a button and this event goes into an encoder. The encoder looks like the first pic attached. It generates the number (say number 0) of the event within the "bus system" and sends it through the control-cable. Afterwards it sends the event itself through the data-cable.
The decoder looks like the second file attached. It does the whole thing the other way round: It routes incoming events according to the number of the control cable.
It would be pretty usefull like this, you only need two cables for loads of modulation fun.

The problem is: Sometimes it works, sometimes not, depending on the event-source I couple to the encoder. I guess there's a problem with the signal flow, which is a bit strange to understand for me... maybe you can help me with this - I have no Idea, where the problem is. Some outputs of my decoders only pass constants like 82 or 9 - no idea, where they come from (the source, always creates valid data - just after it has gone through the bus system its rubbish)
I tried to rebuild the problems in my synth in a new ensemble, but no chance. I think the "signal flow" creates most of the problems here, becourse I do not use simple faders as modulation sources, but complex macros full of stuff.

One idea: I'm not sure, which signal arrives first: The control or the data one, both should start "at the same time" (after each other) in the encoder. This might be part of the problem... There must be an "unsave" part in my structure.

Thanks for any help or hint,
Bääääär

PS: I also attached a macro with a simple bus system inside. I works there, but maybe it helps you to understand my bus system and to find the "unsave" part in the structure.

[Edit:] Sorry, didn't see that there's a matching subforum... Maybe someone could move my topic...

 

Hi again,

I did a lot of testing now an finally managed to improve my bus, however it is still not working as needed.

You will find a *.ism file with this reply. Inside, I set up three of the knobs in my new synth along with an encoder for them. After the two bus-wires you will find the decoder with three meters.
What happens is: All values get sent now, but with two problems:

1. When Reaktors calculations are turned on, no initialization event reaches the meters. I have no idea why.
2. When you use one of the knobs (let's call it knob a) an afterwards another one (knob b) the first event send by knob b is routed to meter a. After that, the event is routed to the corresponding meter (b) as expected.

At least I got closer =)

Thanks for help,
Bääääär

 

Do you need one impulse for pressing (on -> off -> off) on cpu button?
same for snapshot recalling?

 

why don't you use this: event bus

ciao herw

 

Yes, it doesn't send any value when I turn the cpu switch on, the same problem appears when a snap is loaded. (Hope that's what you meant). You can try out the ism file that I uploaded in my last post if you like.

well, I didn't know an event bus already existed... well, fine I'll have a try. But hey, it's a good lesson to get my version working - so maybe you can still help me?

Greets,
Bääääär

 

well read the event bus manual and study the structure.

ciao herw

 

I took some time to dig into this event-bus you wrote about. Sorry, but I have to say: That's actually not, what I want to do... I do not need the flexibility and the possibility to route more than one source to a single modulation target. I simpy want to send loads of different events via two wires. I could use send/receive instead, sure, but the point was to learn how it could work and thus to learn something new about the reaktor functionality.
But thanks anyway, probably I'll use this nice project in another ensemble someday.

Greets,
Bääääär

 

Have you read this recent thread?
http://www.native-instruments.com/forum/showthread.php?t=103687

It goes into a lot of detail on what I *think* is the same topic and show a couple of different strategies for how to do it.

Cheers,
CL

p.s.
Also per some recent threads, taking something like a oscillator or filter and doing it in core - when the same functionality exists in a primary osc / filter - will most likely waste CPU vs doing it in primary, but if you just want to learn core, then it's fine...

 

the idea of using send-receive is the same as to use only two wires. You have to use only half of the structure.

learning (core) by doing is ok

ciao herw

 

simple solution to demonstrate the idea


ciao herw

 

Hi herw!

Thanks for your reply, that's exactly as I did it using primary structures. I noticed an error in my version: Simply delete the "value" and the "order" module after the two big merge-modules in the encoder macro. The problem 2 (mentioned above) is solved by this.

The strange thing is: In your version, one of the meters (the right one; address 2) is receiving an initialization event, the others don't. In mine (using the same logic but primary structures) no meter ever gets an initialization event. Where's the difference between our two versions? And how can it be fixed?

Thanks anyway,
Bääääär

 

the difference is that the last input of the merge module sends the intialization.
Normally i would block out the initialization inside of a core cell and would use an event core cell for merging. I uploaded it because i thought you would like to see something in primary mainly.
The example is very simple and there are many problems when using many sources. I think there are different methodes to construct an event bus.
You can see what i mean when you have a look inside of modular m1.
Perhaps there are very simple solutions depending on special applications.
It is a hard way to solve such problems for special ensembles - so a tried to give a general answer or an idea. Nevertheless you have to find your own solution.

ciao herw

 

I don't know how your entire system is supposed to look like- how many sources how many destinations- but one possible solution can go through polyphony. A had a comparable problem: one unwanted event coming from the wrong place and that hangs in a value module.
http://www.native-instruments.com/forum/showthread.php?t=104310

Also, if you want to be moving more than one control simultaneously... it can be straightforward to let that happen simultaneously in the system. Polyphony lets you do that.
I have left all your structure in place in the attachement, just added my things.. and raised the number of voices.

 

enough - 100, 200 ?
my upload here is only a very simple example. Many sources requires clever solutions.

special application - special solution i think. There is no king's road.
ciao herw

 

Well, my application wouldn't work well with many voices, but I allready used this method for other designs. Thanks for the hint!

Bääääär