06/22/08
+
PM |
QUOTE |
PERMALINK |
REPORT
eyesnine
also, i've been known to get carried away in reaktor themed discussions. call me jimmy longpost!
06/22/08
+
PM |
QUOTE |
PERMALINK |
REPORT
eyesnine
massive polyphony is a really interesting technique! i use it myself at times. problem is that it gets to be cumbersome on the old cpu. i like to use it for stuff that doesn't have to be processed during a performance, like parameter editing.
also, discretely handling polyphony is often done by encoding the voice number to the data, rather than having an entirely separate event path just for the voice number. i used this technique for a little while, but dropped it in favor of having two separate event paths so i could save the cpu required to encode/decode.
because core doesn't support event looping it actually turns out to be a moot point in the iteration vs recursion argument. recursion isn't supported by core. but, if your code doesn't have any core cells in it, event looping can offer some very elegant solutions. maybe i'm just attracted to the concept in an entirely abstract manner, but i use event looping pretty much whenever possible.
here's a (simplified) problem for you, its one i struggled with and it shows you the importance of event looping in reaktor, and the limitations of core cell implementation that doesn't support event looping. plus, its really interesting if you think about it.
lets say you have eight audio streams: 12345678 and you want to have these streams muted using one button and one fader. so, you set the fader to 5 and press down the button and you get 1234X678. then you change the fader to 3 and press mute and you get 12X4X678. also, you want it so that if the state of the stream is 1X3X5X7X and you set the fader to an odd number the button will change to the unmuted state, and when you set the fader to an even number the button will change to the muted state.
this doesn't seem to be a complicated problem, and it could arise fairly naturally in instrument design.
in order to accomplish this you need some memory device that represents the state of the stream (i'm using 8 voice polyphonic snap values, you could use snap value arrays of size 8 also though). obviously then, the memory device both receives information from AND transmits information to the button. also the button must transmit information to AND receive information from the memory. this creates an event loop! button => memory => button (=> memory => button => ...)
just the simple act of bidirectional communication with the button creates an event loop. you can't avoid it! and you can't put any core cells anywhere in that path. uh oh! no core for you!
this doesn't seem at first glance to be a recursive problem, but it actually is. its just a recursion that executes one stage at a time. stage 1: button => memory. then 2: memory => button. then 3: button => memory, and so on. interesting, huh!
!!!! OMG TURING OMG OMG OMG OMG. I'd so like to have a code module like in synthmaker, or a java object like in max msp. All that event recursion/iteration crap in reaktor drives me nuts. I like lazyfish's approach to put stuff like that in massive polyphony (like 64 voices for a 8x8 step sequencer) to avoid having to do iteration by hand.