On Nov 7, 2007, at 2:35 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
AFAIK, MySQL and the like do not guarantee realtime responses, and network connections certainly do not. So if want something that is designed to do that, then use [pool], [textfile], or perhaps an embedded SQLlite, if it is quick enough.
Unless there are ways to guarantee the database will reply within one clock tick (usually ~1.5ms), then the interface should represent the reality of the situation. Otherwise the database object will cause lots of clicks and interruptions when used.
SQLite is fast. In most cases, MySQL etc. will be fast enough as well, but of course no common DB gives realtime guarantees. But neither does [textfile], e.g. when responding to the "read"-command: Loading large textfiles will halt execution as well. (Btw: An important use of SQL in Pd would be as a replacement for [textfile] if you need to parse tons of data, like gigabytes, as you can read row by row in nanoseconds with a realtime response that would be better than [textile] by miles.)
Pyext's approach of offering threading as an option is the most flexible and it's what first inspired my remark. If you want to use a sql-db as a way to store and load data for use in your logic, you often *need* deterministic behaviour. Of course then it's in your own responsibility to make sure you meet the deadlines, for example by optimizing queries, using fast, local DBs etc.
But the need to do deterministic queries sometimes (or rather often) must not be ignored by designing a SQL class for Pd with only threaded use in mind.
As databases can be used in so many different ways, I still favour the DIY approach using Python or Lua or so anyway. It's again a use case, where not the interpreted language is the bottleneck, but an outside factor. A C-class for SQL querying wouldn't be any faster than the (existing) Python/Lua classes, if the database is too slow.
Using threads in a Pd objects without representing it in the interface is a recipe for very difficult bugs. Talk to Max/MSP about bugs in "Overdrive" mode. Most people solve them by turning off overdrive, from what I hear.
Making the interface reflect the threaded nature doesn't have to be complicated. It could just be that you give each query a message ID which is prepended to the result. A deterministic database query object will cause interruptions, especially if there is any network activity involved. It would be a shame to have a database object that couldn't be used with realtime audio, video, etc.
I think the bigger issue is that people want to use Pd to interface all sorts of things that can't be deterministic. So it would be good if we figure out how to make that work well in the context of programming in Pd. "It's pretty good, but it interrupts sometimes" doesn't sound like a goal to strive for.
.hc
------------------------------------------------------------------------ ----
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie