ArrayArrayArrayArrayArrayArrayArrayArrayArray
BrainModularBrainModular Users Forum2009-05-25T07:11:40+02:00https://brainmodular.fr/forums/app.php/feed/topic/15772009-05-25T07:11:40+02:002009-05-25T07:11:40+02:00https://brainmodular.fr/forums/viewtopic.php?t=1577&p=9028#p9028Statistics: Posted by 23fx23 — 25 May 2009, 07:11
]]>
2009-05-25T00:15:08+02:002009-05-25T00:15:08+02:00https://brainmodular.fr/forums/viewtopic.php?t=1577&p=9019#p9019 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!
Statistics: Posted by gurulogic — 25 May 2009, 00:15
]]>2009-05-24T16:24:02+02:002009-05-24T16:24:02+02:00https://brainmodular.fr/forums/viewtopic.php?t=1577&p=9002#p9002 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..
]]>2009-05-24T05:07:01+02:002009-05-24T05:07:01+02:00https://brainmodular.fr/forums/viewtopic.php?t=1577&p=8995#p8995 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.......
Statistics: Posted by gurulogic — 24 May 2009, 05:07
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
Statistics: Posted by gurulogic — 23 May 2009, 22:08
]]>2009-05-23T21:21:52+02:002009-05-23T21:21:52+02:00https://brainmodular.fr/forums/viewtopic.php?t=1577&p=8989#p8989Statistics: Posted by 23fx23 — 23 May 2009, 21:21
]]>2009-05-23T20:42:07+02:002009-05-23T20:42:07+02:00https://brainmodular.fr/forums/viewtopic.php?t=1577&p=8988#p8988 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:
Statistics: Posted by gurulogic — 23 May 2009, 20:42
(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).
]]>2009-05-23T03:54:23+02:002009-05-23T03:54:23+02:00https://brainmodular.fr/forums/viewtopic.php?t=1577&p=8965#p8965 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 ...!)
Statistics: Posted by gurulogic — 23 May 2009, 03:54
]]>BrainModularBrainModular Users Forum2009-05-25T07:11:40+02:00https://brainmodular.fr/forums/app.php/feed/topic/15772009-05-25T07:11:40+02:002009-05-25T07:11:40+02:00https://brainmodular.fr/forums/viewtopic.php?t=1577&p=9028#p9028Statistics: Posted by 23fx23 — 25 May 2009, 07:11
]]>2009-05-25T00:15:08+02:002009-05-25T00:15:08+02:00https://brainmodular.fr/forums/viewtopic.php?t=1577&p=9019#p9019 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!
Statistics: Posted by gurulogic — 25 May 2009, 00:15
]]>2009-05-24T16:24:02+02:002009-05-24T16:24:02+02:00https://brainmodular.fr/forums/viewtopic.php?t=1577&p=9002#p9002 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..
]]>2009-05-24T05:07:01+02:002009-05-24T05:07:01+02:00https://brainmodular.fr/forums/viewtopic.php?t=1577&p=8995#p8995 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.......
Statistics: Posted by gurulogic — 24 May 2009, 05:07
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
Statistics: Posted by gurulogic — 23 May 2009, 22:08
]]>2009-05-23T21:21:52+02:002009-05-23T21:21:52+02:00https://brainmodular.fr/forums/viewtopic.php?t=1577&p=8989#p8989Statistics: Posted by 23fx23 — 23 May 2009, 21:21
]]>2009-05-23T20:42:07+02:002009-05-23T20:42:07+02:00https://brainmodular.fr/forums/viewtopic.php?t=1577&p=8988#p8988 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:
Statistics: Posted by gurulogic — 23 May 2009, 20:42
(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).
]]>2009-05-23T03:54:23+02:002009-05-23T03:54:23+02:00https://brainmodular.fr/forums/viewtopic.php?t=1577&p=8965#p8965 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 ...!)
Statistics: Posted by gurulogic — 23 May 2009, 03:54