hi marius,

> that is somewhat sad to read. but I think there are many reasons for it.
> first, it only runs on linux. if you want people to use it, you have to 
> provide win and mac binaries. or at least support compiling, which did 
> not work for me (I have sndlib and portaudio lib, but I keep getting 
> error messages that they are not found...)

unfortunately, you are right .. it is not easy to build it on osx or
windo$ ... for osx, it is possible, though ... i once compiled a version
on klaus filip's old imac ... for windows, it should compile, although
someone would have to adapt the build system ...

but possibly, i should also bundle portaudio, libsndfile and scons ... i
won't bother bundling python, qt and pyqt, though ...

> second you would have to provide better documentation, including a 
> webpage, people complain about this in in pd, and pd has already a lot 
> of documentation.
> and then, I think you need to find people that use it for their work. 
> that could be students (for example, when you teach at a university) or 
> corporate clients (that use it for some installation).

well, documentation is one point, most of the documentation that i
wrote, are simple reference patches ... i was always hoping, that
someone would join, helping in these parts ...

> similar to this is the question of compatibilty. have you thought about 
> compatibility to pd and max? would it be possible to load pd-patches?

not really, although nova shares a common subset with pd/max, the
language is not 100% compatible ... i implemented some new concepts, for
which i had to drop the compatibility ...

> also, have you looked at the new file format for max5 patches? 

no, but it is good to read, they _have_ a new file format ... :)

> would it 
> be possible to get a tool like flext, that creates a nova and pd 
> external from one codebase?

when i started nova, i had a closer look at the flext api ... i guess,
it would be possible to write a backend for flext, targeting nova, but
it is not easy ... max and pd share the same codebase, the api is not
too different ... nova uses an api, which is quite different, though,
since it was designed in c++ in the last two years, and not in c in the
1980s :P

> In the US with the current state of your technology you would now try to 
> get a nice sum of investment money (like 1-10 mio dollars) and make it a 
> proprietory new software product. From what I read in your paper, you 
> have probably the fastest dsp kernel for realtime audio available. 
> Interested people might sit in the gaming industry (sony, EA) or in the 
> research labs of (future) mobile devices (nokia, apple, ...).

fortunately, i am not in the us ;)

i am pretty sure, that it is quite hard to come up with a more efficient
dsp engine than novas for uniprocessors ... i will have to find a way to
run the dsp engine on multiprocessor machines, though ... the
max-paradigm is basically broken for this ... an interesting approach
would be to use a realtime scripting language for accessing the dsp
graph manually ...

cheers, tim

--
[EMAIL PROTECTED]
http://tim.klingt.org

Linux is like a wigwam: no windows, no gates, apache inside, stable.

Attachment: 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

Reply via email to