hi roman, > - errors: > in pd many objects print their errors to the console, which makes it > impossible to take them into account within a patch. i think this is a > big flaw (if it pd is considered to be a programming language [and that > is how i use pd])
objects should give good error messages, and there should be an infrastructure to handle errors ... there is already the infrastructure to throw and track exceptions, however it is not widely used, yet ... > - reporting: > many objects are able to print their current state (connection, on/off, > whatsoever) to the console, but not to an outlet. others don't report > their state at all, while reporting would be helpful. this is somehow related to `attributes' ... i was thinking about flext/jitter-like attributes for nova, haven't been finding a powerful way to use and define them, yet ... > - networking > actually the problem described above (reporting): all network objects in > pd use a standard buffer of 4kB. if the buffer is full, processing is > stopped, which causes audio drop outs. i think it would make sense for > all objects that establish a connection and buffer messages, if they > would report their actual buffer state. in case of the network objects, > it would aready be sufficient, if they would send a 'bang' or whatever, > whenever the buffer is emptied. with that information, patches could be > built, that send only the next message, if the buffer is empty, but at > the same time use the maximum bandwidth available. i'm using a helper thread and a powerful networking library (boost::asio), so all the problems, pd runs into because of it's crappy implementation shouldn't be a problem in nova ... > - reading~ from tables > pd's abilities to deal with samples are quite limited. if reading > directly from disk, you can only play at actual samplerate, that pd is > running. not only that, but you also cannot start playback from an > arbitrary point within the file (you can use some hacks, but they only > work, if you set headersize, bytes per sample, channels, endianess etc > yourself -> not a clean solution). if non-standard speed is needed, > samples need to be loaded into tables. however this is limited by ram, > which isn't that much an issue anymore nowadays. but there is also a > problem with floating point precision. depeding on your quality needs, > you are very limited in sample size, since above a certain index the > floating point representation is not precise enough anymore to set the > index accurately. actually, i don't know how this could be solved, but > if it would be solved, it would be a big PLUS for nova. the way to go here would be high-resolution objects, which internally work with double-precision floating point numbers ... cheers, tim ps, i'll soon try to set up a wiki on the plone site to collect ideas -- [EMAIL PROTECTED] http://tim.klingt.org The first question I ask myself when something doesn't seem to be beautiful is why do I think it's not beautiful. And very shortly you discover that there is no reason. John Cage.
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
