Discussion:
Proposal for a new version of Csound
(too old to reply)
Michael Gogins
1999-06-26 05:55:06 UTC
Permalink
Michel Jullian
1999-06-26 16:37:29 UTC
Permalink
To summarize, the idea is to do a kernel rewrite of Csound that implements
the existing orchestra language, score language, commands, and behavior in a
shared library.
That will certainly expand the scope of Csound, and pave the way to (my dream,
as some may have noticed) compilation of Csound instruments as lightweight
VST2 dlls relying on the shared library for DSP work.
Completely platform-independent kernel written in ANSI C using only the
runtime library.
Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
Plugin unit generators.
Plugin function tables.
Flexible growth for Csound. Will direct loading of Csound Plugin UGs by other
frameworks be allowed ? Why not make it a universal Plugin interface for UGs ?
Java interface that integrates with the JavaSound API.
Java GUI and I/O code on top of fast multiplatform DSP code. That's a perfect
combination IMHO.
If anyone is interested in working with me on this, email me.
I hope there will be many candidates. I doubt I'll be able to participate in
the coding (i wish i was government funded like you all lucky academics), but
as a potential user I am very interested and would love to be informed of, and
if I can at all contribute to, this project's developments.

In any case thank you Michael for this very constructive proposal.
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email ***@exbang.com
Exbang Industries S.A.
Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
Maurin 34970 Lattes France fax +33(0) 499 529 879
.........................................................................


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-26 16:15:03 UTC
Permalink
Thanks for your response. I will address your points in the order raised.
Post by Michel Jullian
Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
C is still a little bit faster, and Csound is written almost entirely in C.
Post by Michel Jullian
Plugin unit generators.
Plugin function tables.
Flexible growth for Csound. Will direct loading of Csound Plugin UGs by
other
Post by Michel Jullian
frameworks be allowed ? Why not make it a universal Plugin interface for
UGs ?


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.
Post by Michel Jullian
I hope there will be many candidates. I doubt I'll be able to participate
in
Post by Michel Jullian
the coding (i wish i was government funded like you all lucky academics),
but
Post by Michel Jullian
as a potential user I am very interested and would love to be informed of,
and
Post by Michel Jullian
if I can at all contribute to, this project's developments.
I am not an academic. I have a fulltime day job as a C++ programmer.



dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Paul Barton-Davis
1999-06-26 16:50:01 UTC
Permalink
Post by Michel Jullian
To summarize, the idea is to do a kernel rewrite of Csound that implements
the existing orchestra language, score language, commands, and behavior in a
shared library.
Why do you want to start with Csound when Quasimodo is already running
and much closer to what you're talking about than Csound ?
Post by Michel Jullian
Completely platform-independent kernel written in ANSI C using only the
runtime library.
Ah, now there's your reason :)

I hope that you will at least consider using the Csound orchestra
parser from Quasimodo rather than hacking up another "custom parser"
like the one already in Csound.
Post by Michel Jullian
Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
Indeed. Although actually, no, because of the speed penalty. This is
one area where you don't want to mess around with too many object
abstractions - its in the inner loop of Csound's execution. However,
that doesn't stop you from using some aspects of C++ for the arguments
to an opcode function, or its internals.

--p

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michel Jullian
1999-06-26 19:45:56 UTC
Permalink
Post by Paul Barton-Davis
Post by Michel Jullian
Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
Indeed. Although actually, no, because of the speed penalty. This is
one area where you don't want to mess around with too many object
abstractions - its in the inner loop of Csound's execution.
You mean calling an object's method is actually longer than calling an
otherwise identical C function ? Why ? (sorry if that's obvious) Or is there
some silly redirection from the object to the class and from the class to the
corresponding function (I would have thought that would be solved at compile
time as a pointer to a function) ?

BTW, I agree it might be better for Michael's project to start from Quasimodo,
or for both of you to unite your efforts to make Quasimodo the next improved
version of Csound.
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email ***@exbang.com
Exbang Industries S.A.
Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
Maurin 34970 Lattes France fax +33(0) 499 529 879
.........................................................................



dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Caliban Tiresias Darklock
1999-06-26 17:17:40 UTC
Permalink
On 12:15 PM 6/26/99 -0400, I personally witnessed Michael Gogins jumping up
Post by Michael Gogins
Post by Michel Jullian
Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
C is still a little bit faster, and Csound is written almost entirely in C.
I might also add that C++ compilers are still not wholly
standard-compliant. It's next to impossible to find a C compiler that
*doesn't* conform precisely to the ANSI C standard, but C++ compilers (and
their interpretations of the less-mature C++ standard) have subtle and
important differences that would severely damage portability.

I've always sort of looked at C++ as the language to use when (a) your
project and/or team gets too large for C to be effective because you spend
more time arguing about implementation than you do writing code, and (b)
portability is not critical. For CSound, portability *is* critical, and I
don't think the team has gotten that large yet. ;)

-----
| Caliban Tiresias Darklock ***@darklock.com
| Darklock Communications http://www.darklock.com/
| U L T I M A T E U N I V E R S E I S N O T D E A D
| 774577496C6C6E457645727355626D4974H -=CABAL::3146=-

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Chris Townsend
1999-06-26 18:58:54 UTC
Permalink
Post by Michel Jullian
Post by Paul Barton-Davis
Post by Michel Jullian
Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
Indeed. Although actually, no, because of the speed penalty. This is
one area where you don't want to mess around with too many object
abstractions - its in the inner loop of Csound's execution.
You mean calling an object's method is actually longer than calling an
otherwise identical C function ? Why ? (sorry if that's obvious) Or is there
some silly redirection from the object to the class and from the class to the
corresponding function (I would have thought that would be solved at compile
time as a pointer to a function) ?
I was under the impression that a slow down would only occur if you use
virtual functions, but the use of virtual functions can be avoided, so I
don't see any real problem here. Why avoid using C++ altogether, just
because it has SOME features that might cause slower execution or
incompatibilities between compilers? In other words, don't throw the baby
out with the bath water.


-Chris


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-26 19:37:42 UTC
Permalink
C or C++, this is a side issue. I don't care as long as the thing runs on
all JavaSound platforms. That is currently Windows and Solaris and soon to
be Linux. Presumably the Mac will come some day.

-----Original Message-----
From: Chris Townsend <***@townsend.net>
To: music-***@shoko.calarts.edu <music-***@shoko.calarts.edu>
Date: Saturday, June 26, 1999 3:22 PM
Subject: Re: Proposal for a new version of Csound
Post by Chris Townsend
Post by Michel Jullian
Post by Paul Barton-Davis
Post by Michel Jullian
Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
Indeed. Although actually, no, because of the speed penalty. This is
one area where you don't want to mess around with too many object
abstractions - its in the inner loop of Csound's execution.
You mean calling an object's method is actually longer than calling an
otherwise identical C function ? Why ? (sorry if that's obvious) Or is
there
Post by Chris Townsend
Post by Michel Jullian
some silly redirection from the object to the class and from the class to
the
Post by Chris Townsend
Post by Michel Jullian
corresponding function (I would have thought that would be solved at
compile
Post by Chris Townsend
Post by Michel Jullian
time as a pointer to a function) ?
I was under the impression that a slow down would only occur if you use
virtual functions, but the use of virtual functions can be avoided, so I
don't see any real problem here. Why avoid using C++ altogether, just
because it has SOME features that might cause slower execution or
incompatibilities between compilers? In other words, don't throw the baby
out with the bath water.
-Chris
dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Ross Bencina
1999-06-27 02:08:45 UTC
Permalink
Post by Chris Townsend
I was under the impression that a slow down would only occur if you use
virtual functions, but the use of virtual functions can be avoided, so I
don't see any real problem here.
Given that any kind of polymorphic opcode execution is going to involve
vectoring through a function pointer in a structure (ie an explicit vtable)
I'm curious to know how C++ virtual functions would be slower than an
explicit C implementation of same. But yes, presumably you would aviod using
virtual functions elsewhere if you really thought it would make a
difference.

Ross.



dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Larry Troxler
1999-06-27 00:45:37 UTC
Permalink
Post by Ross Bencina
Post by Chris Townsend
I was under the impression that a slow down would only occur if you use
virtual functions, but the use of virtual functions can be avoided, so I
don't see any real problem here.
Given that any kind of polymorphic opcode execution is going to involve
vectoring through a function pointer in a structure (ie an explicit vtable)
I'm curious to know how C++ virtual functions would be slower than an
explicit C implementation of same. But yes, presumably you would aviod using
virtual functions elsewhere if you really thought it would make a
difference.
Ross.
dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Yeah, I think I'll jump in here finally to echo the same opinion! I hear
all the time how using C++ is supposed to somehow result in slower code
than the equivalent program coded in C. And I just don't see how that
can be. I think of C++ as just a cleaner notation for the same things
you would otherwise accomplish in C. In the realm of single inheritance
and virtual functions, I really fail to see why there would be a
performance difference. I suspect that this is some kind of false
folkore that won't go away. (especially since I've heard arguments to
the effect that the farther a derived class is removed from a base
class, the slower the code!) On the other hand, I've also seen this
performance reservation from people who I think are not stupid, but are
quite familiar with both C and C++ and have been using them both.

So, is the "C++ is slower" thing just a programmer's urban myth? I think
it is!


Larry


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Quickling
1999-06-27 03:40:20 UTC
Permalink
My humble opinion is also that the performance
difference between C and C++ is negligible for
nearly all non-critical-loop code. The only
? spots I've heard about are the overhead of
virtual function lookup and of pushing the
object instance pointer for passing to member
functions (more a ? for recursion). Critical
inner loops shouldn't be calling non-inline
functions anyway! Or if you have to, pass
via registers so the hit is small...


-Jesse
Post by Larry Troxler
Yeah, I think I'll jump in here finally to echo the same opinion! I hear
all the time how using C++ is supposed to somehow result in slower code
than the equivalent program coded in C. And I just don't see how that
can be. I think of C++ as just a cleaner notation for the same things
you would otherwise accomplish in C. In the realm of single inheritance
and virtual functions, I really fail to see why there would be a
performance difference. I suspect that this is some kind of false
folkore that won't go away. (especially since I've heard arguments to
the effect that the farther a derived class is removed from a base
class, the slower the code!) On the other hand, I've also seen this
performance reservation from people who I think are not stupid, but are
quite familiar with both C and C++ and have been using them both.
So, is the "C++ is slower" thing just a programmer's urban myth? I think
it is!
Larry
dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
troy straszheim
1999-06-27 07:33:00 UTC
Permalink
Post by Larry Troxler
Yeah, I think I'll jump in here finally to echo the same opinion! I hear
all the time how using C++ is supposed to somehow result in slower code
than the equivalent program coded in C.
that's murky: "equivalent program". not a fruitful line of inquiry. One could
write ten different programs to sort arrays of integers, all in the same
language, and they all have different performance characteristics, due to the
different ways they're compiled and also from the different behaviors of the
different algorithms.

you could have "equivalent programs" coded in C and BASIC, for instance, but
since C++ is a superset of C, the "equivalent program" could be exactly the
same code, line for line, and that's going to compile almost exactly the same
as the C code. But then you haven't really got anywhere in comparing
performance.

I think one can get further by checking out the issue from a more general
standpoint (below).
Post by Larry Troxler
can be. I think of C++ as just a cleaner notation for the same things
you would otherwise accomplish in C. In the realm of single inheritance
I agree that for many problems it is a cleaner notation, (and more fun to code
and design), but that by no means makes it a cleaner *compilation* of the
solution to the problem.
Post by Larry Troxler
performance difference. I suspect that this is some kind of false
folkore that won't go away. (especially since I've heard arguments to
Nah, there's reason behind it. The basic principle is this: the more you leave
to the compiler, the more things the compiler can decide to do inefficiently,
and the slower the resultant executable code. conversely, the less you leave
to the compiler, the less it can screw up, the more code you have to write, and
usually, the harder it will be to write well. Thus the (for the most part)
time-honored hierarchy of (fastest-to-slowest) languages: assembler (no
compiler), C (bare-bones compiler), C++ (more abstract), Java (semi-compiled)
and then your interpreted languages (uncompilable).

Personally I go with Jesse, use a kind of sparse C++. no templates, multiple
inheritance or overloaded operators, and where I want to get things fast I keep
everything inline, declare a bunch of local variables, that kind of thing.
profiler's a good thing.

troy
_______________________________________________________________________________

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Caliban Tiresias Darklock
1999-06-27 07:52:11 UTC
Permalink
On 12:45 AM 6/27/99 +0000, I personally witnessed Larry Troxler jumping up
Post by Larry Troxler
I hear
all the time how using C++ is supposed to somehow result in slower code
than the equivalent program coded in C.
Let me don my NOMEX underwear here, real quick... ahh, there.

It's a misstatement of the problem, actually. C++ is not inherently slower
than C -- proper object oriented programming is inherently slower than
proper structured programming. They are designed for different purposes --
structured programming is geared toward maintainability and robust program
operation, while OOP is geared toward manageability and code reuse.

