| Richard Dobson wrote:
> Well, making Csound re-entrant will benefit all platforms. COM is indeed a
> Microsoft invention (though they do have a version for the Mac, and are trying
> to extend it to unix through DCOM - Idon't know how realistic this is, or how
> much take-up there is), so the particular ideas Michael Gogins and I have been
> exploring are indeed specific to that platform. I do think that once the
> re-entrancy has been achieved, developers on all platforms will jump at the
> opportunity to create all manner of powerful facilities.
I think re-entrancy should be the first goal. One this is achieved, all
sorts of server functionality can be achieved on many if not all of
Csound's platforms. Focusing on COM or on any other specific API at this
point will fragment the efforts of Csound developers...
Looking at the code for Csound, I'm struck by its two-pass nature: a parser
builds instrument files into complicated data structures representing the
instruments, while another parser turns score files into a chain of data
structures representing "notes." The result of these two parsings is then
fed to a "virtual machine" that does the actual calls, via function pointers,
to the various units, based on the chain of note events (and optionally,
additional events generated via MIDI or other real-time sources).
Reflecting on this, I think that one avenue for development is to make
the virtual-machine nature of "pass two" more explicit. This is in line
with the suggestion that several on this list have made to look into
sound-modeling methods like those proposed for MPEG-4. Taking a page from
compiler technology, the output of *.orc and *.sco parsing could be made
into an explicitly-defined intermediate language that the Csound "virtual
machine" interprets. I know that this might sound wild to some folks,
but in essence this is pretty close to what is already happening inside
Csound. Allowing streams of this internal language to coexist with streams
of sound data, plus the ability to make the Csound "engine" re-entrant,
would move Csound well along the road to scalable distributed processing,
among other possibilities. Want to produce 200 simultaneous voices in
real-time? Just add on a few cheap Pentium (or Alpha!) boxes with network
cards, and it will be so...
> A properly developed Windows application is supposed to provide keyboard
> alternative for all mouse commands, and such things as menu controls are almost
> automatic, using Visual C++. I like keyboard control myself, so I do not neglect
> this feature in my own work!
And they say that the command-line is dead... Not to make too fine a point,
but I'm amused at how Windows power-users (like Mac power-users) use single-
key commands that make the two-letter commands of early Unix seem downright
verbose! But this is really another thread entirely...
>
> Richard Dobson
>
> Jim Stevenson wrote:
> >
> > Oh arg!
> >
> > Please don't limit such promising development tools to M$,
> > and please do include commands to do * ALL * the mouse functions.
It's not a MS vs. anti-MS thing. The effort to make software truly
multi-platform can also make it better software in the long run. Those
of us who have been following Microsoft for a while are well-aware that
use of one of their technical standards--especially one of those on the
leading edge--is no guarantee against early obsolescence.
-Ed
|