reducing wire weirdness

So the day is come....

I´ve working on a Ensemble which doesn´t accept any more inputs.

Is there a solution to merge diffrent wires from (for example) 4 On/Off Buttons into 1 wire put this one wire into a core cell and then and then split the signal back to 4?
So that it works like 4 connected wires?

Is this possible? With a 1 Voice ensemble ?


Any help is greatly appreciated.
See attachments for more info.

 

let me ask this do you want the selection of one to turn the rest off? or do they need to work independant?

ok, the first one is simple a selector, sends out 1,2,3,4, etc

the second one send a gate on/off (0-1) to all outputs. The selected button is gate on, all others will be turned off. I think this would be called Radio button? I have snapsave there but you could install that anyway you would like.

I would consider food this for thought, I haven't tested it out nor check to see if it gets messed by up by global resets, just hooked it up in a few moments.

 

Of course this is possible, not trivial but very interesting.
First let me say that you are just beginning to plan an event bus. There are limits to the number of inputs of macros especially core cells (40 inputs).
So if one is planning to create an ensemble which uses f.i. only a panel macro and one or few core cells you need an event bus which is able to tranport several event signals with one or few wires.
If you want to do this every source and target has to have an address if you want to create it very flexible.
So sending a value from a source means sending an address too.
There are two main possibilities to do this:

• every value from a source (maybe a range from 0..+1) adds the address number: f.i. source 1 sends value 0.567 so the bus get 1.567; source 3 sends 0.123 so the bus get 3.123 etc.. The target has to split address and value again.
• a source sends value and address on two busses: one for the value, one for the address. The only „problem” to send them one after the other directly is simple to solve with an event core cell: the core cell has one input (the value) and two outputs (one for the value, one for the address). Every value from the input creates an event with the address by using a latch module.

You can merge all such two events by internal connections; you don't need any wire harps
On the other side it is not trivial to analyse such values if you want to mix some of the events (or add) for modulating something. But perhaps you don't need them.

Interesting is that you can use permanently streaming on a bus not only for isolated events: so it is possible to transport several streams of LFOs, ADSRs, knobs, midi events etc. only with one bus.

I have made such an event bus in 2007 but only a few are interested to read the manual and to use the ensemble GREYHOUND - so i deleted it .
If there is interest i can upload it again.
I used the idea for a modular synth.

ciao herw

 

I lost my copy of grayhound some time ago, didn't realize it until I needed to build something based on the event bus. Had to invent something of my own, would have been nice to have grayhound as a reference.

 

Thank ya two for the helpfull comments. Youre both amazing. This clarify a lot.

1. Horuschild:
for Example i have 4 simple On/Off Buttons connected inside core Cell to activate independent Mixer Channels. So if you activated Button 1 and then Button 2, the first one should be stay activated until you deactivate it manually.
Simple Routing like 4 independent wires...just with one wire.
I´ll have a look to your structure in next hours.



2. Herw:
thanks for this detailed description. Now i know exactly what i´m looking for.
I can´t imagine why no one was intrested in "greyhound". I have it already and will have a closer look. Maybe you should upload it again for all the other intrested people. Not everyone can follow such professional building skillz as fast as you migth expected. Me included.



I´ll make some thougths and try to come up with an eventbus.



´til later.

 

CList does something like it in the beatlookup ens to send all panel data over one wire. Maybe worth checking? He uses a code for the adress. Like 10001-10009 is for granular parameters, 20001-20009 is for playback parameters, and so on. I think this is an elaboration of herw's idea, because, it allows you to easily read which data are being passed, something that is less obvious if you have 1, 2, 3, .... (imho)

Nicolaas

 

upload to user library

GREYHOUND / EVENTUS

ciao herw

 

i think that CLists solution is another concept.
The main idea of greyhound you will find in the ensemble simple.ens of my upload.
It is a real bus in the sense that you can patch from all sources to all targets.
F.i. you can modulate several targets from one source AND you can modulate one target from several sources simultaniously!
In the attachment two LFOs with different frequencies and different amplitudes are modulating one target.

ciao herw

BTW: the upload contents two short manuals (english-deutsch), the demo simple.ens, an „empty” ensemble filled only with an event bus to start with your own ensemble and greyhound.

 

Yes, I see. Interesting concept...

 

Ahhh, a subject dear to my heart, I love bussing events...

Before I start, let me say that the term "address" can be misleading as it sort of implies "where the event is intended to go". It might be better to think of it as the "event source address". Since all the receivers will be receiving all the events, they can each be set up to filter and route whichever ones they like. In the BeatLookup I call the address codes "Action #s" - but that's a really bad name!

As mentioned, I use a different method from herw, but I think it's really just a matter of personal choice. I will say that I'm not a fan of having two separate event lines one for address and one for value as the possibility of them being out of sync or timing incorrectly seems too high. The idea of adding the address to value and subtracting it later is a good one, IMO as it nicely packages the address and the value into a single event.

My way of doing it was to send pairs of events down a single wire - the first one is the address, the second is the value.
Since the addresses are all in the > 10000 range, it's easy for the receiver to know which are the values and which are the addresses in case there's ever a syncing issue where multliple values come in by accident. Still, I take care to make sure that no value can ever be generated without it going instantly into the "pair with address" macro, and so no single value should ever be sent through the buss without it's address event being sent in front of it, and since the address/value pair are always created together, there's never a problem of values from/to different addresses getting "interleaved".