Proper OOP will have everything wrapped up in flawless, errorproof objects.
So EVERY TIME you give a pointer to one of those objects, it has to look
and see whether it's a valid pointer. You call your base classes a lot, so
what you get is a valid pointer coming out of new(), being checked to
ensure it's non-NULL, then passed into the "Record" class, which checks to
see if it's valid. Then it calls the "RecordFile" class, which checks to
see if it's valid. Then it calls the "File" class, which checks to see if
it's valid. And then it calls the operating system, which hopefully checks
to see if it's valid. As you derive farther and farther from the base, a
properly written object will validate the pointer more and more often.

Proper structured programming doesn't do that. You do all your error
checking before you call the function. That way the function doesn't have
to error check it -- it knows you have done this already, so it won't
bother. You should have verified your memory was valid before getting here.
If you didn't, you're a bad programmer and your program deserves to crash.
Maybe you'll know better next time.

I want to stress that NEITHER APPROACH IS INHERENTLY BETTER. They're
different. They do different things well, and different other things badly.
It's worth noting that you can certainly write a series of C functions
which are just as paranoid and redundant as a C++ object heirarchy, or a
series of C++ objects which are just as reckless as normal C functions.
It's not the language; it's the canonical method most people use to program
in it.
Post by Larry Troxler
I think of C++ as just a cleaner notation for the same things
you would otherwise accomplish in C.
You can do everything you would do in C++ in C. It's just more difficult,
and the compiler won't be able optimise it properly, so you'll have to
optimise it yourself. If you programmed in C instead of C++ but built the
same sort of object-oriented programs... well, not only wouldn't it be
faster, it would probably be *slower*, since you're quite likely not as
good at optimising as the people who design optimising compilers for a living.

Likewise, if you write clean, tight, structured C++ instead of using OOP
concepts as the foundation of your program, C++ will probably outperform C
rather handily. You can certainly develop faster in it, purely as a matter
of how many times you type "<<" instead of "printf()". ;)
Post by Larry Troxler
(especially since I've heard arguments to
the effect that the farther a derived class is removed from a base
class, the slower the code!)
Partially true. Since you HAVE to assume that every class is a "black box",
you can't rely on your base class to do any error checking, and you can't
rely on your descendants to do any either. As a result, error checks are
performed everywhere, and you check the same pointer to make sure it's
valid about forty times. This slows things down. But C++ is not at fault;
it's the OOP discipline that mandates this sort of redundancy. When you
*don't* call the base class, you don't have this problem.

In structured programming using C, once you verify that a pointer is valid,
you can call any number of functions that don't modify the pointer. The
pointer will not magically become invalid. In OOP using C++, you may only
validate once, but when you make five calls to a class with seven ancestors
and all of them call the base -- yep, you guessed it, forty more error checks.

Some people say the structured C method is faster and therefore better.
Some people say the OO C++ method is more error-proof and therefore better.
Speed or certainty? Given one and only one choice which I could live with
on any and all programs until the end of time... I'll take certainty. If I
was going to program in one and only one methodology and language on each
and every project until the end of time, I'd pick OOP with C++. But as it
is, I tend to choose whatever makes more sense. Time-critical leans me
toward structured C; mission-critical leans me toward C++.
Post by Larry Troxler
So, is the "C++ is slower" thing just a programmer's urban myth? I think
it is!
It's only true when you leverage the strong points of C++ as opposed to the
strong points of C. It's often been said that C gives you all the power and
flexibility of assembly language combined with all the readability and
maintainability of assembly language. C++ is more or less the same... you
don't inherently get any benefit from C++ over C, it's just that certain
common tasks become easier.

