synth programming

Hiyas,

is there any place on the net where one could find other people using reaktor, to learn more about programming it, and that in a compressed way (as in.. a lot of info in a short time)? I'm looking for something like a chatroom where other reaktor users can be found.

thanks in advance!

Markus

 

You can join us in #reaktor on DALnet. Any IRC client will get you there. Just type /server irc.dal.net and /join #reaktor. We idle a lot, but there are always people around. If you want to learn the basics quickly, I recommend getting the Wizoo guide to reaktor 3 at http://www.wizoo.com

 

thanks.. any idea why I'd be getting this error message on any dalnet connection attempts (any server, ive tried about 10):
*** Unable to connect (Can't assign requested address)

I can connect to any other irc network without problems.

any ideas?

thanks a lot

Markus

 

Try this...

Go here:
http://www.dal.net/servers/index.php3
...and try picking a server...
I found this info on the dalnet homepage.

Unfortunately, however, none of these servers in the US seem to be responding rright now either. They have some info about DoS attacks being a common problem for IRC networks. Maybe that's why, I dunno.

- CList

 

I did use the servers from the dalnet server list. I'm not getting any timeout errors, but those weird "can't assign requested address" messages which I never got before on any other network.

thanks for the tips

Markus

 

here's some findings (sorry--it turned into a ramblathon)

the past few monthts i was learning a lot, looking at others'
ensembles, and trying, and retrying, and retrying to make my
own work the way i want (and i'm still retrying)
it almost always seems that you can do whatever you want in
reaktor, and the only limitations are our knowledge of reaktor,
not the engine, or functionality.

but i found out a few things that might help you keep more hair in
your head, and glass out of your fists:

16 router: if ctrl is <0 it still routes to 0
if ctrl is > 15 it still routes to the last output
use separators if you only want ctrl vals 0..15 to go through

COMBINING MONO AND POLY EVENTS: if you route a polyphonic router
with a mono signal, even though the info displays the correct values
the router routes incorrectly. same with a rx,wx input of a table,
i.e. mono event->poly audio doesn't work as it would seem (to me and my naive model of how reaktor should work).
SOLUTION: convert the mono signal to poly by putting it through
an event adder (poly) or event merger and hooking that to the poly audio input.
it seems that the same happens for inputs to macros (i.e. don't
merge a mono and poly signal into the same input-- it doesn't
seem to pass the values of one of the signals--probably an ordering
rule thing--"rules of wiring" section in manual)

DELAY/HOLD: there's always a 1ms delay in the audio or event delay or event hold -- even when set to 0 (use a timer to see)--this doesn't mean that
the delay quantizes to the nearest ms though--if you hook up an osc
to a mod delay to get the reason.subtracor type of "phase" thing,
and set the delay to 1/F (i.e. p->f shaper) it works perfectly.
note: the dry signal will sound first, since it's not delayed, so
you'd hear a short click, to eliminate this delay the gate by
atleast 1/F ms and multiply both signals by the same amp env
(which is triggered by the delayed gate
also, the maker of the flange-o-mat (i'm pretty bad with names, sorry)
knows about some other type of delay he calls the "parasite delay":
when you don't have modules connected in the order they were inserted
(i.e. see "rules of wiring") there will be a 1ms delay.
it's depth first than breadth for wiring. also order of module
insertion, and wiring counts (in some still vague way for me)

INVERTING: if a signal is inverted and added together, there will
be a slight delay so it won't = 0. work around: stick an audio_add2
in the noninverted path to restore the phase of the 2 signals when
added back together: works perfectly.

19 terminals pasted into a module will crash reaktor
i mailed tech support (since it always seemed to crash when i was
"almost done" and they gave me the exact number. now i do it
when i want to zap a disobedient instrument
big ups to tech support- the guy who made the disco girl XY ensemble
told me that one-- i'm still working on my answer to that:
it will be called "putZ! XY" it will have only one knob that will do 10000 useless things all accompanied by the snickering of a 3-D putz.
anyway

there was 1 more thing, hmmm-- it's cost me many sleepless hours
and missed parties. they should market reaktor as the "amazing
stay at home synthesis development environment" or "arthritis"--
AUDIO/EVENT SWITCHES AND THE TWILIGHT ZONE:
if you use event tables, to store parameters, or sequences and use
knobs, or midi input (or any event input) hooked up to "in"
the following will happen if you have switches (or if you edit the
ensemble structure):
all the values of the knobs or value modules will trigger an event
into the table and change the data.
i used to wonder from which dimension the new data came from.
i thought maybe it was the ghost of the previous version, or
the dimension that interacts mysteriously with photon beams projected
through a single slit in some physics lab somewhere.
but no, it was just the values of the knobs or value modules, or
whatever output is connected to the "in" input of the event table
EXPLANATION:
when a switch is turned on, every event module passes it's value
as if it was trigged (hook up a constant to a meter for example--
have the constant also connected to some sort of output or else it won't be on)
WORKAROUND: to prevent unintended writes to event tables hook
up the triggering thing (if it's a button ->value.in->table.in)
to either a router or separator before it reaches the table.in input.
ex. button->separator.in
separator.out->value.in
pitch->value.val
value.out-> event_table.in

pitch comes before gate in midi in modules...always
between gate and velocity it depends on order of insertion/wiring
(easy to test: gate and vel -> eventmerge-> meter, cut and paste
to see which one gets there first -- use different ranges for the
vel and gate to distinguish)


modulo module: the mod output comes before the div output:
so when using it to route multiple 16 routers for example:
modulo.div->route16#0.ctrl
route16#1.[1..16] -> route16#[1..16].in
modulo.mod->route16#[1..16].ctrl

you will have to trigger the modulo like : modulo.mod->value.val
modulo.div->order.in
order.1->route16#0.ctrl
order.2->value.in
value.out->route16#0.in

i.e. route16#0 (the "first" one) routes the input signal to one
of 256 positions: the div determines which of the 16 route16's
(#'s 1..16) get the input signal, and the "mod" output determines
which of the outputs on the secondary routers (1..16) gets the input.
since mod comes before div you want div to set the ctrl (i.e. route)
and then pass the value of mod to the other ctrl's of the route 16's




oh yeah, this was a big one (just found this one yesterday)
PARALLEL MINI MACROS VS 1 LARGE MACRO:
let's say you want to loop through 127 rows and 256 columns of a
table used to store sequences. if you hook up 2 counters and
create a gigantic nested loop you will crash reaktor
then if you put an event delay (i once included the structure
of a "cpu-less" event delay that i had gotten the idea from
reading a post in the creaters list once--i'll post it on the library,
eh, not worth it, here it is:
macro.in#1 delay
macro.in#2 event
delay->Hold.H
event->order.in
order.1->value#2.val
order.2->value#1.in
const=1->value#1.val
value#1.out->Hold.G
Hold.out->value#2.in
value#2.out->macro.out
it works just like an event delay, except it uses very low cpu
)

sorry for the tangent, -- so i have 24 mini tables (12x127)
and 1 big table (24*12=288x127) and want to write the contents
of the big tables to the mini ones by a gigantic loop reaktor
will crash-- so i put the above delay macro with delay=0 and it
takes about 1 minute to loop through the values! (fyi i was
doing a few things in the loop so there were many many operations
being carried out but still the point is...) so i made the
big table multi client and just did 24 copies of 12x127 to
12x127 sections of the big table-- it took probably a few milliseconds! this means that if you use reaktors built in
really really fast logic for many small identical macros
executing simultaneously (sort of) it will be much faster
than 1 master macro doing the work of all the little guys.

same is true for polyphony: 1 8 voice sine oscillator is more
efficient than 8 mono sine oscillators (even though both
could theoretically do the same thing)

also: there seems to be a soft limit of 100 control modules
(but it seems like the hard limit is much higher) before you
get the "sorry too many control modules in instrument" message.
it occurs with buttons but not knobs.

can't thing of anything else to add to the ramble. maybe some
thread can be started with an organized format for these findings,
or statistics. is there one and i just don't know?

anyone have a suggestion for the format (sorry i know it shouldn't
be a stream of consciousness ramble, but no time for formatting: i should get back to reaktoring

hopefully this helps someone.

also, is there a more in depth explanation of the parasite delay
thing? -- the maker of the flange-o-mat would know (again sorry
i don't remember your name though

peace,

elon

 

holy cow. thanks a lot for sharing that wealthy piece of experience.

You wouldn't know what could prevent someone from joining dalnet servers (*** Unable to connect (Can't assign requested address)) that isn't there for say efnet (which I can connect to fine)?

thanks a lot!

Markus

 

Some more on what Romulus said

"COMBINING MONO AND POLY EVENTS"
...you're dead on with this one. Cost me a lot of wasted time as well, I now always combine mono event sources using one input of an EventAdd before routing them anywhere.

"amazing stay at home synthesis development environment"
- He he. Word. My girlfriend hates Reaktor.

"AUDIO/EVENT SWITCHES AND THE TWILIGHT ZONE"
There are things in Reaktor that are "event sources" and things that just process events. Somewhere in the manual around where they mention event order of processing they also say; "when you load an ensemble all *event sources* will fire an event". They will also ALL fire their event when a switch (not a button!) is pressed. What's really crazy if you don't know about it, and cool if you do know about it is that there are "event sources" that are NOT panel controls (though most of them are). Button, knobs, faders, and XY controls (but *not* switches) are event sources. Constants, adders, and just about every other event-type module, are not. I would assume that MIDI inputs are not (though I hate to say anything without testing). What's crazy/cool is that EventDelay and EventHold modules *ARE* event sources. An EventDelay module will fire an event - after the delay time passes - on start up or after a switch press
==> even if it's Event input is not connected to anything!!! <===

Keep this in mind when weird stuff happens from your switch presses, an EventDelay or EventHold might be responsible.

The fact that eventdelay and eventhold are delay sources is what allows them to stop your looping structures from breaking. Without them, one single event goes through too many modules without "dying" and it eventually causes a stack overflow and crashes reaktor. With them, the incoming event "dies", and a new event starts.

I have a macro saved in my "Test Equipment" folder called "EventLight", that lights a panel lamp for 500ms when ANY event comes in. It's basically (using your notation);
macro.in#1 in
in ->Value.in
Constant[1]->Value.Val
Value.out->Hold.G
Constant[500]->Hold.H
Hold.out->PanelLamp

...it's great for checking stuff like this. I hook it up all over and see where the events are coming from. You can also use it to see what's firing when an ensemble starts up.

That low CPU delay is very cool! I'll have to try it in my Game Of Life ensemble. Thanks!

Also, for everyone, there's a Yahoo Group for Reaktor Builders (reaktorBuildersForum) - strictly technical - that's pretty active. I actually brought up this question of "event delays are sources" there a month or so ago. It has it's own file section with some nice utility modules and the sort of quirky geeky ensembles that aren't really for everyone. What's really hilarious is that my Yahoo ID is "Remus_NY", and has been for years.

- CList

 

...something else...

From what I've seen - I haven't read or proven this so correct me if I'm wrong - when an event line is connected to an audio input, the order-of-processing does not apply. It's as if the audio input "looks back" down the wire to see what the value is **at the time the value is required be the module**. This means for things like RX/WX table inputs, and "val" inputs of EventValue modules, EventOrder modules are not really needed. That being the case, I don't think you need the EventOrder module in your "low-cpu-delay".

You may want to keep use them just to be sure adnd/or for clarity.

- Clist

 

about the cpu friendly delay

is there maybe a difference between a regular event delay module and your suggestion, or am i doing something wrong?

i builded the delay as you described (interesting idea cause i find it amazing when creating a complex structure is faster than a built in module...). but is it correct that the events a doubled and you get an event immediately and one delayed? when im right, you have to filter out the original event - will it still be faster?

ill try...

 

thats what i experience too...

in some cases, there is definitely a "look back" function. dont know how to handle it exactly, but it definitely will expand your capabilities in reaktor programming when you know about it...

 

Yeah, Romulus forgot to mention an event seperator after the hold output. Low value goes to the EventValue module.

 

Re: here's some findings (sorry--it turned into a ramblathon)

Excellent post! I look forward to more of your ramblings.

 

This is sort of related, sort of not...

Panel meters will round stuff off to a max of 3 decimal places , so you need to be careful about that when doing measurements. I realized this while exploring the rules for time constants and exponential decay of the ADSR, AD and AR modules. It would seem like the outputs would drop to .001 then to 0, but if I multiplied the output by 10000, I'd see that it was actually never dropping all the way to true zero. (this, btw, is how hardware ADSR's work, they use the exponential decay of a resistor-capacitor pair, which never fully discharges).
This means that if you do the following;
ADSR -> AtoE -> EventSeparator
...where the threshold of the separator is 0, you'll **never** get an event out of the Lo output of the Separator. But a panel meter hooked up the output of the ADSR will show zero. Multiply that by 10^6, and you'll see what that the "real" value is not zero, but some very small positive number.

Moral:
Always a good idea to scale things up when doing testing of small numbers so that you use the full range of digits in the Panel Meter's value display.

I haven't tried anything to test whether a delay always delays by 1ms or not - so I'm not confirming or denying that, just making a related point about testing quirks in Reaktor.

Another way to test this might be to take a 20 ro 30Hz LFO spitting out ON / OFF events, split the signal so that one goes into an EventDelay, then take the output of the event delay and the output of the undelayed signal and run them into two sides of an AUDIO adder (thus converting them to sample-rate), then take the output of the adder and run it into a scope module and see what the waveform looks like. If you make the time factor low enough for the scope, you can see the individual samples becoming wider and wider horizontal bars on the scope, and from that you could get a sense of what the delay time is. Purely hypothetical here of course, probably would have been easier for me to try it out than to just type all this up right now!

- CList

 

Actually I just confirmed this, the scopes work great for testing timing stuff like this in the real world as well.
There's a delay , but it's a lot less than one 1ms. I have 6 of them lined up here and the delay is tiny. Note that the time-scale for the scope module is such that the value of scale represents the number of milliseconds shown on the screen. So if it's 4, then each sweep of the scope trace take 4ms, and a 1ms delay would be a shift in the waveform 1/4 of the way across the screen.

A 2kb download here has my ensemble;
http://www.mindspring.com/~clist/reaktor/timingtest.zip
Check it out. Try changing the delay constant for the first of the 6 event delays to 1ms and you'll see the difference.

- CList

 

more on event ordering

wow, i'll have to check that out-- i was getting my times from
the hints not meters for the delay testing (in structure view)
maybe it's my pc? p4 1.7ghz 1G rambus?
i still see 1ms delay in a timer even when the dly input or H input
is unconnected.


i did some more testing for the event ording stuff:
1) within a macro (or instrument) the events travel from the
source to the branch started by the oldest module--
so if you cut and paste in that branch, as long as the oldest
module remains connected to the source it's still traversed first.
before saving the instrument you would see the branch last wired
to whatever output you're monitoring-- but once you save it goes
back to the age of the module.
2) the first event hooked up to a macro in is the branch that
goes through!!!??! the opposite of rule #1, even when that branch
receives events after the first event they are ignored, only
the first branch hooked in passes the events
2a) but a very wierd case is the following instrument(attached)
you can see a different value on each side of the last add module
(in hints of structure view)

i've attached an instrument which shows this behavior: confusion.jpg
rename it to confusion.ism before opening (it's my new philosophy
when it comes to reaktor
which has a gate which should always come after pitch
and you'll see that the pitch is the only value passed through--
still has different values on both sides of the adder module
connected to the "ground" macro.
if you attach the pitch and gate outputs to an adder (same
input --so 1 input is inactive) you should only see the gate
value on the other side


correct me if i'm wrong, and thanks for any replies

elon

sorry, couldn't attach even as a jpg , i'll email it to tech support.

 

Good stuff, very interesting.
I always thought that when you have multiple wires coming out of a single event port that the order of processing is based on the order in which the WIRES were created - but that - as you say - is not the case. I just double checked it.

It is indeed based on nothing but the creation order of the modules those wires are connected to. Good to know.

BTW, I'm sure your machine is plenty fast enough, check out that oscilloscope timing tester ensemble on my website from my last post, you'll see what I'm talking about. It may not be 100% clear how it works, but basically, the top and bottom scopes are just for reference. The output of the square-wave in the middle of the three scopes goes from +/-1 to +/-2 only after the delayed event arrives, and so shows how much time the event delay adds.

- CList