The advantage of this approach over the one herw describes is minimal, and the downside is that it has a bit more complexity and the events are not as neatly "packaged" as the "add the address to the value" method. The advantages are:
* you don't need to worry about the your event values since they can be in the range +9999 ... -inf
* you don't lose any floating point resolution in your values, which could happen if you add a large address number to the value. If you have a value of 0.12345678213, and you add 10000 as your address to make the value 10000.12345678213, you've added digits and floating point math won't be able to hold of those values, so you might get 10000.1234567, and then you take the address part off at the other end of the buss and you're left with 0.1234567. A minor point, but still something to think about.

The trick to my approach (or just about any of the approaches described) is going to be that you want to make sure your values get sent correctly when the ensemble first loads up and Reaktor does it's first initialization. In this case, you might have a panel knob initialize and send it's event *before* the constant module that's used to set the address. In this case, the address would be 0.

Consider the attached gif macro that shows both herw's way and my way of creating a address of "100" for the knob...
(note also the way I "latch" the value in the herw method; this is always a good idea as it prevents an extra value from firing when an initialization occurs. Another way to do this would be to simply put the "add 100" inside of a core cell).

The problem with both of our structures as shown in that gif is that on start up, the knob may fire it's initializing event before the "100" value event fires from the constant. For the rest of the lifetime of the instrument this isn't an issue because 100 value will be set, but on startup, it is an issue.

To avoid this, we should *not* use output 1 on the order modules. This is because output 2 of the order module will fire *after* all event-source modules have initialized. So even if the knob fires it's value first, the knob's event will:
1. Go to the unused output "1" of the EventOrder
2. sit in the Event-Order module until all other event-sources have fired
3. The Constant of "100" fires it's event as part of step 2
4. The event-order module sends a copy of the knob event out port 2
5. The event-order module sends a copy of the knob event out port 3

...and the event is guaranteed to have a proper address, even on instrument start up.

I've attached a zip file with the encoding macro (which has to be done at primary level since a core cell cannot send out two events when it receives only one), and the decoding core cell (with a couple of addresses hard-coded, but they could easily be done as input parameters).

Cheers,
CList

 

Great trick, ever thought of that! That'll probably save me some annoyance in the future! Thanks for your explanation!

Nicolaas

 

me too

my concept uses address in the sense of "where the event is intended to go".

thanks for your detailed explanation (years ago too when core started)

An interesting detail is in my concept, that i don't send the event but the change of the event. The receiver has its own memory. So it is possible to add several events to the same receiver.
Adding the action number and value is problematic when using a value range of [-1...+1] f.i. when sending LFO datas.

ciao herw

PS: a concept of an event bus is neccessary if you want to create a big ensemble of only two macros: one for the panel (primary level) and one for data processing (core). Unfortunately the split is in R5 not really possible (iterator, from voice, to voice etc are not implemented in core).

 

Thanks to both Herw and Clist for these wonderful explanations.

 

...It's interesting to note that what we're basically doing here is creating our own "MIDI" for sending messages around the instrument.

Cheers,
C

 

Thanks for all these detailed comments. I really appreciate that help& didn´t expected that my little question is such a big thing.
I start to look inside CLists Action extract and herw´s bus solution, for the next week(s). Lot of stuff to read

I will definitely try to bus something together from Horuschilds upper structure. In next time i hope…

If anyone is a bit more involved in this concept and wan´t to help, feel free to post an improved version of the attachment.
(The channels are actually not independent& just the first Button works more or less correctly).


cheers

 

Yeah.... that won't really work. You're basically just mapping the "on" of the buttons to new values and merging them - something you could do at the primary level with the EventSeperator, EventValue and Merge modules. ...or even just the EventSeperator and Merge is you have the buttons set to send out different values than 0 and 1.
Regardless, what this means is that all the zeros get merged together. It's like midi where you send out the note number when you press a key, but then send a zero when you release any key - you don't know which you've released. You need a better method.

Taking the macros I posted I posted before and you have what I've attached below.

I've also included the eventwatcher so you can see what's going on.

I tried to demo a few things - for example, if you have a unique address code for each event source, then you can merge and split the buss however you like.

The trickiest part is making sure you keep the track of all of the sources and destinations and get the codes right each time. Also, my decode module requires that the address codes be > 9999, so I used 10001 ... 1004 for the buttons and 20001 ... 20003 for the knobs.


Cheers,
Chris

 

Wow, thousand thanks chris....have no words.

I really going to read this thread sometimes more to understand these things correctly. Your´e descriptions are very informative.


thanks again,
Phil

 

I think what Chris posted is exactly what you need. The one I posted will not work for this proccess.

Really cool to see it broken down, thanks.

 

Hi.
just another approach at decoding using flip flop.

Martin

 

Yeah Horus ... CL´s solution is exactly what i need. I think it CAN´T be done better for this case.
And the idea can implemented nearly everywhere to reduce wire weirdness.


Thanks for all help here.


cheers