-----
| Caliban Tiresias Darklock ***@darklock.com
| Darklock Communications http://www.darklock.com/
| U L T I M A T E U N I V E R S E I S N O T D E A D
| 774577496C6C6E457645727355626D4974H -=CABAL::3146=-

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Larry Troxler
1999-06-27 14:07:52 UTC
Permalink
Post by Caliban Tiresias Darklock
On 12:45 AM 6/27/99 +0000, I personally witnessed Larry Troxler jumping up
Post by Larry Troxler
I hear
all the time how using C++ is supposed to somehow result in slower code
than the equivalent program coded in C.
Let me don my NOMEX underwear here, real quick... ahh, there.
It's a misstatement of the problem, actually. C++ is not inherently slower
than C -- proper object oriented programming is inherently slower than
proper structured programming. They are designed for different purposes --
structured programming is geared toward maintainability and robust program
operation, while OOP is geared toward manageability and code reuse.
Proper OOP will have everything wrapped up in flawless, errorproof objects.
Who said C++ is
"Proper OOP", whatever that term means? But from your paragraph above,
you probably agree that the use of C++ doesn't equate to the use of
whatever "proper"OOP is.
Post by Caliban Tiresias Darklock
So EVERY TIME you give a pointer to one of those objects, it has to look
and see whether it's a valid pointer. You call your base classes a lot, so
what you get is a valid pointer coming out of new(), being checked to
ensure it's non-NULL, then passed into the "Record" class, which checks to
see if it's valid. Then it calls the "RecordFile" class, which checks to
see if it's valid. Then it calls the "File" class, which checks to see if
it's valid. And then it calls the operating system, which hopefully checks
to see if it's valid. As you derive farther and farther from the base, a
properly written object will validate the pointer more and more often.
I think the discussion is getting confused here (or at least veering off
into a different topic). (Well, I guess you admitted that yourself).
What I was questioning was the popular belief that using C++ results in
slower code than using C. But now you aren't reeally talking about
languages, but about programming paradigms (ugg, I hate that word - well
at least I didn't say "methodologies"). I'm sure you, and most people,
will agree whether C or C++ is used has no bearing on whether you are
programming in the OOP style or not. C is quite capable of implementing
classes and objects, if you decide before hand on some conventions. The
notation is not as clean, that's all.

Now. As far as your observation about how error-checking slows things
down, I think I might not quite understand what you mean whithout seeing
some code. I assume that you do a lot of OOP programming and have seen
this come up. I think that you are running in to a problem where you are
constantly checking to see if a pointer is valid, then perhaps this is a
problem with defining the "contract" between "client" and "server". The
"client" in this case would be the caller, and the "server" would be the
called function (or method if you prefer). In the situation you mention,
it seems that the "contract", or "interface requirements" are not
clearly defined, so you end up doing redundant error-checking because
neither caller and callee knows exactly who is responsible for ensuring
what conditions. Not that this is such a terrible thing, if you are not
in a critical path of the program. I do it all the time at my day job.
It is much easier and costs only a few bytes, to simply add a check in a
low-level function, rather than trying to figure out if the test is
redundant. Welcome to the real world where you have to get the product
out the door! The way I see it, this is the best of all possible ways of
being a lazy programmer! But again, in the "real world", the motto is
"first, let's make sure it works, then if for some strange reason the
sales department doesn't have something else for us to do, *then* we'll
make it faster".
Post by Caliban Tiresias Darklock
Proper structured programming doesn't do that. You do all your error
checking before you call the function. That way the function doesn't have
to error check it -- it knows you have done this already, so it won't
bother. You should have verified your memory was valid before getting here.
If you didn't, you're a bad programmer and your program deserves to crash.
Maybe you'll know better next time.
Hmm, I'm still not quite sure what OOP has to do with whether or not you
need to check whether an object is valid. I can see, for example, if you
have some public base-class function, then you might need to
double-check the "this" object for validity. But if you then derive from
that class (ok we're in C++ mode here), then could you not, if you had
the time, code a protected base-class funtion that was equivalent but
"unsafe"? You then do your validity checking in the subclass only, and
call "unsafe_xxx()" in the base.

At my level of experience, I have to say that I don't see why the use of
OOP in itself causes a performance hit because of redundant error
checking.
Post by Caliban Tiresias Darklock
I want to stress that NEITHER APPROACH IS INHERENTLY BETTER. They're
different.
And you can use both techniques *in the same program*! That's why this
discussion it academic, I think. It's simple. Be paranoid everywhere
except for the real-time stuff.
For the RT code, which is usually very small anyway, simply spend a
little time to eliminate innefficiencies. Make sure all "ugen" or
"dsp-module" objects are valid (not just non-null, but consistent,
properly constructed objects), before they are exposed to the
time-critical code. The time-critical stuff then needs not do any error
checking at all. So I guess I don't see what the big deal is, although
this is a quite interesting discussion. It is certainly not an argument
against using C++, as you have said yourself and which we agree :-)
Post by Caliban Tiresias Darklock
You can do everything you would do in C++ in C. It's just more difficult,
and the compiler won't be able optimise it properly, so you'll have to
optimise it yourself. If you programmed in C instead of C++ but built the
same sort of object-oriented programs... well, not only wouldn't it be
faster, it would probably be *slower*, since you're quite likely not as
good at optimising as the people who design optimising compilers for a living.
Yep, but at my day job I have to stick to C. I write embedded industrial
control systems, and we haven't made the switch to a C++ cross-compiler
yet. It's not actually that much of a loss, since we don't use a
dynamic memory allocator anyway (easier and much safer to statically
allocate everything for the worst-case scenario).
Post by Caliban Tiresias Darklock
Post by Larry Troxler
(especially since I've heard arguments to
the effect that the farther a derived class is removed from a base
class, the slower the code!)
Partially true. Since you HAVE to assume that every class is a "black box",
you can't rely on your base class to do any error checking, and you can't
rely on your descendants to do any either. As a result, error checks are
performed everywhere, and you check the same pointer to make sure it's
valid about forty times.
This slows things down. But C++ is not at fault;
it's the OOP discipline that mandates this sort of redundancy. When you
*don't* call the base class, you don't have this problem.
Well, I guess we already talked about this issue. In summary, I don't
think I can agree that OOP implies these kind of redundant error checks
in the general case. Certainly, there's no such thing as some OOP
Discipline that mandates this. Certainly it all depends on the
programming language, project requirements, whether the objects are
distributed across a network, etc. I think you are over-generalizing!
Post by Caliban Tiresias Darklock
-----
| Darklock Communications http://www.darklock.com/
| U L T I M A T E U N I V E R S E I S N O T D E A D
| 774577496C6C6E457645727355626D4974H -=CABAL::3146=-
dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Larry Troxler


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michel Jullian
1999-06-28 08:40:41 UTC
Permalink
Post by Larry Troxler
Now. As far as your observation about how error-checking slows things
down, I think I might not quite understand what you mean whithout seeing
some code. I assume that you do a lot of OOP programming and have seen
Just a thought, but maybe this has to do with overriding : there is a need to
check if the method has been overriden by the derived classes all the way up
the class hierarchy to the base class. But I would have thought this kind of
null-pointer checking was done at compile-time , not at runtime ?
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email ***@exbang.com
Exbang Industries S.A.
Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
Maurin 34970 Lattes France fax +33(0) 499 529 879
.........................................................................


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Earl Vickers
1999-06-27 18:06:07 UTC
Permalink
I want to convert SFX Machine to Windows Direct-X. SFX Machine is an
award-winning multi-effects and modular synthesis Premiere-format plug-in
for the Macintosh. It's not as deep as CSound, etc., but there are over 300
presets and it's convenient to use.

I'd like to find a Windows programmer to do this conversion. I can't pay
anything up front, but I would offer half of my royalties from the Windows
version, with an advance upon completion. The code is in C. The DSP code is
pretty straightforward; the user interface code is somewhat involved. There
may be some thrashing and/or cursing. On the plus side, a few months of
work should bring in royalties for a couple years or more. E-mail me
directly if you're interested.

Alternatively, if I can't find a programmer, I may break down and do this
myself in my copious free time. Any suggestions for how to get started
writing a Direct-X plug-in? For example, a very complete starter kit that
implements a simple example effect?

--
Earl Vickers
http://www.bias-inc.com/sfx.html

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michel Jullian
1999-06-28 08:22:13 UTC
Permalink
Post by Earl Vickers
I want to convert SFX Machine to Windows Direct-X. SFX Machine is an
award-winning multi-effects and modular synthesis Premiere-format plug-in
for the Macintosh. It's not as deep as CSound, etc., but there are over 300
presets and it's convenient to use.
Have you considered starting with a vst plugin ?

- Unanimously considered easier to develop
- There exists a VSTtoDX converter, but none for the other way round AFAIK.
- VST2 interface (sdk soon to be released hopefully) allows for MIDI note and
parameter passing (which is not the case of DirectX : you have to use virtual
midi ports such as hubi loopback's for that, which hampers rendering).
- Last but not least in your case, you can develop your plugin on the Mac (use
the vst2 GUI APIs for your GUI) and it will need little more than recompiling
for Windows :-)

http://www.steinberg.net/developers/VSTPlugInsDocumentation/index.html
Post by Earl Vickers
I'd like to find a Windows programmer to do this conversion. I can't pay
anything up front, but I would offer half of my royalties from the Windows
version, with an advance upon completion.
Do I get half of your royalties if a simple recompile does it ? ;-)
Post by Earl Vickers
Alternatively, if I can't find a programmer, I may break down and do this
myself in my copious free time. Any suggestions for how to get started
writing a Direct-X plug-in? For example, a very complete starter kit that
implements a simple example effect?
http://www.microsoft.com/directx/resources/devdl.htm

