General question for the more advanced builders

Hi all! I have long hesitated to ask, alas until today no answer did appear from nowhere, so here goes...

When I load my selfmade synths, more often than not I notice that (probably all) presets sound different until I switch them back and forth once. I read the paper about the new initialization algorithm [of which I just uploaded a translation (into German) to the UL], however I am uncertain (clueless, actually) where to look for issues causing this behaviour. So my question is - is there a general routine / order / sequence of measures to narrow down the source of error, and what would that be? In this particular case, I'm working on an Arp Odyssey clone that makes use of a lot of Sends and Receives (all inside one instrument) to avoid spaghetti code. The thing is working quite nicely, only this issue leaves me standing in the rain.

Any suggestions appreciated!

 

I have just read through the Reaktor Resources thread, namely the links to threads that CList posted in May. Although that is a lot to chew on, it is worth reading every letter, and from what I picked up for now the problem I was referring to in my initial post seems to have a lot to do with event order. Before I re-read the whole lot, let me ask - is the "wrong sounding presets at startup" generally avoidable or is that something I should rather live with and simply toggle presets first thing in the morning?

 

could you please upload a very simple example.ens here?

ciao herw

 

Yeah, please give an Arp to Herw.

He'll probably end up with dangling patch cords this time.

Anyone else down for a close encounter?

 

oh no - my intention is that many more users like to create modular synths and make music with it!

 

Hehe... well, Herw, I'm afraid the ARP isn't close to the simple.ens category. And I'm not too sure where ripping it apart would solve the issues I'm having.

 

LOL! Almost sprayed my coffee...

 

3D-dangling patch cords with hardware feeling
bernie's studio

 

i dont really build synths (midi-synthesizers, that use snapshots and stuff, that is), and i havent experienced this myself, but as you said event order has a big effect on this. the first output is the only one that is involved in the simultaneous event init that occurs, the others are sent out as normal reaktor events. more than likely, things can be solved by paying alot of attention to event ordering.

i agree with herw, though, without an example its hard to tell whats going on. of course im not trying to force you to post it, i dont even know if i have enough time to really give it a good testing, but without anything to rip apart its hard to tell. hopefully someone else has experienced something similar, which is what im sure you were hoping by posting this thread.

 

Something you dont see everyday. A lone ranger D2 amongst all of that analog gear.

 

event ordering is the main point - it is better to solve the problems in core generally because core is like thinking naturally. There are only a few interesting points to primary level: the interface between core and primary. I like to play with it but i think there have to be a revolution at next update to R6: only core with a cleaned and well described documentation of General Reset.

 

Only Core. That's a good idea Herw. I've been trying to imagine what shape R6 would take. I think you've got the best idea so far. Build from the roots.

If you do make new "patchcords". Will they be stackable bananas, ala Buchla?

 

Exactly. I noticed CList's comment in Koyaanisquatsi concerning such a behaviour - and it (quatsi) still is behaving that way. It's actually not such a big deal, however I'd really like to find the culprit to gain some experience in debugging. You know, I'm aware of the event watcher, however I'm not at all familiar with how to use it systematically...

 

Yeah, whenever I load an ens. I have to change the presets at least once for it to begin sounding.

 

honestly, im not sure if i do either. i rarely use the output ports or multiple inputs, rather i just paste it in, plug in input 1 and possibly 2, and let rip, then start over elsewhere.

did you see the recent post by james walker hall with the wireless debug system? that looks promissing for users like myself who have tons of hidden macros (i tend to keep most if not all of my GUI elements in one control macro, and keep everything else hidden in sound-engine and logic macros).

 

Hi Daniel - yeah, I did read that post. In order to keep my structures sort of clean, I started using Sends and Receives to avoid too many wires going all over the place. But even with the Wireless Debug thing, it doesn't solve my lack of strategies using it properly... thanks for your reply!