hi olivier, thanks for testing nova and for your comments ...
> For now I can get two reproductible crashes: > - Create a new patch and put this object: [inlet 1]. Immediately after, > rename the object to: [inlet 1 2]... CRASH. > - Create a dac~ object with more outputs than defined in the > preferences, eg. a [dac~ 1 2 3 4 5 6] when only four outputs are > defined... CRASH. i can reproduce both crashes ... i will have a closer look at them later on ... > > 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. if you want to help me a bit more: - is there audio coming out of nova? - can you run a profiler, to figure out, where all the cpu cycles are burned? to me, it somehow looks like a life-lock ... > The questions I would like to ask: > - How is it possible to add comments with more than 2 lines? first i have to mention, that the gui objects are still in the state of a prototype. you can shift+drag the gui.comment box to a certain shape, but iirc, the shape is not stored in the patch, yet ... > - Do we have access to the length of a buffer~ (like with the arraysize > object of PD)? not yet ... but you are right, that should be added ... > - Is it possible to create a subpatch locally (like the [pd mysub] > object in PD)? sure ... |p mysub| ... > - How fast are python objects done with pyx compared to a plain C++ > external? well, that is a good question ... all python code is interpreted in a separate thread, since python is not realtime safe ... so it is definitely slower, both in the code execution and in the synchronization. in the best case, the python objects introduce a message-delay of one sample-block... on the other hand, if c++ externals are not realtime-safe, they would have to be detached to a helper thread, too ... > The things I would miss to switch completely to nova: > - midi objects and a poly object i have been thinking about introducing midi objects, but would prefer not to ... the reasons are: - different backends on different platforms ... i am not sure, how well portmidi works, though - i consider midi a broken and obsolete standard 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 :) 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 ... > - non audio arrays and objects to access them yes, i need to write some non-trivial control data structions ... > - file IO to store arrays yes ... > - more GUIs!! yes ... i hope to get some help from mischan and niklas (and phil?) in the gui development > - fft objects fft objects are another problem, where i am not sure. yet, how to design them. the implementation in pd is straight-forward, but quite inefficient. i am still thinking of a cleaner way to implement them into nova, maybe using fftin~/fftout~ objects ... > That said, I would like to help in nova developement too, but I am > affraid my C++ programming skills are too bad. Maybe with a clean and > well documented sample external plugin, i could convert some Pure Data > externals... However, are you interested on documentation patches? 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 - 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 ... - 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 :) thanks, tim -- [EMAIL PROTECTED] ICQ: 96771783 http://tim.klingt.org Most of the trouble in this world has been caused by folks who can't mind their own business, because they have no business of their own to mind, any more than a smallpox virus has. William S. Burroughs
signature.asc
Description: This is a digitally signed message part
_______________________________________________ nova-dev mailing list [email protected] http://klingt.org/cgi-bin/mailman/listinfo/nova-dev http://tim.klingt.org/nova
