PlanetZ forums - scopeusers.com

Hi,

When I create lots of midi cc inside modules or midi devices the cpu jumps to unseen heights....... its probably something we have to live with ?

For example I tried the new morph modules, and when I add 3 CC's to some morphing knob the cpu goes to 90%

Also noticed this with control smoothed signals which I give midi CC.......

any ideas/modules to help with this ?

edit: perhaps I should create a seperate box for this.......
any windows/*nix software which could do this for me ?!?!?!?

My first attempt will be to write it using PureData. It seems capable of it.

If you know of any other solutions please let me know!

90% is a lot… which CPU do you have right now?

Its a P4 2.5Ghz!

It takes almost no CPU if I use only modular signals. But when I assign a midi cc to one of the signals (so it gets send out the modular) the CPU starts climbing each time I add one CC.......

Well, it is not a big CPU for today world, but definitely enough for what you’re doing. Have you analyzed the whole process just in case you are sending a wrong signal? It could be a loop signal somewhere.

I am out of ideas here… anybody please?

Medhi confirmed that midi processing takes alot of CPU. So basicly I am dealing with it. I will definitly test on a better DAW when I have it.

However, I made my first successull midi smoother in PureData! Probably not smooth enough but its working, can learn & assign the midi cc just fine

Its pretty cool! for a firs try

lol

CPU still going mad

Ok I changed the midi routing into scope a bit, its working better now!

I have 5 midi fades running with various speeds and the CPU stays under 20% most of the time!!

Partly, I havent tried the scope midi tools with this setup.

What I routed the signal thru usb -> midi-ox -> scope -> puredata -> scope which caused some extra cpu. Changing it to puredata -> scope saved some CPU.

I also think the USB driver of my midi controllers is party the problem, so I will have to test with direct midi connections into scope!!

Currently I think I will need a seperate midi control box. I have yet to decide how I will route the midi signals from MidiBox -> Scope DAW.

Perhaps its best to use normal midi cables ?

Or midi over lan perhaps ? I could even have PureData transmit the signals over LAN I think........ options options... choices choices...


I think I can route 3 midi cables into my scope cards, should be enough. but maybe midi over lan is faster ???

Francis: this looks a bit like the problem I had with Scope and Hubi's Loopback device: http://www.planetz.com/forums/viewtopic.php?t=23970 - I had terrible MIDI problems while dragging events in the screen. It all got sorted after I started using Reaper to open Scope ASIO and echo the MIDI into it.

Also great to see you're taking programming into your own hands. I'm just starting out on Max/MSP myself (slooowly) Doesn't seem so bad after a few years of ModIII and Nord modular...

peace,

T

FrancisHarmany wrote:...I have 5 midi fades running with various speeds and the CPU stays under 20% most of the time!!

you might want to drag the faders to a part off screen and watch if that has an influence on the CPU load.
I.e is it the graphic or the midi data processing that causes the load increase.
It may not be a very reliable test, as it depends on how the graphic is programmed, but there is a chance that load decreases - and if it does, you don't have to dig deeper in the midi stuff
The midi driver may misbehave if it's programmed in a 'not-so-cooperative-way'.
Midi processing isn't such a big deal for the CPU but the routine may lock out other processes to keep it's timing clean.
That pretends a false 'huge' demand of processing resources.

To be honest, I'm not a Windows programming expert, but some experiences make me think into that direction. Mind you, the basic programming was done when a CPU had 166 MHZ clockrate...

cheers, Tom

Ok thanks for your input!!

Tested 10 cc fade signals, connected to 2 dynamic mixers (10 channels each).

With scope open and the dynamix mixers visible:
-- around 60% CPU

With scope minimized (but mixers are "visible" when you open scope again
-- around 20% CPU

With scope open/closed, mixers not visible:
-- 15 / 18 % CPU

26 CC Fade channels, linked to 40 knobs/faders in scope:
-- 40% CPU

I will try various routings/setups to see if I can get it more stable. After that I will test with with real audio going through scope, cause these tests are all done in empty projects!! Perhaps the midi cpu issues wont really effect the sound....

So 40% is OK, I think it will be much less when I generate the signals on another PC and send them via midi overlan or directly into the scope midi
inputs. And of course the new DAW which should be comming this year .

FrancisHarmany wrote:...With scope open and the dynamix mixers visible:
-- around 60% CPU

With scope minimized (but mixers are "visible" when you open scope again
-- around 20% CPU ...

as you can see the screen updates produce a CPU load that's 3 times as high as midi processing alone - it's not the midi driver, processing or routing

cheers, Tom

you are wrong...

if I create 20 smoothed fades in modular the cpu is still 80%

well, it wasn't me who provided the figures...
the quote above clearly says that moving the stuff into 'offscreen' takes 2 thirds of the load away

the 'smoothing' example is a different story, I have no idea in which way it is performed - in other words I dunno the Modular project doing the job.

not sure about smoothing, but if you're into morphing stuff the Tobybear Controller might be worth a look...

cheers, Tom

yes, imho wx is a piece of crap
wherever it's used you have these strange 'redraw effects' if you quickly move stuff over the screen. AOL once had client software based on it and EnergyXT is similiar.
The latter can release a thunderstorm of crackles when it's communicating with Scope Asio and you fiddle with Scope GUI elements...
But as I dunno in which way Scope handles pure midi stuff one has to rule out one or the other.

cheers, Tom

I don't know if it's relevant here, but if Cubase charges the CPU a lot, I also experience that 'thunderstorm' Tom is talking about.
Moving the windows out of sight solves the (refreshing graphics) problem (indeed), more helpfull is it to move all windows to the analog connected TFT...


Another aspect is that audio recordings don't get affected by the clicks, after realtime ASIO recording I mean, not freezing/audio export.

hopefully next week I will have my new hardware + fresh installation. Should clear up alot of troubles!! (DP35DPM. duocore 3+ ghz and 4gb mem!!)

Astroman: its definitly a problem with the midi cc's being generated inside scope! it seems stuff like puredata, or that Toby MCC stuff will do a better job (thanks for the link).

I guess it might save cpu if we have a module which only outputs 127 steps, and only generates CC when the output changes. but perhaps thats already how it works under the hood.... I have no clue