Csound Csound-dev Csound-tekno Search About

Re: Proposal for a new version of Csound

Date1999-06-26 17:48
FromMichael Gogins
SubjectRe: Proposal for a new version of Csound
I think you may have slightly misunderstood my question.

I did not mean an abstract interface was necessary for UGs to access
function tables, only that one would be required to UGs to access function
tables exported by some other, non-Csound application hosting the UG. But I
may be wrong about this...

What do you think about this idea? Would you be open to using this
JavaCsound kernel in Quasimodo, or merging the two kernels into one (as a
shared library, it can support any number of external interfaces, including,
as I have said, Java, VST-2, Buzz machines, etc.).

-----Original Message-----
From: Paul Barton-Davis 
To: Michael Gogins 
Cc: csound@noether.ex.ac.uk 
Date: Saturday, June 26, 1999 12:37 PM
Subject: Re: Proposal for a new version of Csound


>>Fortunately or unfortunately, Csound UGs need access to global objects in
>>the Csound kernel, notably various rate variables and the function table
>>array. They cannot really work in isolation. If the UG "type" were changed
>>to perform this access through an abstract interface that other
applications
>>could implement, it would work, but then that would be an even deeper
>>rewrite of Csound than I am contemplating.
>
>Michael - this isn't true. There is no reason to change the UG "type"
>in order to provide access to rate variables and function tables.
>I know this because I've done it in Quasimodo. This is certainly true
>for Unix dynamic libraries anyway, and I was under the impression that
>the Windows DLL's worked similarly. Perhaps not.
>
>BTW, Quasimodo also changed the UG argument type to be a C++ object,
>which allows much greater flexibility and also allows you to use the
>compiler to take of allocation, which avoids some of the silly
>problems with alignment that regular Csound has had on 64 bit machines.
>However, the object looks identical from the point of view of an
>opcode function.
>
>Also, as far as C++ goes, although its true there is often a small
>speed penalty even for identical code, in the places where it matters
>(execution opcode functions), egcs spits out almost identical code for
>C or C++ compilation. There's really nowhere else in Csound where the
>difference between the two languages makes a significant difference in
>terms of speed.
>
>--p
>
>

Date1999-06-26 18:29
FromPaul Barton-Davis
SubjectRe: Proposal for a new version of Csound
>I did not mean an abstract interface was necessary for UGs to access
>function tables, only that one would be required to UGs to access function
>tables exported by some other, non-Csound application hosting the UG. But I
>may be wrong about this...

FUNC's *are* an abstract interface, because the data itself is held in
a pointer to the storage, rather than within the FUNC itself. This
allows other applications to create the data, and then make it
available to Csound UG's by wrapping the data with a FUNC structure,
and putting into the list of tables. Thats the only piece of glue you
need.

There are several places in Quasimodo (e.g. my version of spliner,
that lets you draw your own function tables with the mouse) where I do
exactly this operation: generate the data, call for it to be wrapped
as a FunctionTable, and presto, FunctionTable::find (const char *name)
can find it.

>What do you think about this idea? Would you be open to using this
>JavaCsound kernel in Quasimodo, or merging the two kernels into one (as a
>shared library, 

If it means moving away from C++, I'm not in favor of it. If it means
not using a formal grammar, I'm not in favor of it. 

In addition, two things I forgot to mention in my quasimodo overview:

* Quasimodo can handle any number of quoted strings in the arguments to an
  opcode. It is not limited to one-string-per-call the way that Csound is.
* Quasimodo uses names for function tables and instruments, not numbers,
  though the names can be numeric if you so wish.

The first one of these has lots of implications for the parser and
compiler, and requires a dirty trick involving inner knowledge of IEEE
32 bit float format. The second one has less implications, but they
are still significant. I would not give up either of these features gladly.

>it can support any number of external interfaces, including, 
>as I have said, Java, VST-2, Buzz machines, etc.).

This is true, and a very desirable goal. But I'm very familiar with
the benefits I've gained from using C++, and I am loathe to abandon
them for the sake of interoperability. Your advocacy on behalf of Java
over C++ is something I would echo on behalf of C++ over C for this
purpose. Managing the complexity of the internal compiler in C is not
impossible, but it is harder.

--p

ps. while i'm here:

* Quasimodo has an abstract interface for its internal DSP object. Porting
  Quasimodo to a plugin card with some kind of DSP(s) on it is mostly
  just a matter of reimplementing the DSP object. (this is currently an