CPU performance in Buzz (general tips and tricks topic)

[Dean]

i added 500 machines to machine view and yes it gets slow, the gfx stuff anyway. but i REALLY doubt you need 500 machines in the first place..

but does it explain why it gets more slow in the recent version compared to one from last year?

[Dean]

btw. what does your cpu usage say while buzz´s output is muted? (F12 key)

Forgot to answer this one. if I hit F12, the cpu goes down to 0% very fast.

Also, what's that theme you are using? it looks like something which would come in handy for me,
the machines view is too small for this 500-machines project. I'm not sure, but I get the impression
you can fit more machines in the machines view size than I can in the one I use (on regular theme).
Is it possible to resize machines view size?

[strobotone]

adding hundreds of matilde trackers (connected to master) playing samples had the same effect.
cpu usage was over the top and the sound stuttered of course.
but the interface kept functional.

i could add about 2000 generators before buzz crashed and all mem was used up.

for the theme check my download link in this thread viewtopic.php?f=3&t=217
(requires latest builds)

and ofcourse is it possible to resize the machineview since a while now.

[UNZ]

i added 500 machines to machine view and yes it gets slow, the gfx stuff anyway. but i REALLY doubt you need 500 machines in the first place..

but does it explain why it gets more slow in the recent version compared to one from last year?

kind of, the one from last year didn't have the right hand column in machine view right ? the new one has to keep state on a few more things like this. Its all the "housekeeping" that seems to slow it down currently. This is just the price you pay for more features to be done in less time. Maybe optimizations are possible, but i doubt its a priority at the moment when so many other things are beeing changed around and re-done, and many loose ends, usually you think about optimisations when you're quite sure things are going to stay where they are and can measure where the real big hits to performance are and fix those. Also your use case is just so absurd it may never really get adressed properly...it might get faster, but don't expect wonders.

[Dean]

adding hundreds of matilde trackers (connected to master) playing samples had the same effect.
cpu usage was over the top and the sound stuttered of course.
but the interface kept functional.

i could add about 2000 generators before buzz crashed and all mem was used up.

for the theme check my download link in this thread viewtopic.php?f=3&t=217
(requires latest builds)

and ofcourse is it possible to resize the machineview since a while now.

