more declicking

[gurulogic]

At the expense of 6% more of my cpu cpu at idle I now have a decent solution for smoothing out any clicks in the audio during patch enable /disable, but now I am getting declick-crazy and I want to find a way to smooth the clicks when selecting from different audio buses with a listbox.
I already have a stereo volume for each sub patch that I use for the patch enable declick so I would like to find a way that every time a listbox selection was made, the audio would very quickly fade out and back in again. (assuming this would even help)
Whatever the case, it has to be cpu friendly over 46 sub patches because if I start sucking too much more cpu all I am going to be able to do with my workspace is start sharing it as a computer benchmarking tool
I started connecting various modules to the list outputs of a pair of lisboxes (L/R) assuming I should be able to use the changing values to trigger some sort of fade in and out but I'm just not coming up with anything that works.
(that's how I figure things out in Usine. Just start connecting things untill something either finally makes sense or else it just works ...!)

[23fx23]

(that's how I figure things out in Usine. Just start connecting things untill something either finally makes sense or else it just works ...!)

hehhe, same here, but I start to understand pause and reflexions is a better tec

back to your pb I would create a subpatch based on the count ms module, each time the list box change it start the counter.
after that I would put a counter with max down (max is half duration) linked on the count output and play a bit with math(you'll have to inverse the values) to generate a ramp fade out, then in of specified time at each change, then drive the fade to the concerned subpachs (via selector or array). you could also do that with other methods (envellopes, shifting a sawtooth array, trigger a triangle lfo,...) but feel this would be more cpu friendly (used a similar method to generate flashs). anytime you can have a master module that do an opeertaion driven to subpachs must be more cpu friendly than having 46x this operation in subpachs, so try to track every tiny thing than can be used one time (got same cpu pb with my cellz matrix).

[gurulogic]

Well, your explanation confused me so much I had to "reflect" and find another way
Only problem is my solution doesn't help. I think I need a way to delay the text input to the receive buses so that the bus doesn't change untill the volume is at -80. Trouble is is that the Data Delay script does not work properly for text input. Also the Data Delay is quite expensive for cpu when using too many times. I tried a string of 10 wait one cycle modules but that does not help.
Any thoughts on how I could work around this problem? Also, is there any lighter way to delay data as the many data delays is accounting for a large amount of the cpu with my patch enable/disable declick method.perhaps there is a method to use a selector or an array as you mentioned for distributing the data to subpatches / volume modules from the second example I am showing here?
Also I realize now that extreme cpu savings is not as important if the modules are in a sub patch that is not always active.

First Example, list box name change of audio bus declick attempt:


Second Example, my working patch enable /disable declick method:

[23fx23]

instead of the script, you could use a simple count ms to delay impulses (it will start counting 3ms on list chg, and create a stop impulse), must be lighter on cpu. cause you don't really delay texts data in your examples, but simple data inpulses out of the has chg module. to dispach to your patchs use a 1in 16 out selector and the list box out nb will choose what pach drive to if connected to the select input of the module. also I don't catch why in your second pic you use a<b and a>b modules out of the swich as the swich has only two states 0 or 1 no?

[gurulogic]

also I don't catch why in your second pic you use a<b and a>b modules out of the swich as the swich has only two states 0 or 1 no?

I did that so that I wasn't sending the same patch enable / disable message twice or something like that that. I just tried without and it didn't seem to work at all properly without at least the a<b to the data delay.

Am I missing something? I don't see a simple count ms module, only the count ms patch, which if the cpu meter is especially accurate still seems to use a fair amount of cpu?
Also what I meant about delaying text is that it seems for my first example to work properly, I would have to delay the text from the listboxes to the bus name input by the amount of time set for the audio gain to fade to -80. ..

Also, I don't know if using a selector to distribute the data to different patches can work because often there will be multiple patches needing the information at the same time...oh but wait, maybe if I just have the master patch always send the data to the sub patches every time there is an action and then I use multiple Pass Event Flow modules linked to the active patches to regulate which ones receive the data! This seems like maybe a much better solution...I wish I had more time to spare today

[gurulogic]

ok, now I'm not at all sure what the < > than modules were doing for me in the previous example 2 because things are being very unpredictable. New solution shown as new example 2. Still no idea why I have to wait 100ms after the fade out to disable the patch without clicking. Is there latency in some Usine data?

Back to the the listbox > audio bus name select declick topic, for some reason the Count ms patch does not reliably let list text through the Pass modules if I set the count to less than 65. More Usine data latency? This ends up meaning that the fade out/in has to be 130ms which is quite noticable (but maybe still better than pop sounds?) Anyways, however boring it may be I've shown how I am doing it as new example 1.Also, it does not perfectly remove all unwanted noise.
Feedback welcome...


new example 1:
(audio outputs from buses to volume module is not there atm)


new example2: (patch enable / disable declick)



I don't want to spend the rest of my life building my patch.......

[23fx23]

dont' want to confuse you but just show you the way ive done for my setup:


seems not noticable latency, customizable fadein/out curve, 0,07 cpu for contolling 16 subpachs, but you need more than 16 in you case don't you? aslo here didn't implemented the fade for when the pach goes off, could if you re interested..

[gurulogic]

Thanks for the ideas, but if I understand correctly that only works for switching from one patch to another. Mine is more complicated where I may have any number of patches turning off, on and or internally switching audio receive buses at the same time. I think maybe my idea of Pass Event Flow modules to act as relays for passing data only to currently active modules may still work best for me. Tonight I will try.

I was just thinking how interesting it could be if we had a hardware modules version of Usine.... Solder the A/B math chip outlet leg and an electronicly controlled A/B switch to the inlet legs of Pass Event Flow relay and feed that to the power switch for the previously built Modulation Delay board..
Sounds expensive!

[23fx23]

hehe yes expensive, you right my tech is only for 1 sw a t time, best with pass event then, good luck and lets us know if you find solution!