|
From: Rui N. C. <rn...@rn...> - 2004-06-15 14:04:37
|
Vladimir, > > I'm sorry, i forgot about this . . . I've added this event to illustrate > how this *could* be done with events :) > I have nothing against your proposal to load instruments in the > background and have an extra status field in CHANNEL_INFO. > I'm not sure about the implementation on the server though . . . might be > a bit more difficult. I'll look into that at some point. No problem. I'm just insisting to make it official on the draft protocol specification. I know that's not that immediately obvious to implement the progress notification/status on the server side, at least without tweaking on libgig, as Christian once noted. Most probably, libgig has to be changed accordingly and the load process will be spawned as an appropriate thread. A server channel instance variable will have to be used in anyway to keep channel/instrument status progress, that gets updated on each loaded chunk. I'm sure, for the time being, we can fool things up on the server and, upon receiving a LOAD INSTRUMENT command, the server will do: 1) Check for file validity, by checking for it's existence and naively verify if it's of one of the supported formats (gig, dls or whatever). 2) If yes, send the "OK" response immediately to the client, and set the progress status variable to "0" (zero percent). Otherwise an error status value will be set (e.g. "ERR"). 3) Load the instrument file as it would do normally, as is. 4) Right after the load completes, just update the status variable with a succesful "OK", or "ERR" otherwise. Let's face it, the error status may hold the actual final response to the LOAD INSTRUMENT command, as it was until now. The value stored on this server channel status variable is exactly the one that will be held on the INSTRUMENT_STATUS field of the GET CHANNEL_INFO command. Clear? Honestly, I think this isn't that hard to do on the server side. The actual progress threading and probable libgig changes can be just left to when Christians get back. Until then, everybody will be happier, me and qsampler :) If all this is OK, I can make the changes myself to the draft document. Yet again, it will bump to v.09. The summary preview of changes are: 4.4.1 LOAD INSTRUMENT slight semantics change; 4.4.9 GET CHANNEL INFO response new status field, INSTRUMENT_STATUS; 6.6 INSTRUMENT_LOADING event type simply vanishes away. > Any other comments? > Oh, just a minor: about CHANNEL_BUFFER_FILL event type (6.4), ermm... wouldn't it be nicer to just name it BUFFER_FILL ? Note that on all other event types a sampler channel is always implied, so why include it on the event name on this one? Bye now. -- rncbc aka Rui Nuno Capela rn...@rn... |