ArrayArrayArrayArray BrainModular BrainModular Users Forum 2014-06-06T14:05:10+02:00 https://brainmodular.org/forums/app.php/feed/topic/4376 2014-06-06T14:05:10+02:00 2014-06-06T14:05:10+02:00 https://brainmodular.org/forums/viewtopic.php?t=4376&p=29617#p29617 <![CDATA[Non-dynamic low-cpu busses]]>
But I assume that's true of anything you rewrite in the gui? Like my metronome that flashes 1,2,3,4 by changing the value of a fader? Or is that drawing done differently somehow?
This, I think, is exactly why a color bus or something similar. Basically a module with a dropdown to choose which color bus to send through the output. This color bus would be defined at the workspace level and be completely immutable while the playback engine is engaged. So these workspace-level colors could effectively be an array in memory. The drawing engine would still need to take some CPU at the last pin (which of course would not be immutable, instead acting the same and taking the same overhead).

Would getting rid of all the pins in between (especially in the case of polyphonic patches) have a positive effect on performance?

Statistics: Posted by ceasless — 06 Jun 2014, 14:05

]]> 2014-06-06T05:59:09+02:00 2014-06-06T05:59:09+02:00 https://brainmodular.org/forums/viewtopic.php?t=4376&p=29616#p29616 <![CDATA[Non-dynamic low-cpu busses]]>
So what about a buss recieve that is guaranteed to have only one input? I have 100s of these, although some busses do recieve from multiple patches. I have the gui in one patch, and each vst in a different patch. there is generally a 1:1 correspondence between a gui widget and a recieve inside the vst patch.

I know my color is stealing cpu, and I don't mind as my wkp is low enough latency for me. I wouldn't care how low priority color updates were. If it took 1000ms to update a color that would be fine with me.

But I assume that's true of anything you rewrite in the gui? Like my metronome that flashes 1,2,3,4 by changing the value of a fader? Or is that drawing done differently somehow?

Statistics: Posted by woodslanding — 06 Jun 2014, 05:59

]]> 2014-06-05T20:38:33+02:00 2014-06-05T20:38:33+02:00 https://brainmodular.org/forums/viewtopic.php?t=4376&p=29612#p29612 <![CDATA[Non-dynamic low-cpu busses]]> So we need to "lock" them to avoid conflicts. This take time ...

for colors, the main pb is that the graphic engine can be slower in some situation, for example change the color of a simple button can lead to redraw the entire IB. And the graphic engine is much slower on HH than in the V5, especially on macos.

Statistics: Posted by senso — 05 Jun 2014, 20:38

]]> 2014-05-07T17:18:30+02:00 2014-05-07T17:18:30+02:00 https://brainmodular.org/forums/viewtopic.php?t=4376&p=29453#p29453 <![CDATA[Non-dynamic low-cpu busses]]>
I have a wkp that uses a lot of color cues. It is a mixer with many channels, and I used poly to construct it. I have the channels color-coded. These colors are completely static, and ONLY change when I set poly, but because they are in poly I must use busses.

In fact I have many dozens of busses sending color and text into this polyphonic subpatch that NEVER change name or value (except through re-patching, obviously) Presumably they are all hogging cpu being at the ready for their source-name or even just their value to change when I have made sure this cannot ever happen through the gui!

It would be nice if busses had a parameter that allowed them to 'stand down', so to speak. A checkbox marked 'static' that would instruct them that their value and name could not be changed from the gui, but only by repatching or resetting polyphony, and otherwise would only be checked on startup. Or perhaps a different kind of buss object would make sense for this purpose.

Although dynamic busses are very useful, busses are necessary to get any piece of information from one patch to another, even if that information never changes.

It would be great to lower my cpu and get lower latency. That said, although I am running at the same displayed soundcard latency as I was in v5, the actual latency is obviously much much lower. And despite the high cpu, the wkp is working well.

Thanks,
-e

Statistics: Posted by woodslanding — 07 May 2014, 17:18

]]> BrainModular BrainModular Users Forum 2014-06-06T14:05:10+02:00 https://brainmodular.org/forums/app.php/feed/topic/4376 2014-06-06T14:05:10+02:00 2014-06-06T14:05:10+02:00 https://brainmodular.org/forums/viewtopic.php?t=4376&p=29617#p29617 <![CDATA[Non-dynamic low-cpu busses]]>
But I assume that's true of anything you rewrite in the gui? Like my metronome that flashes 1,2,3,4 by changing the value of a fader? Or is that drawing done differently somehow?
This, I think, is exactly why a color bus or something similar. Basically a module with a dropdown to choose which color bus to send through the output. This color bus would be defined at the workspace level and be completely immutable while the playback engine is engaged. So these workspace-level colors could effectively be an array in memory. The drawing engine would still need to take some CPU at the last pin (which of course would not be immutable, instead acting the same and taking the same overhead).

Would getting rid of all the pins in between (especially in the case of polyphonic patches) have a positive effect on performance?

Statistics: Posted by ceasless — 06 Jun 2014, 14:05

]]> 2014-06-06T05:59:09+02:00 2014-06-06T05:59:09+02:00 https://brainmodular.org/forums/viewtopic.php?t=4376&p=29616#p29616 <![CDATA[Non-dynamic low-cpu busses]]>
So what about a buss recieve that is guaranteed to have only one input? I have 100s of these, although some busses do recieve from multiple patches. I have the gui in one patch, and each vst in a different patch. there is generally a 1:1 correspondence between a gui widget and a recieve inside the vst patch.

I know my color is stealing cpu, and I don't mind as my wkp is low enough latency for me. I wouldn't care how low priority color updates were. If it took 1000ms to update a color that would be fine with me.

But I assume that's true of anything you rewrite in the gui? Like my metronome that flashes 1,2,3,4 by changing the value of a fader? Or is that drawing done differently somehow?

Statistics: Posted by woodslanding — 06 Jun 2014, 05:59

]]> 2014-06-05T20:38:33+02:00 2014-06-05T20:38:33+02:00 https://brainmodular.org/forums/viewtopic.php?t=4376&p=29612#p29612 <![CDATA[Non-dynamic low-cpu busses]]> So we need to "lock" them to avoid conflicts. This take time ...

for colors, the main pb is that the graphic engine can be slower in some situation, for example change the color of a simple button can lead to redraw the entire IB. And the graphic engine is much slower on HH than in the V5, especially on macos.

Statistics: Posted by senso — 05 Jun 2014, 20:38

]]> 2014-05-07T17:18:30+02:00 2014-05-07T17:18:30+02:00 https://brainmodular.org/forums/viewtopic.php?t=4376&p=29453#p29453 <![CDATA[Non-dynamic low-cpu busses]]>
I have a wkp that uses a lot of color cues. It is a mixer with many channels, and I used poly to construct it. I have the channels color-coded. These colors are completely static, and ONLY change when I set poly, but because they are in poly I must use busses.

In fact I have many dozens of busses sending color and text into this polyphonic subpatch that NEVER change name or value (except through re-patching, obviously) Presumably they are all hogging cpu being at the ready for their source-name or even just their value to change when I have made sure this cannot ever happen through the gui!

It would be nice if busses had a parameter that allowed them to 'stand down', so to speak. A checkbox marked 'static' that would instruct them that their value and name could not be changed from the gui, but only by repatching or resetting polyphony, and otherwise would only be checked on startup. Or perhaps a different kind of buss object would make sense for this purpose.

Although dynamic busses are very useful, busses are necessary to get any piece of information from one patch to another, even if that information never changes.

It would be great to lower my cpu and get lower latency. That said, although I am running at the same displayed soundcard latency as I was in v5, the actual latency is obviously much much lower. And despite the high cpu, the wkp is working well.

Thanks,
-e

Statistics: Posted by woodslanding — 07 May 2014, 17:18

]]>