If there are people out there who think DirectX plugins are better, i am
interested and quite open to their arguments.
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email ***@exbang.com
Exbang Industries S.A.
Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
Maurin 34970 Lattes France fax +33(0) 499 529 879
.........................................................................



dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michel Jullian
1999-06-29 06:53:29 UTC
Permalink
Thanks for the suggestion! That does sound like the best way to proceed.
If you're going the VST way, note that :
- the new version 2 vst sdk is due out any day now (might be worth waiting
unless you don't need the new features)
Post by Michel Jullian
Do I get half of your royalties if a simple recompile does it ? ;-)
I'd have to say, probably not. :-)
I guessed not ;-)

Good luck for your project.
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email ***@exbang.com
Exbang Industries S.A.
Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
Maurin 34970 Lattes France fax +33(0) 499 529 879
.........................................................................


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Bram De Jong
1970-01-01 00:00:00 UTC
Permalink
Hi,

for what it's worth:

I will make NO assumptions on speed, but, when one sees OO-code, you can
imediatly see what it's all about (for example STKit). When you use a non
OO language, the deeper plot is VERY obsecure (CSound).

I enjoyed reading the STKit source code.
I did NOT enjoy finding out how CSound works.

One more thing.
Isn't the way of abrreviating EVERYTHING in CSound a bit archaic.
Newcomers to the language have a hard enough time learning to use the
'compiler' like feeling. They stagger back when they see all those stupid
abbrvs ;)
If the user wound have to use these names a LOT of times in one orchestra.
Wouldn't it be nice if it said Resonator in stead of Reson ????


My 2 pence


Bram


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Bram De Jong
1970-01-01 00:00:00 UTC
Permalink
Hi,


I've been programming some more.
These are some sounds from a program I will be releasing soon, soon, soon.

There created by an abstract Additive Synthesis synth, controlled by
Cellular Automata. The program I wam creating combines CA's with Add.
synthesis, with GA's and NN's... (try to guess the abbrv., like in CSound)

;))))

http://studwww.rug.ac.be/~bdejong/CA.zip





Bram


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michel Jullian
1999-06-26 20:39:44 UTC
Permalink
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.
Well, what do you think Michael ? Might be worth considering C++ :-)
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email ***@exbang.com
Exbang Industries S.A.
Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
Maurin 34970 Lattes France fax +33(0) 499 529 879
.........................................................................


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-27 13:24:36 UTC
Permalink
I'm surprised by the emotional depth of this discussion about C versis C++,
which is distracting the discussion away from the merits of my proposal to
rewrite the kernel of Csound.

I don't care whether it's C or C++ as long as it's fast and completely
platform-neutral so that in reality it IS just recompilation for different
processors.

Can we get back to the point now?

-----Original Message-----
From: Michel Jullian <***@exbang.com>
To: ***@maths.ex.ac.uk <***@maths.ex.ac.uk>
Cc: music-dsp list <music-***@shoko.calarts.edu>
Date: Sunday, June 27, 1999 5:43 AM
Subject: Re: Proposal for a new version of Csound
Post by Michel Jullian
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
Post by Michel Jullian
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.
Well, what do you think Michael ? Might be worth considering C++ :-)
--
Greetings,
Michel
.........................................................................
Exbang Industries S.A.
Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
Maurin 34970 Lattes France fax +33(0) 499 529 879
.........................................................................
dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Paul Barton-Davis
1999-06-27 14:45:02 UTC
Permalink
Post by Michael Gogins
I'm surprised by the emotional depth of this discussion about C versis C++,
which is distracting the discussion away from the merits of my proposal to
rewrite the kernel of Csound.
I don't care whether it's C or C++ as long as it's fast and completely
platform-neutral so that in reality it IS just recompilation for different
processors.
This is a little disingenuous Michael - we got started on this track
because Michel asked "why not do it in C++?" and you offered two
arguments against it: speed, and your desire to use only the ANSI C
runtime library.
Post by Michael Gogins
Can we get back to the point now?
Sure, but what *is* the point ? Given that I have already
reimplemented a "Csound kernel" to do most of what you describe (and
other stuff too), I would think that a good starting point would be:
is Quasimodo a reasonable place to begin, or do we (you) want to do it
all over again ? If the former, then we can ask: what needs to change
in Quasimodo so that it can be used the way that you describe ?

I expect that the answer to the first question is "well, no not
really". I say this because I have an important goal for Quasimodo
that you don't have for your proposal, namely a multithreaded
implementation. Multithreadedness is no small alteration to a program,
and although its conceivable that we could figure out a way to make
this transparent, I think it would come back to bite somewhere
else. There are many assumptions throughout the design of Quasimodo
that there are different threads handling different responsibilities.

