Tim Blechmann a écrit : >> Regarding CPU consumption (my machine is an AMD-XP2500+ 1Gb RAM realtime >> kernel 2.6.22): >> - After lauchning nova_gui.py, i get around 5-10% CPU and 12-15% RAM >> consumption. Selected audio device is dummy. >> - After choosing portaudio, CPU consumption goes up to 95% and stay >> here, even if there is no patch, no computation. However, system keeps >> responsive. Is it normal? >> > > hm ... there is definitely something wrong there ... can you tell me: > - which portaudio backend are you using (oss/alsa/jack)? > - which compiler version are you using? two days ago, i came across a > problem in the assembler code for <=gcc-4.1, that i haven't examined, > yet. basically i recommend that people use gcc-4.2 for compiling nova. > My gcc is 4.1.2...
> if you want to help me a bit more: > - is there audio coming out of nova? > Yes. Audio works like it was supposed to. > - can you run a profiler, to figure out, where all the cpu cycles are > burned? to me, it somehow looks like a life-lock ... > Excuse me, but, I don't know what a profiler is, and how I should use it. Any link? > - i consider midi a broken and obsolete standard > Yes, I agree, but, you know, it is the standard again. I have never seen a keyboard with an ethernet port. > i am using midi devices myself, using a standalone midi-to-osc converter > (written in supercollider), so nova only needs to handle osc data. > but of course one could write midi objects as externals :) > Ok, why not. A converter done with Pure Data.. ;) Even if I agree with you, and it is not a problem for me to do a converter with PD or Csound or Chuck, not having midi could be dissuasive for some users. > polyphony is problem, that i have been thinking about, but haven't found > a good solution, yet ... currently one has to build polyphonic patches > discrete, like in pd ... a max-like poly object could be implemented > into the core, but i am not sure, about the design, yet ... > Discrete is Ok for me. I would just need an equivalent of PD's [poly] object. I could look for a pyx alternative... > there are actually quite a number of things, you could contribute, if > you are willing to spent some time on nova: > - if you are fluent in python, you could help with the development of > the gui, gui objects, improved versions of the dialog/property windows > and so on > I don't think I am fluent enough, but that could be a good training for me. > - if you are interested in writing help patches, that would be > awesome ... at the moment, there is just a small number of objects, that > have been documented properly (my attempts can be found > in ./help/reference/) ... not to speak of introduction patches ... > Yes I have seen your help patches. I can do some more if you are interested. The main question is: "should I wait for gui messages and numbers to be ready before preparing an exhaustive set of help patches?" > - and of course it would be a great help, if you test nova ... i can > only fix the bugs, that i either experience myself, or that other people > find and tell me how to reproduce :) > I won't hesitate to report the bugs i find. Bye, -- Olivier _______________________________________________ nova-dev mailing list [email protected] http://klingt.org/cgi-bin/mailman/listinfo/nova-dev http://tim.klingt.org/nova