Very interesting, how do you resize machines view? (I've looked around in settings, found nothing...)

i added 500 machines to machine view and yes it gets slow, the gfx stuff anyway. but i REALLY doubt you need 500 machines in the first place..

but does it explain why it gets more slow in the recent version compared to one from last year?

kind of, the one from last year didn't have the right hand column in machine view right ? the new one has to keep state on a few more things like this. Its all the "housekeeping" that seems to slow it down currently. This is just the price you pay for more features to be done in less time. Maybe optimizations are possible, but i doubt its a priority at the moment when so many other things are beeing changed around and re-done, and many loose ends, usually you think about optimisations when you're quite sure things are going to stay where they are and can measure where the real big hits to performance are and fix those. Also your use case is just so absurd it may never really get adressed properly...it might get faster, but don't expect wonders.

the 1347 build has the column to the right, cause it supports the templates. in fact the only thing I miss in this old build is bypass of fx and multi-solo (not included).
I'm very interested in multi-groove, I don't know where to find it in the new build?
And there are things like better cpu-view, folders for templates, better wavetable (much better), among other things..
If I find the multigroove to be ease of work, I might consider it all a trade-up, I don't usually use more than 100 machines even...
Also, maybe it was you or someone else, who wrote about a machine which could be used as a container for other machines, it might be possible to do some efficiency work...

[UNZ]

multigroove: you can do it by adjusting RPB in PXP

there are also groove machines, but i think they work global.

or wait for the new new pattern editor (preview it with ctrl-q in pxp in latest builds)

[Dean]

multigroove: you can do it by adjusting RPB in PXP

there are also groove machines, but i think they work global.

or wait for the new new pattern editor (preview it with ctrl-q in pxp in latest builds)

thanks!, interesting... but maybe cause I haven't updated in a while, but I don't know where to find RPB?
I am still not sure what is multigroove, I just imagine it's like being able to set grooves individually for patterns,
instead of global ones (which sound way interesting)...

[strobotone]

first of all check this : http://buzzwiki.robotplanet.dk/index.php/Pattern_XP

RPB = rows per beat
TPB = ticks per beat

the slider on the attached screenshot is the machineview zoomer. are you testing us?

[Dean]

first of all check this : http://buzzwiki.robotplanet.dk/index.php/Pattern_XP

RPB = rows per beat
TPB = ticks per beat

the slider on the attached screenshot is the machineview zoomer. are you testing us?

oh man ,! I got things wrong! I thought multi-groove was actually a way to handle for example grooves on a specific
machine (you can do that as a workaround now, as mentioned), I thought I was going to recall a command RPB, which
would be something atleast like a TPB setting in the pattern (so that you could shuffle easily for one generator, without
applying the shuffle globally) wow, I must have misunderstood, someone else posted about "multigroove" in other topic hehe

now, about machineview zoomer, I do know it , another misunderstanding...
I thought there would be a setting of (max) machine view size (like there was in old buzz with overloader hack).
As I understand it, the machines' view already adapt to the size of the monitor, so there is nothing really stopping
anyone from making it larger, I don't know why it's locked...
You can increase it slightly by sliding the right side templates/machines column to the right, why not allow more increase of size?
I really like having a lot of space when I connect things (even when I don't use 100s of machines ) and I've
been thinking there must have been an update for this some time when I didn't update, but sadly not
I thought your theme there seemed to be able to show more machines in max zoomout than mine.
But maybe the machines are just smaller in this theme, or there was something else making me think so...
I don't know much about xml, but shouldn't there be a simple setting somewhere which even I could modify
(what should I look for, if so?)
thanks!

[strobotone]

yes the machines themselves are smaller than the defaults.

we should put this topic in a new thread.
if you take a look in MachineControl.xaml you find:

<Border Name="Border" Width="84" Height="34" BorderThickness="0" SnapsToDevicePixels="True" HorizontalAlignment="Left" VerticalAlignment="Top">

<Grid Name="MachineGrid" SnapsToDevicePixels="True">

<Rectangle Name="borderRect" StrokeThickness="2">
<Rectangle.Stroke>
<SolidColorBrush Color="{Binding Path=Machine.Graph.Buzz.ThemeColors[MV Machine Border]}"/>
</Rectangle.Stroke>
</Rectangle>

<Image Source="{Binding Path=MachineImageSource}" SnapsToDevicePixels="True"/>

<Rectangle Name="machinebody" Width="84" Height="34" RadiusX="2" RadiusY="2" Stroke="#DDDDDD" StrokeThickness="2">
<Rectangle.Fill>
<LinearGradientBrush StartPoint="0,0" EndPoint="1,1">
<GradientStop Offset="0" Color="#48000000"/>
<GradientStop Offset="1" Color="#38000000"/>
</LinearGradientBrush>
</Rectangle.Fill>
</Rectangle>
...
...
</Border>

there you find all the elements that make up the machine´s appearance. (LED, buttons, texts ...)

[Buzztler]

I already had installed the .Net4 client thingy ... I installed the latest/newest graphics-driver for my card and it seems as if the debugger-message referring wpf is gone?! I keep the driver anyway, it rocks (!). Then I installed Win XP Sp3 and .... the performance of my whole computer sucks
I switched back by a backup to build 1453 and stay with it for a while, 'cause it seems I can work with it. I have most of the possibilities of the old maximum overloaded buzz combined with a whole lot of possibilities of the new Buzz. The hardware rendering rocks now for me, 'cause I'm able to record setups that are normally out of reach, referring to the cpu, it takes more time "if the track is over the top" on my slow computer, but it works very fine, no dropouts or clicks in the rendered music and cpu stays cool 'cause even 100% load does not rise the temperature very much ... So I'll still read the comments here and watch the further development ...

[Dean]

yes the machines themselves are smaller than the defaults.

we should put this topic in a new thread.
if you take a look in MachineControl.xaml you find:

<Border Name="Border" Width="84" Height="34" BorderThickness="0" SnapsToDevicePixels="True" HorizontalAlignment="Left" VerticalAlignment="Top">

<Grid Name="MachineGrid" SnapsToDevicePixels="True">

<Rectangle Name="borderRect" StrokeThickness="2">
<Rectangle.Stroke>
<SolidColorBrush Color="{Binding Path=Machine.Graph.Buzz.ThemeColors[MV Machine Border]}"/>
</Rectangle.Stroke>
</Rectangle>

<Image Source="{Binding Path=MachineImageSource}" SnapsToDevicePixels="True"/>

<Rectangle Name="machinebody" Width="84" Height="34" RadiusX="2" RadiusY="2" Stroke="#DDDDDD" StrokeThickness="2">
<Rectangle.Fill>
<LinearGradientBrush StartPoint="0,0" EndPoint="1,1">
<GradientStop Offset="0" Color="#48000000"/>
<GradientStop Offset="1" Color="#38000000"/>
</LinearGradientBrush>
</Rectangle.Fill>
</Rectangle>
...
...
</Border>

there you find all the elements that make up the machine´s appearance. (LED, buttons, texts ...)

thank you for explaining, I'd be happy to take this topic in a new thread, feel encouraged to start it
now, I actually have some theming problems... the theme which you linked in the other thread, it gives me errors, and finally the whole buzz window went black (there was nothing except black)... I had to resort to deleting the theme (so buzz would automatically reset to default theme)...
much strange!

now, as for the code suggestion, I can not find this code in default theme... I can locate MachineControl.xaml but inside it, there are not these things you mention.

[strobotone]

some more stuff : viewtopic.php?f=3&t=186

[Dean]

some more stuff : viewtopic.php?f=3&t=186

thanks! I'll continue discussion there.

[Dean]

On the topic of cpu performance... I've noticed that Buzz performs better(!) on three cores rather than four.
A song which peaks (stutters) on four cores, can play well without stutter on 3 cores.
I've investigated some about this topic, and I've found that software which for example is written for a two cores
can be optimized by setting the software to use just two cores. But buzz is supposed to be able to handle up to 8 cores, right?
It's puzzling, but I would like to advice those who have trouble with cpu peaking of your e.g. i7 cpu in buzz
to select fewer threads/cores in the settings.

at 1 core and 4 cores, I get stuttering and cpu peaking, at 3 the project in question can play without stutter at around 99% cpu load.
Major difference, as real-time-edits without stuttering is worth a LOT in audio software.

[synthphase]

While I know it's frustrating to hit the proverbial CPU barrier, I bet you there is at least one effect I can remove from your 400 without making any noticeable difference to the song. I hope that doesn't sound dickish, but just try and use the bypass feature on some of those effects - you might get some headroom back as well as CPU if there's something that can be artistically removed. All that being said, I love experimentation in music and would never want to discourage chaos or noise, so I offer another solution since every program is going to have a CPU barrier at some point.

Get Ethernet Midi http://www.linuxsampler.org/ethernetmidi/

Take some of the chains out and replace the notes/data on the generators with Polac midi. Hook it up like this:

Polac Midi out > Virtual Midi port > Ethernet midi out > other PC's Ethernet midi in > Virtual Midi port > Polac wrapped Buzz machine or Midi enabled generator with the same output chain (imported).

Obviously this would take a lot of work and possibly involve transcribing automation data to CC's which would suck, but maybe for future massive projects?

[Buzztler]

Hello ... my last comment here for a while ... My graphics card is one year old and so it is much too old for the new Buzz, in the beginning it should be a fast 3D-card ... now it should have wpf-support. In two weeks MS will find something new, doesn't matter (still have old Buzz working fine under linux.)
For all the people who wanna work with the new Buzz on old "scrap metal" for example a 3.6 Ghz single core and want to have overloader working ... I have in the cpu-monitor of the new Buzz, playing an old Shytan-bmx 20%-30% cpu-load shown. In windows task manager it is shown the true load of Buzz with 80-100% ... .
I'm able to reduce the real cpu load in the windows task manager with the following trick: I click on the menu of Buzz and open it, but I do not make any choice ... I just leave it open and the track runs fine with a real cpu-load in the taskmanager of 40-50%.
Hope it helps for all who want to run the new Buzz (build 1453) on their scrap-metal ... take care ...

[syphilissauna]

I often combine songs into one giant bmx for live shows and have never really had a problem with buzz slowing down .. tho dang 500 machines seems like over kill .

[mcbpete]

My graphics card is one year old and so it is much too old for the new Buzz

The graphics card on my last laptop was 6 years old and was just fine for the new Buzz builds (the last release I used on it was 1453)