The reason that multithreadedness is a problem is because there
is a standard for threads that I think makes sense to follow: POSIX
P.1003. This standard is not implemented, as far as I know, for the
Mac, and I am not sure of its status for Windows (one of the cygnus
libraries might have it, I don't know).

This makes it hard to see how Quasimodo could form the basis for
the cross-platform system you want to build. It certainly violates
your desire to stick with the ANSI C runtime library.

Other important issues: if you commit to being truly cross-platform,
and reliant only on core C functionality, you can't use
compiler-compiler's like bison. You could provide the C output of
bison as part of the distribution, but that isn't cross-platform. Not
using compiler-compilers is one of the biggest problems with Csound as
it currently exists, IMHO.

I sound negative in the above, which is not intentional. I don't want
to see someone else having to redo all the stuff that I've already
done, and I think that Quasimodo would itself benefit from being
required to meet some of the design goals that you laid out. But I do
feel that there is a bit of a disjunction between Quasimodo's overall
goals and yours, and that these might make it hard to use the same
kernel. It would be great if this was not true, and I welcome
suggestions and ideas on how to make it not true.

--p




dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
t***@cygnus.com
1999-06-28 13:04:02 UTC
Permalink
Post by Paul Barton-Davis
The reason that multithreadedness is a problem is because there
is a standard for threads that I think makes sense to follow: POSIX
P.1003. This standard is not implemented, as far as I know, for the
Mac, and I am not sure of its status for Windows (one of the cygnus
libraries might have it, I don't know).
The Cygwin library implements posix threads as well as many other posix
API's. See http://sourceware.cygnus.com/cygwin/

Thomas

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-27 15:00:16 UTC
Permalink
This is more like it... a substantial discussion.

What indeed would need to be done to fit Quasimodo into the JavaSound
framework using some class with native methods such as I have described? I
have looked over the Quasimodo source code, but since I'm not experienced
with Gtk and other Linux type stuff, it's not clear where, if at all, the
GUI can be severed from the kernel. I must say I admire what I saw.

It's also not clear to me whether currently compiling Csound scores and
orchestras would run with Quasimodo, without modification, which is a
requirement of my proposal: complete backward compatibility with existing
scores and orchestras. Sorry if I didn't make that clear.

When I say "cross-platform", I mean: you take the sources, which possibly
have some conditional compilation in one or a few clearly demarcated files,
define one macro in the makefile, type "make", and then you can run
JavaCsound with JavaSound on your processor.

If it is necessary to create some abstract interfaces (say an abstract
thread class with different implementations on different platforms) that is
fine, as long as this part of the work is stable and easily maintained. It
also is not critical if the compiler-compiler runs only on one (common)
platform, but I would prefer otherwise.

As far as threading is concerned, the JavaCsound class is designed to have
methods that are pulled at by different threads - but those threads are
created in the JavaCsound Java code or in the external program itself, not
in the Csound C or C++ kernel. In other words, the Csound kernel implements
the guts of several worker thread routines, but those threads are created
and destroyed outside of the kernel, either in the JavaCsound class or in
its clients. This design makes it easy to (a) code a thread-safe kernel and
(b) synchronize all the inputs and outputs.The thread synchronization model
is pretty much mandated by the JavaSound API design, but I think it looks
like a pretty good model.




-----Original Message-----
From: Paul Barton-Davis <***@Op.Net>
To: ***@maths.ex.ac.uk <***@maths.ex.ac.uk>;
music-***@shoko.calarts.edu <music-***@shoko.calarts.edu>
Date: Sunday, June 27, 1999 10:39 AM
Subject: Re: Proposal for a new version of Csound
Post by Paul Barton-Davis
Given that I have already
reimplemented a "Csound kernel" to do most of what you describe (and
is Quasimodo a reasonable place to begin, or do we (you) want to do it
all over again ? If the former, then we can ask: what needs to change
in Quasimodo so that it can be used the way that you describe ?
I expect that the answer to the first question is "well, no not
really". I say this because I have an important goal for Quasimodo
that you don't have for your proposal, namely a multithreaded
implementation. Multithreadedness is no small alteration to a program,
and although its conceivable that we could figure out a way to make
this transparent, I think it would come back to bite somewhere
else. There are many assumptions throughout the design of Quasimodo
that there are different threads handling different responsibilities.
The reason that multithreadedness is a problem is because there
is a standard for threads that I think makes sense to follow: POSIX
P.1003. This standard is not implemented, as far as I know, for the
Mac, and I am not sure of its status for Windows (one of the cygnus
libraries might have it, I don't know).
This makes it hard to see how Quasimodo could form the basis for
the cross-platform system you want to build. It certainly violates
your desire to stick with the ANSI C runtime library.
Other important issues: if you commit to being truly cross-platform,
and reliant only on core C functionality, you can't use
compiler-compiler's like bison. You could provide the C output of
bison as part of the distribution, but that isn't cross-platform. Not
using compiler-compilers is one of the biggest problems with Csound as
it currently exists, IMHO.
I sound negative in the above, which is not intentional. I don't want
to see someone else having to redo all the stuff that I've already
done, and I think that Quasimodo would itself benefit from being
required to meet some of the design goals that you laid out. But I do
feel that there is a bit of a disjunction between Quasimodo's overall
goals and yours, and that these might make it hard to use the same
kernel. It would be great if this was not true, and I welcome
suggestions and ideas on how to make it not true.
dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Paul Barton-Davis
1999-06-27 16:59:52 UTC
Permalink
[ please note the qm-dev mailing list inclusion in the Cc: line ]
Post by Michael Gogins
with Gtk and other Linux type stuff, it's not clear where, if at all, the
GUI can be severed from the kernel.
Its as completely separate as I could make it. There are just two
"connections":

1) in nmain.cc:
UI *ui;

if ((ui = ui_factory (&argc, &argv)) == NULL) {
error << "Cannot start Quasimodo UI" << endmsg;
return 1;
}

UI is an abstract class that declares the following functions:

virtual bool running () = 0;
virtual void quit () = 0;
virtual void request (RequestType) = 0;
virtual ModuleSet &default_module_set () = 0;
virtual void new_module_set () = 0;
virtual int nstate_query (size_t nstates, const char *prompt, ...) = 0;
virtual void queue_error_message (Transmitter::Channel, const char *) = 0;
virtual void run (Receiver *) = 0;

The things that really make the UI work are in a concrete UI class
that implements the virtual methods as well as its own (see
src/qm/abstract_ui.h for the definition)

2) various methods of the UI class are used by way of the global "ui" pointer.

So, to make this work in Java, you just write a new concrete UI class
implements the required methods. You don't need to fix up ui_factory,
because presumably, there would be a different "main()" if things ran
inside Java (but src/qm/nmain.cc shows very clearly how
straightforward it is to get things running).
Post by Michael Gogins
It's also not clear to me whether currently compiling Csound scores and
orchestras would run with Quasimodo, without modification, which is a
requirement of my proposal: complete backward compatibility with existing
scores and orchestras. Sorry if I didn't make that clear.
The orchestra parser is complete (I think), and handles all Csound
instruments that I've been able to find that use the opcodes I've
ported thus far. It actually handles a few things more sensibly than
Csound as well, but attempts to be backwards compatible. For example,
value converters that return an i-time value can be used as an i-time
argument to another opcode, instead of first storing their return
value in another variable.

The only (intended) notable change is that Quasimodo has no concept of
"header statements", so setting kr, ksmps, etc. at the top of a .orc
has no effect whatsoever. It wouldn't be hard to change that, but if
you plan to load several different instrument files the way that
Quasimodo does, the idea that these variables should be set in any one
of them is just plain wrong.

The score file stuff is both more compatible (in that there are no
changes whatsoever), and less complete. It currently does not handle
ramping, npp, lpp and various other things. There is also no support
for the macro system, which I consider to have been an extremely bad
design decision by jpff.

All this is with the proviso that both are still liable to changes,
and the score file stuff doesn't currently work at all (I broke it,
but will fix it today). But hey, its all just Bison and flex
specifications, so changing it is nothing like trying to change the
Csound parser.
Post by Michael Gogins
When I say "cross-platform", I mean: you take the sources, which possibly
have some conditional compilation in one or a few clearly demarcated files,
define one macro in the makefile, type "make", and then you can run
JavaCsound with JavaSound on your processor.
Sounds pretty reasonable. Thats the way Quasimodo tries to be "for
itself". There are almost no #ifdef's anywhere in the main code for
different platforms, and I intend it to remain that way. There is a
system-dependent directory with system-specific code in it that
handles all the differences between platforms, as well as a "Platform"
object that can be used for various platform-specific small tasks.
Post by Michael Gogins
If it is necessary to create some abstract interfaces (say an abstract
thread class with different implementations on different platforms) that is
fine, as long as this part of the work is stable and easily maintained. It
also is not critical if the compiler-compiler runs only on one (common)
platform, but I would prefer otherwise.
Well, Bison is out there, and I'm sure there are various versions for
Windows etc. Same with flex.
Post by Michael Gogins
in the Csound C or C++ kernel. In other words, the Csound kernel implements
the guts of several worker thread routines, but those threads are created
and destroyed outside of the kernel, either in the JavaCsound class or in
its clients.
Quasimodo is written so that the code to handle various tasks run in a
different thread than the DSP simulator. This is the key to making it
able to use multiple processors. Although the DSP thread could be
thought of as the Csound kernel, thats not really true in Quasimodo:
to implement all that Csound does, Quasimodo uses 3 threads: the DSP
simulator, the real time event thread and some other thread (which
might be running the UI) to handle input/loading and parsing of scores
and orchestras.

This doesn't look like a single function, and if you used it for Java,
you'd presumably need a Java wrapper that invoked the 2 "other"
threads, and took care of the tasks currently done by the UI thread.

Its going to get more complex too: I am about to change things so that
there is one DSP thread per ModuleSet, and then a final (quick)
mixdown of the output of each DSP before it goes off to the
soundcard. This allows me to use N>2 CPU systems efficiently, and even
N=2 CPU's *more* efficiently, since when Quasimodo is running, its
almost always just the DSP thread thats active, leaving a second
processor sitting idle until "something else" happens. It also opens
the door to sound output from Quasimodo coming from things other than
Quasimodo DSP threads, if you see what I mean.

I don't know how this is sounding so far. I do think that Quasimodo
could really benefit from trying to be made into something close to
what you described.

--p

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-27 23:05:38 UTC
Permalink
Many thanks for your thoughtful and detailed explanations. It now looks more
like the Quasimodi UI class might possibly be used to implement my Java
kernel. Certainly it looks worth looking into. When I perused the sources I
thought UI had something to do with GUI, but now it seems to be just the API
for Csound.

The threading issues seem amenable to me. Either Quaismodo can do all this
thread stuff internally, or we could break its threads out to Java and let
only Java spawn and destroy them. Perhaps you can define some classes that
expose the thread routines but not the thread creation and destruction, your
concrete UI class can do that, and a Java version of the concrete UI class
can also do that.

I welcome your interest in my proposal. I will try to make a rough cut of
integrating Quasimodo into my design, modifying the design if it seems
reasonable, and get it up on the list soon.

In the meantime, I have modified my design quite a bit after going over and
over the JavaSound APIs. I have appended the new design, which is still not
quite complete. At the lowest level, the actual native interfaces are all in
the following (and there are not many native methods after all). This
becomes a straight C++ class in the kernel code.

/**
* An implementation of SynthesizerKernel
* based on a platform-independent,
* re-entrant, multiply instantiable,
* double-precision rewrite of Csound with
* plugin unit generators and function tables.
*/
public class CsoundKernel extends SynthesizerKernel
{
public native long createKernel();
public native void destroyKernel(long kernel);
public native boolean read(long kernel, String filename);
public native boolean compile(long kernel, String xml);
public native void sendCommand(long kernel, String command);
public native int loadAllPlugins(long kernel, String directory);
public native int loadPlugin(long kernel, String filename);
public native boolean midiSendOpen(long kernel);
public native boolean midiSendClose(long kernel);
public native boolean isMidiSendOpen(long kernel);
public native void midiSend(long kernel, byte[] midiSendBytes);
public native boolean midiReceiveOpen(long kernel);
public native boolean midiReceiveClose(long kernel);
public native boolean isMidiReceiveOpen(long kernel);
public native synchronized int midiReceive(long kernel, byte[]
midiInBytes, Object monitor);
public native int getAudioSampleFramesPerSecond(long kernel);
public native void setAudioSampleFramesPerSecond(long kernel, int
value);
public native int getAudioSampleFramesPerControlSample(long kernel);
public native void setAudioSampleFramesPerControlSample(long kernel, int
value);
public native int getAudioInputChannelCount(long kernel);
public native void setAudioInputChannelCount(long kernel, int value);
public native boolean audioInputOpen(long kernel);
public native boolean audioInputClose(long kernel);
public native boolean audioInputIsOpen(long kernel);
public native synchronized int audioInputWrite(long kernel, float[]
audioInputBuffer, int offset, int length, Object monitor);
public native int getAudioOutputChannelCount(long kernel);
public native void setAudioOutputChannelCount(long kernel, int value);
public native boolean audioOutputOpen(long kernel);
public native boolean audioOutputClose(long kernel);
public native boolean audioOutputIsOpen(long kernel);
public native int audioOutputRead(long kernel, float[]
audioOutputBuffer, int offset, int length);
}

One thing I have done is made the synthesizer interface abstract, so that it
could be implemented by any number of different synthesizer "kernels", such
as a rewrite of Csound, Quasimodo, or SAOL. In other words, my proposal is
for an adapter class that fits general-purpose, academic, powerful software
synthesizers seamlessly into the JavaSound framework, which, the more I work
with it, seems reasonably flexible and useful. Only time can tell if the
implementation of the JavaSound APIs lives up to its good appearance.

From: Paul Barton-Davis <***@Op.Net>
To: Michael Gogins <***@nyc.pipeline.com>
Cc: ***@maths.ex.ac.uk <***@maths.ex.ac.uk>;
music-***@shoko.calarts.edu <music-***@shoko.calarts.edu>;
qm-***@exp.firstpr.com.au <qm-***@exp.firstpr.com.au>
Date: Sunday, June 27, 1999 12:53 PM
Subject: Re: Proposal for a new version of Csound
Post by Paul Barton-Davis
Post by Michael Gogins
with Gtk and other Linux type stuff, it's not clear where, if at all, the
GUI can be severed from the kernel.
Its as completely separate as I could make it. There are just two
UI *ui;
if ((ui = ui_factory (&argc, &argv)) == NULL) {
error << "Cannot start Quasimodo UI" << endmsg;
return 1;
}
virtual bool running () = 0;
virtual void quit () = 0;
virtual void request (RequestType) = 0;
virtual ModuleSet &default_module_set () = 0;
virtual void new_module_set () = 0;
virtual int nstate_query (size_t nstates, const char *prompt, ...) = 0;
virtual void queue_error_message (Transmitter::Channel, const char *) = 0;
virtual void run (Receiver *) = 0;
Quasimodo is written so that the code to handle various tasks run in a
different thread than the DSP simulator. This is the key to making it
able to use multiple processors. Although the DSP thread could be
to implement all that Csound does, Quasimodo uses 3 threads: the DSP
simulator, the real time event thread and some other thread (which
might be running the UI) to handle input/loading and parsing of scores
and orchestras.
This doesn't look like a single function, and if you used it for Java,
you'd presumably need a Java wrapper that invoked the 2 "other"
threads, and took care of the tasks currently done by the UI thread.
Its going to get more complex too: I am about to change things so that
there is one DSP thread per ModuleSet, and then a final (quick)
mixdown of the output of each DSP before it goes off to the
soundcard. This allows me to use N>2 CPU systems efficiently, and even
N=2 CPU's *more* efficiently, since when Quasimodo is running, its
almost always just the DSP thread thats active, leaving a second
processor sitting idle until "something else" happens. It also opens
the door to sound output from Quasimodo coming from things other than
Quasimodo DSP threads, if you see what I mean.
I don't know how this is sounding so far. I do think that Quasimodo
could really benefit from trying to be made into something close to
what you described.
--p
Jason VandeKieft
1999-06-28 19:30:01 UTC
Permalink
Hello Earl,

You might consider taking a look at Sonic Foundry's free Plug-In Development
Kit (PIDK) available on our website here:
http://www.sonicfoundry.com/support/dev/dev.asp

While not an exhaustive resource, it will probably help you get going in the
world of DirectX. It is essentially a handful of generic plugins that can
be used as templates or starting points for less trivial effects. Also, it
packages much of the non-DSP related code (e.g. connection code) into a
manageable form.

The PIDK does require the Microsoft DirectX Media SDK, Version 6.0 or later.
Please not that this is not the same as the DirectX 6.1 SDK. The Media SDK
is no longer available for download, but MS will send you a CD for a nominal
fee (around $10, I think). More info can be found here:

http://www.microsoft.com/directx/developer/downloads/dx6mediasdk.asp

Regards,
Jason.

Jason VandeKieft
Sonic Foundry, Inc.
http://www.sonicfoundry.com
Date: Sun, 27 Jun 1999 10:06:07 -0800
Subject: Programmer/advice for Direct-X conversion
I want to convert SFX Machine to Windows Direct-X. SFX Machine is an
award-winning multi-effects and modular synthesis Premiere-format plug-in
for the Macintosh. It's not as deep as CSound, etc., but there are over
300
presets and it's convenient to use.
I'd like to find a Windows programmer to do this conversion. I can't pay
anything up front, but I would offer half of my royalties from the Windows
version, with an advance upon completion. The code is in C. The DSP code
is
pretty straightforward; the user interface code is somewhat involved.
There
may be some thrashing and/or cursing. On the plus side, a few months of
work should bring in royalties for a couple years or more. E-mail me
directly if you're interested.
Alternatively, if I can't find a programmer, I may break down and do this
myself in my copious free time. Any suggestions for how to get started
writing a Direct-X plug-in? For example, a very complete starter kit that
implements a simple example effect?
- --
Earl Vickers
http://www.bias-inc.com/sfx.html
Michael Gogins
1999-06-28 23:45:50 UTC
Permalink
I completely agree with you about abbreviations. I never use them myself.

I also frequently avoid putting comments in for quite a while, and see if I
or anyone else can understand the code purely from the design and the names
of the variables and functions. This seems to help me write better code. To
each his (or her) own.

-----Original Message-----
From: Bram De Jong <***@rug.ac.be>
To: music-***@shoko.calarts.edu <music-***@shoko.calarts.edu>
Date: Monday, June 28, 1999 4:47 PM
Subject: C<->C++<->CSound
Post by Bram De Jong
Hi,
I will make NO assumptions on speed, but, when one sees OO-code, you can
imediatly see what it's all about (for example STKit). When you use a non
OO language, the deeper plot is VERY obsecure (CSound).
I enjoyed reading the STKit source code.
I did NOT enjoy finding out how CSound works.
One more thing.
Isn't the way of abrreviating EVERYTHING in CSound a bit archaic.
Newcomers to the language have a hard enough time learning to use the
'compiler' like feeling. They stagger back when they see all those stupid
abbrvs ;)
If the user wound have to use these names a LOT of times in one orchestra.
Wouldn't it be nice if it said Resonator in stead of Reson ????
My 2 pence
Bram
dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Martin Fay
1999-06-29 00:05:33 UTC
Permalink
Post by Michel Jullian
Post by Earl Vickers
I want to convert SFX Machine to Windows Direct-X. SFX Machine is an
award-winning multi-effects and modular synthesis Premiere-format plug-in
for the Macintosh. It's not as deep as CSound, etc., but there are over 300
presets and it's convenient to use.
Have you considered starting with a vst plugin ?
- - Unanimously considered easier to develop
Agreed, although most of the pain is in the COM, if you were up on
this before starting (pretty unlikely) then it wouldn't be much
harder.
Post by Michel Jullian
- - There exists a VSTtoDX converter, but none for the other way round AFAIK.
There is, not that it's available to the public, I created one to see
if I could and because it required some work on my DX plugin hosting
code which I'd been putting off ;)
Post by Michel Jullian
- - VST2 interface (sdk soon to be released hopefully) allows for MIDI note and
parameter passing (which is not the case of DirectX : you have to use virtual
midi ports such as hubi loopback's for that, which hampers rendering).
I'm not totally sure of the answer to this, but is this just a case of
MIDI not being implemented on DX plugin hosts? I've haven't seen
anything using MIDI over DirectShow but I think I remember the data
type constants being there...
Post by Michel Jullian
- - Last but not least in your case, you can develop your plugin on the Mac (use
the vst2 GUI APIs for your GUI) and it will need little more than recompiling
for Windows :-)
This is a very good point, and one which would bear futher
investigation.


Martin

| man(i)kin - sem(i)nal debut album
| available on nightbreed recordings july
| www.manikin.force9.co.uk
--------------------------------------------
| VAZ Modular virtual analogue modular synth
| VAZ+ virtual analogue synth
| www.software-technology.com


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Niels Gorisse
1999-06-29 07:59:25 UTC
Permalink
Hi,
Post by Jason VandeKieft
You might consider taking a look at Sonic Foundry's free
Reading this, I remembered I once wrote a paper about making DirectX
plugins and an explanation of all technology buzzwords around it. It is in
DUTCH (sorry for that), but defenitely better than starting with the PIDK
first - that doesn't explain a thing. You can read it (if you can...) at:

http://www2.hku.nl/~aud97/dxplugins/

Greets,

Niels Gorisse



dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Continue reading on narkive:
Loading...